From salvatore.loreto@ericsson.com Sat Dec 1 02:27:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA09121F850E for ; Sat, 1 Dec 2012 02:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 x-1-6nBJavOR for ; Sat, 1 Dec 2012 02:27:02 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0658421F84FB for ; Sat, 1 Dec 2012 02:27:01 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-7d-50b9db74a28e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 25.0C.06323.47BD9B05; Sat, 1 Dec 2012 11:27:00 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Sat, 1 Dec 2012 11:27:00 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E52B92B30 for ; Sat, 1 Dec 2012 12:26:59 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9E2BD53D1D for ; Sat, 1 Dec 2012 12:26:58 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 57A7553D1C for ; Sat, 1 Dec 2012 12:26:58 +0200 (EET) Message-ID: <50B9DB72.8050705@ericsson.com> Date: Sat, 1 Dec 2012 12:26:58 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50B90266.4030003@nostrum.com> <50B92BF8.2090303@omnitor.se> <50B93506.3090509@jesup.org> In-Reply-To: <50B93506.3090509@jesup.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+JvjW7J7Z0BBlPvylis/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBvvNQp281aceJXVwHiFq4uRk0NCwESi98BiRghbTOLCvfVs XYxcHEICJxklPr28xwjhrGeUmLTqMjuEc4FRYunXdiYI5zCjxOumVSwQzhlGib/v9rGDDOMV 0JZY2nwcbDCLgIrE9233mUBsNgEziecPtzCD2KICsRJbL11mg6gXlDg58wkLiC0iICyx9VUv WL2wgJXErK5JUAt+Mkqsuv0abCingKbE7vkNYM3MArYSF+ZcZ4Gw5SWat85mhvhITeLquU1g tpCAlkTv2U6mCYwis5Dsm4WkfRaS9gWMzKsY2XMTM3PSy803MQKD+eCW3wY7GDfdFzvEKM3B oiTOq6e6319IID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD47nM5ce3GMj/dzKb9eugxgu94I5N 79gNpcIdqy2uzkwtkvpZ2jZp0VtBm6cu8ZYPTy6Zo/3jzKyg2bEKSudkZ7H+/bRtu6Ptjrz7 Xww2/dymzpKUZSS0N/yDK9PRZevUHnQe5DZ6z2s7Z2PCgnDrSTMOS7yOcPmlWraI2fu4XP2D yWEPjY1lrZVYijMSDbWYi4oTAQYz3yk0AgAA Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 10:27:03 -0000 On 12/1/12 12:36 AM, Randell Jesup wrote: > On 11/30/2012 4:58 PM, Gunnar Hellström wrote: >> It has been said a number of times that the rtcweb data channel would >> be suitable for real-time text. >> >> I have also seen doubts about that expressed. >> >> One alerting doubt was that it did not seem to have well established >> implementations. And the protocol spec is very thick. It might take a >> long time before it is implemented with reliable function and good >> interoperability. Right? > > The protocol spec is tiny (draft-jesup-rtcweb-data-protocol). If > you're thinking SCTP, yes it's large - so are UDP and TCP, and it does > a lot more. It's used a lot in telephony; very little on the open web. > >> I would like to know more about the data channel. >> >> How much overhead is it per transmission? > > Not a lot. The rtcweb DataChannel protocol adds nothing to a > datagram. SCTP is slightly larger than TCP IIRC, not a lot. Ask > Michael Tuexen or Randall Stewart; maintainers of SCTP and authors on > the spec who are working with us. > >> Is it possible to specify capability negotiation of features using >> the data channel? > > yes > >> Does that require additions to the specs. > > No, you can specify them at channel open time (see the draft), or > (proposed) in negotiation (draft-mmusic-sdp-something). here the link to the draft that propose SDP negotiation for datachannel http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02 the authors are working on a new version that will include the result of the so far discussion on the issue. If you are interested on it please contribute in the mmusic mailing list cheers Salvatore From harald@alvestrand.no Sat Dec 1 02:33:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A3F21F86F6 for ; Sat, 1 Dec 2012 02:33:47 -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 li+WkA2pPq7M for ; Sat, 1 Dec 2012 02:33:47 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0144821F85FD for ; Sat, 1 Dec 2012 02:33:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7458339E13F; Sat, 1 Dec 2012 11:33:44 +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 grEEFfMCvkBG; Sat, 1 Dec 2012 11:33:43 +0100 (CET) Received: from [10.130.6.40] (unknown [194.72.72.170]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id F22B139E090; Sat, 1 Dec 2012 11:33:42 +0100 (CET) Message-ID: <50B9DD06.4090902@alvestrand.no> Date: Sat, 01 Dec 2012 11:33:42 +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: Salvatore Loreto References: <50B87606.5030802@ericsson.com> <50B90266.4030003@nostrum.com> <50B92BF8.2090303@omnitor.se> <50B93506.3090509@jesup.org> <50B9DB72.8050705@ericsson.com> In-Reply-To: <50B9DB72.8050705@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: [rtcweb] Data channel SDP (Re: Consensus call on Text Communication) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 10:33:47 -0000 On 12/01/2012 11:26 AM, Salvatore Loreto wrote: > On 12/1/12 12:36 AM, Randell Jesup wrote: >> On 11/30/2012 4:58 PM, Gunnar Hellström wrote: >>> It has been said a number of times that the rtcweb data channel >>> would be suitable for real-time text. >>> >>> I have also seen doubts about that expressed. >>> >>> One alerting doubt was that it did not seem to have well established >>> implementations. And the protocol spec is very thick. It might take >>> a long time before it is implemented with reliable function and good >>> interoperability. Right? >> >> The protocol spec is tiny (draft-jesup-rtcweb-data-protocol). If >> you're thinking SCTP, yes it's large - so are UDP and TCP, and it >> does a lot more. It's used a lot in telephony; very little on the >> open web. >> >>> I would like to know more about the data channel. >>> >>> How much overhead is it per transmission? >> >> Not a lot. The rtcweb DataChannel protocol adds nothing to a >> datagram. SCTP is slightly larger than TCP IIRC, not a lot. Ask >> Michael Tuexen or Randall Stewart; maintainers of SCTP and authors on >> the spec who are working with us. >> >>> Is it possible to specify capability negotiation of features using >>> the data channel? >> >> yes >> >>> Does that require additions to the specs. >> >> No, you can specify them at channel open time (see the draft), or >> (proposed) in negotiation (draft-mmusic-sdp-something). > here the link to the draft that propose SDP negotiation for datachannel > http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02 > > the authors are working on a new version that will include the result > of the so far discussion on the issue. > If you are interested on it please contribute in the mmusic mailing list Salvatore, I hope you answer my question there about multiplexing of SCTP/DTLS with another RTP stream on a single port. I haven't seen any response to that yet. (Nov 2 question - it's almost 1 month old today) > > cheers > Salvatore > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Sat Dec 1 11:11:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D7121E809E for ; Sat, 1 Dec 2012 11:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.31 X-Spam-Level: X-Spam-Status: No, score=-101.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 e6mQEJBdc940 for ; Sat, 1 Dec 2012 11:11:08 -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 3ACD221E8039 for ; Sat, 1 Dec 2012 11:11:08 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so1480968obc.31 for ; Sat, 01 Dec 2012 11:11:07 -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=NPcl1RDXWG9SSaJTYANG5Bc7BH+f44tYj0s59JFaKIM=; b=YWz0xg2KCCyegA8HlYEtuWj3HmaOKk5djZqT+nemTQJCcvc6sspp182BED11HRLoU3 XklOWqksxtrhNIZxL2Vf0J3zP7bpWtBFMuA2jAE0T3EJdvbQycIr6tcJ8rtu6WuN7tN/ 1EVtoRrwsOFUeZPeqOu4o+mFk6Ps3xNQNIhh5o4iObKvskB+bqUNplq8Hd7xo6t9wijg 6Em7LYTmCPVzLagoeJpczPYk5mOLkRVNdjFHTJRMI4ac6avRyfaMZtp+dqReMUcjMsKA JrVNfsyn5Luf3dPFP6GAFuEepW2aM4KK6D2McPve3Qa2WCQBzj9kSrxxzShOPoW/QZd0 kVdA== Received: by 10.60.170.10 with SMTP id ai10mr4610103oec.72.1354389067501; Sat, 01 Dec 2012 11:11:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.136.102 with HTTP; Sat, 1 Dec 2012 11:10:27 -0800 (PST) X-Originating-IP: [74.95.2.169] In-Reply-To: <50B9DB72.8050705@ericsson.com> References: <50B87606.5030802@ericsson.com> <50B90266.4030003@nostrum.com> <50B92BF8.2090303@omnitor.se> <50B93506.3090509@jesup.org> <50B9DB72.8050705@ericsson.com> From: Eric Rescorla Date: Sat, 1 Dec 2012 11:10:27 -0800 Message-ID: To: Salvatore Loreto Content-Type: multipart/alternative; boundary=bcaec54a35d4418ed504cfcf47a4 X-Gm-Message-State: ALoCoQkcLvUj4XU93XC5Q+6uwyp7tUQ6Ra/kKxrk+IaxrYpOHjgg9x3ODCGaZammobrJVc0ecrcM Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 19:11:09 -0000 --bcaec54a35d4418ed504cfcf47a4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Without taking a position on whether or not Real-Time Text is important, I really don't understand the arguments for why Data Channel isn't sufficient. It's not like the cost of gatewaying typed characters is going to be excessive and there's no reason to think that data over SCTP won't be plenty fast. Given that, I don't really see that adding a use case adds much value, since the data channel capabilities required to support this are already baked into other use cases. -Ekr On Sat, Dec 1, 2012 at 2:26 AM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > On 12/1/12 12:36 AM, Randell Jesup wrote: > >> On 11/30/2012 4:58 PM, Gunnar Hellstr=F6m wrote: >> >>> It has been said a number of times that the rtcweb data channel would b= e >>> suitable for real-time text. >>> >>> I have also seen doubts about that expressed. >>> >>> One alerting doubt was that it did not seem to have well established >>> implementations. And the protocol spec is very thick. It might take a l= ong >>> time before it is implemented with reliable function and good >>> interoperability. Right? >>> >> >> The protocol spec is tiny (draft-jesup-rtcweb-data-**protocol). If >> you're thinking SCTP, yes it's large - so are UDP and TCP, and it does a >> lot more. It's used a lot in telephony; very little on the open web. >> >> I would like to know more about the data channel. >>> >>> How much overhead is it per transmission? >>> >> >> Not a lot. The rtcweb DataChannel protocol adds nothing to a datagram. >> SCTP is slightly larger than TCP IIRC, not a lot. Ask Michael Tuexen o= r >> Randall Stewart; maintainers of SCTP and authors on the spec who are >> working with us. >> >> Is it possible to specify capability negotiation of features using the >>> data channel? >>> >> >> yes >> >> Does that require additions to the specs. >>> >> >> No, you can specify them at channel open time (see the draft), or >> (proposed) in negotiation (draft-mmusic-sdp-something). >> > here the link to the draft that propose SDP negotiation for datachannel > http://tools.ietf.org/html/**draft-ietf-mmusic-sctp-sdp-02 > > the authors are working on a new version that will include the result of > the so far discussion on the issue. > If you are interested on it please contribute in the mmusic mailing list > > cheers > Salvatore > > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --bcaec54a35d4418ed504cfcf47a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Without taking a position on whether or not Real-Time Text is
important= , I really don't understand the arguments for why Data Channel
isn't sufficient. It's not like the cost of gatewaying typed char= acters
is going to be excessive and there's no reason to think that data<= /div>
over SCTP won't be plenty fast.

Give= n that, I don't really see that adding a use case adds much
value, since the data channel capabilities required to support
th= is are already baked into other use cases.

-Ekr



On Sat, Dec 1, 20= 12 at 2:26 AM, Salvatore Loreto <salvatore.loreto@ericsson.com= > wrote:
On 12/1/12 12:36 AM, Randell Jesup wrot= e:
On 11/30/2012 4:58 PM, Gunnar Hellstr=F6m wrote:
It has been said a number of times that the rtcweb data channel would be su= itable for real-time text.

I have also seen doubts about that expressed.

One alerting doubt was that it did not seem to have well established implem= entations. And the protocol spec is very thick. It might take a long time b= efore it is implemented with reliable function and good interoperability. R= ight?

The protocol spec is tiny (draft-jesup-rtcweb-data-protocol). =A0If = you're thinking SCTP, yes it's large - so are UDP and TCP, and it d= oes a lot more. =A0It's used a lot in telephony; very little on the ope= n web.

I would like to know more about the data channel.

How much overhead is it per transmission?

Not a lot. =A0The rtcweb DataChannel protocol adds nothing to a datagram. = =A0SCTP is slightly larger than TCP IIRC, not a lot. =A0Ask Michael Tuexen = or Randall Stewart; maintainers of SCTP and authors on the spec who are wor= king with us.

Is it possible to specify capability negotiation of features using the data= channel?

yes

=A0Does that require additions to the specs.

No, you can specify them at channel open time (see the draft), or (proposed= ) in negotiation (draft-mmusic-sdp-something).
here the link to the draft that propose SDP negotiation for datachannel
http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02=

the authors are working on a new version that will include the result of th= e so far discussion on the issue.
If you are interested on it please contribute in the mmusic mailing list
cheers
Salvatore


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

--bcaec54a35d4418ed504cfcf47a4-- From mary.ietf.barnes@gmail.com Sat Dec 1 11:25:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B35E21F8D15 for ; Sat, 1 Dec 2012 11:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.552 X-Spam-Level: X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, 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 SVgQTNWX68zz for ; Sat, 1 Dec 2012 11:25:35 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0499921F8D14 for ; Sat, 1 Dec 2012 11:25:34 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1299299lah.31 for ; Sat, 01 Dec 2012 11:25:34 -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=HdaKt2s98vNUE9AKcWKeVJ1FvlHkA4Te7jccsL9KXew=; b=CYjPGizg3WtSq2uZacV+aMfZ368jPuJYNsMEoFkl6VlKuFYT9R9de/atO4hTr2KRxT P2Mio37/V5xpY+3Db74jDICRazSB/GJUC2GPXZj7T9en6bX8HL65yAtTu0rr+2iizIB9 h28+QQ6BRDKIAyuJg3hXT+mfeg62622Mokrgh9kiHC40Yin3dilV5ha5f71I2FeRfcQz TFSxGrTvRfYj4hi3E02a6Yo1PPrFJhj29U2OkjMjUKzTLRIlfIjwSGZ9PF60TDzMNRqJ 4NaGutsRp21qlFMfWZkwEcy3F+lrdnpTunVZtbdsiZhrwhSyVA4LF+C53EzX9EiPnm6r ZaMQ== MIME-Version: 1.0 Received: by 10.152.104.148 with SMTP id ge20mr4830722lab.51.1354389933760; Sat, 01 Dec 2012 11:25:33 -0800 (PST) Received: by 10.114.62.73 with HTTP; Sat, 1 Dec 2012 11:25:33 -0800 (PST) In-Reply-To: References: Date: Sat, 1 Dec 2012 13:25:33 -0600 Message-ID: From: Mary Barnes To: Ted Hardie Content-Type: multipart/alternative; boundary=f46d04071169e3a07a04cfcf7ad9 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 19:25:36 -0000 --f46d04071169e3a07a04cfcf7ad9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I have a concern about this proposal to decide later how you will divide the meeting time between the 2 groups. These are separate organizations that are having co-located meetings, but W3C requires membership and permission to attend as observers for folks that are not members. Whereas, the IETF part of the meeting is totally open. I also think this is not quite in the spirit of the policy for announcing meetings ahead of time. If you want to do this split, then I think the exact split must be decided and announced no later than the 30 day window for IETF meeting announcements. Regards, Mary. On Fri, Nov 30, 2012 at 12:17 PM, Ted Hardie wrote: > We will be holding an interim meeting, co-located with the relevant > W3C folks, on February 5th-7th, 2013 in > the Boston area. Many thanks to Hadriel Kaplan for hosting us. We > have not yet established the time split > between the groups; since one possible mechanism is for us to > alternate morning and afternoon, please plan > to be available for the full meeting time. > > regards, > > Ted Hardie, Cullen Jennings, Magnus Westerlund > > > > Details : > > Meeting site: > > Acme Packet > 100 Crosby Drive > Bedford, Massachusetts, 01730 > TEL: 1-781-328-4400 > http://www.acmepacket.com/company/contact-us/directions > > Breakfast, lunch and dinner will be provided on site. > > Hotels: > The following are 15 minutes walk and also have complimentary shuttle > service to/from Acme. > Tell them you're staying for Acme Packet and you should get the > discounted rate shown below. > This may not be cheapest possible price, though, as prices fluctuate. > > DoubleTree by Hilton Hotel > Doubletree discount price- $127 =96 corp. code 0002665706 > Boston - Bedford Glen > 44 Middlesex Turnpike > Bedford, Massachusetts, 01730 > TEL: 1-781-275-5500 > > http://doubletree3.hilton.com/en/hotels/massachusetts/doubletree-by-hilto= n-hotel-boston-bedford-glen-BOSBFDT/index.html > > Hampton Inn Bedford - Burlington > Hampton Inn discount price- $115 =96 corp. code 0002665706 > 25 Middlesex Turnpike > Billerica, Massachusetts, 01821 > TEL: 1-978-262-9977 > > http://hamptoninn3.hilton.com/en/hotels/massachusetts/hampton-inn-bedford= -burlington-BOSBIHX/index.html > > Courtyard Boston Billerica Bedford Hotel is about 3 miles away, and > also has an Acme discount and complimentary shuttle service to/from > Acme (and it's a Marriott chain as compared to Hilton): > > Courtyard Marriott (Billerica) discount price- $130 =96 corp. code ACM > 270 Concord Road > Billerica, Massachusetts 01821 > TEL: 1-978-670-7500 > > http://www.marriott.com/hotels/travel/bosbb-courtyard-boston-billerica-be= dford/ > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d04071169e3a07a04cfcf7ad9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I have a concern about this proposal to decide later how you will divide th= e meeting time between the 2 groups. =A0These are separate organizations th= at are having co-located meetings, but W3C requires membership and permissi= on to attend as observers for folks that are not members. =A0Whereas, the I= ETF part of the meeting is totally open. =A0 I also think this is not quite= in the spirit of the policy for announcing meetings ahead of time. =A0If y= ou want to do this split, then I think the exact split must be decided and = announced no later than the 30 day window for IETF meeting announcements. = =A0

Regards,
Mary.=A0
=

On Fri, Nov 30, 2012 at 12:17 PM, Ted Ha= rdie <ted.ietf@gmail.com> wrote:
We will be holding an interim meeting, co-lo= cated with the relevant
W3C folks, on February 5th-7th, 2013 in
the Boston area. =A0Many thanks to Hadriel Kaplan for hosting us. =A0We
have not yet established the time split
between the groups; since one possible mechanism is for us to
alternate morning and afternoon, please plan
to be available for the full meeting time.

regards,

Ted Hardie, Cullen Jennings, Magnus Westerlund



Details :

Meeting site:

Acme Packet
100 Crosby Drive
Bedford, Massachusetts, 01730
TEL: 1-781-328-4400
http://www.acmepacket.com/company/contact-us/directions

Breakfast, lunch and dinner will be provided on site.

Hotels:
The following =A0are 15 minutes walk and also have complimentary shuttle service to/from Acme.
Tell them you're staying for Acme Packet and you should get the
discounted rate shown below.
This may not be cheapest possible price, though, as prices fluctuate.

DoubleTree by Hilton Hotel
Doubletree discount price- $127 =96 corp. code =A00002665706
Boston - Bedford Glen
44 Middlesex Turnpike
Bedford, Massachusetts, 01730
TEL: 1-781-275-5500
= http://doubletree3.hilton.com/en/hotels/massachusetts/doubletree-by-hilton-= hotel-boston-bedford-glen-BOSBFDT/index.html

Hampton Inn Bedford - Burlington
Hampton Inn discount price- $115 =96 corp. code =A00002665706
25 Middlesex Turnpike
Billerica, Massachusetts, 01821
TEL: 1-978-262-9977
http://hamptonin= n3.hilton.com/en/hotels/massachusetts/hampton-inn-bedford-burlington-BOSBIH= X/index.html

Courtyard Boston Billerica Bedford Hotel is about 3 miles away, and
also has an Acme discount and complimentary shuttle service to/from
Acme (and it's a Marriott chain as compared to Hilton):

Courtyard Marriott (Billerica) discount price- $130 =96 corp. code ACM
270 Concord Road
Billerica, Massachusetts 01821
TEL: 1-978-670-7500
http://www.marriott.com/hotels/travel/bo= sbb-courtyard-boston-billerica-bedford/
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--f46d04071169e3a07a04cfcf7ad9-- From gunnar.hellstrom@omnitor.se Sat Dec 1 14:09:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6326621F8B2F for ; Sat, 1 Dec 2012 14:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVnQ8uGPvgwm for ; Sat, 1 Dec 2012 14:09:54 -0800 (PST) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 62B9621F8B2D for ; Sat, 1 Dec 2012 14:09:53 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Sat, 1 Dec 2012 23:09:45 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id 204663A04E for ; Sat, 1 Dec 2012 23:09:45 +0100 (CET) Message-ID: <50BA802C.3020904@omnitor.se> Date: Sat, 01 Dec 2012 23:09:48 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50B90266.4030003@nostrum.com> <50B92BF8.2090303@omnitor.se> <50B93506.3090509@jesup.org> <50B9DB72.8050705@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 22:09:55 -0000 On 2012-12-01 20:10, Eric Rescorla wrote: > Without taking a position on whether or not Real-Time Text is > important, I really don't understand the arguments for why Data Channel > isn't sufficient. It's not like the cost of gatewaying typed characters > is going to be excessive and there's no reason to think that data > over SCTP won't be plenty fast. > > Given that, I don't really see that adding a use case adds much > value, since the data channel capabilities required to support > this are already baked into other use cases. > It was just that it was natural to think about RTP transport first because RFC 4103 already is an RTP packetization and has SDP defined. Al large number of aspects have already been considered when designing RFC 4103, such as suitable reliability level, non-delivery out of order, marks if text might have been lost, robustness against packet loss bursts, multi-party aspects, action in congestion, negotiation, minimal need of feedback, so that it can be used in loosely coupled conferences, bandwidth and packet load economy, throtteling, etc. Going through all these factors and specify it suitably for a new kind of transport is not tempting. The data channel spec also says that it is for non-media transport. Thinking of real-time text as media causes a need to make exceptions. Of course I understand that it is doable. If the data channel is to be used it seems that a label to be used for real-time text needs to be standardized, and the parameters to be used to achieve suitable characteristics. The procedures for such registration does not seem to be defined yet. I also do not yet see the definitions of how transmission failures are reported. E.g. for a semi-reliable channel, how does the receiving application get informed that some data may have been lost when it gave up with retries? RFC 4103 use such information to mark the place of possible loss och text with a special character. So, there seems to be a lot to standardize and specify for real-time text in the data channel that we already have in RFC 4103 for RTP. There is one thing though that is not yet defined for RFC 4103, and that is its use with the AVPF profile that seems to be mandatory for rtcweb. If we look at the other opportunity, to enhance XMPP Instant Messaging with a real-time text mode as specified in XEP-0301 and combine that with audio and video in common sessions, how would that XMPP be best transported? Completely outside of rtcweb e.g. using BOSH and only coordinated by some common session establishment procedure? Or using a data channel, going through the work described above but for XMPP transport. I get the feeling that BOSH is the right choice. Have anyone done a coordinated combination of XMPP messaging with rtcweb video and audio? And how would a gateway then get hold of all three media in case of translation to SIP Total Conversation is needed because the other party is using that? /Gunnar From ekr@rtfm.com Sat Dec 1 14:36:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B3B1F0C67 for ; Sat, 1 Dec 2012 14:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.41 X-Spam-Level: X-Spam-Status: No, score=-102.41 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 S3AL3pPo6TCB for ; Sat, 1 Dec 2012 14:36:11 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50FAA1F0C61 for ; Sat, 1 Dec 2012 14:36:11 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so1790202oag.31 for ; Sat, 01 Dec 2012 14:36:10 -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=unzZuVjxYm133Pb9ZnArAxFkc0Puevo0CZ0ZZLZpkq4=; b=mU9VdO/Kdmbqiafb78i7qaFF+MryChAa0+5LLqRfvWuJagBsS4u/tIE2KD9d0/4ewm wiDtTg913MKZn+9IKSATLA/7+1zyJwOZo2+bZgJeQ/Ice51fS+S78Q6FEbqkAAwdoRK5 Hi3ye7a+/GHtnF1+wIczxeWFndSZY1jjJPAsytOP/abm/9TNM0/KIwYmUcj/VqwpypXx DiBSNPoFWI/hs7qNEwuQIk9vJ2dcx1Y+PqL3w2ISd/LPM2R5qoMCmlkRxUd29jItjIHc eE7TAQxxho/dVDNgzcRZOv2rjYhxCi3b65dsrXJfdt+XoTNZOg2Bjupv2K9r36Td8u02 lgBw== Received: by 10.60.27.36 with SMTP id q4mr4874062oeg.111.1354401370749; Sat, 01 Dec 2012 14:36:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.136.102 with HTTP; Sat, 1 Dec 2012 14:35:30 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <50BA802C.3020904@omnitor.se> References: <50B87606.5030802@ericsson.com> <50B90266.4030003@nostrum.com> <50B92BF8.2090303@omnitor.se> <50B93506.3090509@jesup.org> <50B9DB72.8050705@ericsson.com> <50BA802C.3020904@omnitor.se> From: Eric Rescorla Date: Sat, 1 Dec 2012 14:35:30 -0800 Message-ID: To: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= Content-Type: multipart/alternative; boundary=e89a8fb1f172963b3f04cfd22441 X-Gm-Message-State: ALoCoQkZTdOeGlHiN2LFQPx2Iau9Jqg9Js+F7FaGCSRymDBfhgI8XlHiYC+MyY4KQBFBHEZBUsUJ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 22:36:12 -0000 --e89a8fb1f172963b3f04cfd22441 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Dec 1, 2012 at 2:09 PM, Gunnar Hellstr=F6m < gunnar.hellstrom@omnitor.se> wrote: > On 2012-12-01 20:10, Eric Rescorla wrote: > >> Without taking a position on whether or not Real-Time Text is >> important, I really don't understand the arguments for why Data Channel >> isn't sufficient. It's not like the cost of gatewaying typed characters >> is going to be excessive and there's no reason to think that data >> over SCTP won't be plenty fast. >> >> Given that, I don't really see that adding a use case adds much >> value, since the data channel capabilities required to support >> this are already baked into other use cases. >> >> It was just that it was natural to think about RTP transport first > because RFC 4103 already is an RTP packetization and has SDP defined. Al > large number of aspects have already been considered when designing RFC > 4103, such as suitable reliability level, non-delivery out of order, mark= s > if text might have been lost, robustness against packet loss bursts, > multi-party aspects, action in congestion, negotiation, minimal need of > feedback, so that it can be used in loosely coupled conferences, bandwidt= h > and packet load economy, throtteling, etc. > > Going through all these factors and specify it suitably for a new kind of > transport is not tempting. > > The data channel spec also says that it is for non-media transport. > Thinking of real-time text as media causes a need to make exceptions. Of > course I understand that it is doable. > > If the data channel is to be used it seems that a label to be used for > real-time text needs to be standardized, and the parameters to be used to > achieve suitable characteristics. The procedures for such registration do= es > not seem to be defined yet. > > I also do not yet see the definitions of how transmission failures are > reported. E.g. for a semi-reliable channel, how does the receiving > application get informed that some data may have been lost when it gave u= p > with retries? RFC 4103 use such information to mark the place of possible > loss och text with a special character. > > So, there seems to be a lot to standardize and specify for real-time text > in the data channel that we already have in RFC 4103 for RTP > Most of these things don't need to specified for data channels because it already provides congestion control, reliability (optionally) and sequenced delivery (optionally). I'm sorry, I'm really not seeing the need for something new. It just seems like you're making the problem unnecessarily complicated. -Ekr --e89a8fb1f172963b3f04cfd22441 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Dec 1, 2012 at 2:09 PM, Gunnar H= ellstr=F6m <gunnar.hellstrom@omnitor.se> wrote:
On 2012-12-01 20:10, Eric Rescorla wrote:
Without taking a position on whether or not Real-Time Text is
important, I really don't understand the arguments for why Data Channel=
isn't sufficient. It's not like the cost of gatewaying typed charac= ters
is going to be excessive and there's no reason to think that data
over SCTP won't be plenty fast.

Given that, I don't really see that adding a use case adds much
value, since the data channel capabilities required to support
this are already baked into other use cases.

It was just that it was natural to think about RTP transport first because = RFC 4103 already is an RTP packetization and has SDP defined. Al large numb= er of aspects have already been considered when designing RFC 4103, such as= suitable reliability level, non-delivery out of order, marks if text might= have been lost, robustness against packet loss bursts, multi-party aspects= , action in congestion, negotiation, minimal need of feedback, so that it c= an be used in loosely coupled conferences, bandwidth and packet load econom= y, throtteling, etc.

Going through all these factors and specify it suitably for a new kind of t= ransport is not tempting.

The data channel spec also says that it is for non-media transport. Thinkin= g of real-time text as media causes a need to make exceptions. Of course I = understand that it is doable.

If the data channel is to be used it seems that a label to be used for real= -time text needs to be standardized, and the parameters to be used to achie= ve suitable characteristics. The procedures for such registration does not = seem to be defined yet.

I also do not yet see the definitions of how transmission failures are repo= rted. E.g. for a semi-reliable channel, how does the receiving application = get informed that some data may have been lost when it gave up with retries= ? RFC 4103 use such information to mark the place of possible loss och text= with a special character.

So, there seems to be a lot to standardize and specify for real-time text i= n the data channel that we already have in RFC 4103 for RTP

Most of these things don't need to specified for d= ata channels because it already
provides congestion control, reliability (optionally) and sequenced de= livery (optionally).

I'm sorry, I'm really= not seeing the need for something new. It just seems like
you= 9;re making the problem unnecessarily complicated.

-Ekr

--e89a8fb1f172963b3f04cfd22441-- From elagerway@gmail.com Sat Dec 1 14:46:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5A021F869A for ; Sat, 1 Dec 2012 14:46:31 -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 96J9zA+I-Xsg for ; Sat, 1 Dec 2012 14:46:30 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B12D21F8696 for ; Sat, 1 Dec 2012 14:46:30 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1360500lah.31 for ; Sat, 01 Dec 2012 14:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lkOco5ZXhtMDAFypSfU00MoN+hyfOHqQ+uG6vBYnUZs=; b=YkZ7H6Xk7JpkKzMxWoQ0Ee/VgAxTs/bxzaU8bRBTwMENQYLc55PpP01j+hSMXxo61u f4b4986edu8vPeMxX+ylN9BWJFMyXNOme7xgyAQi/noB4ugaflmhSear0bPoioPbOce0 vIfr6dbtkLJt9PuQg5k+rZCmzKjddzZLNuJekbuqD0noIXAArNPXG5qbQAZodfgMkMhs YpRrqFNuiE6A//tMsCKhP+SPoRPQZoQQQrgYIvADr79MApqWyV4LZ6HHNkoiHstlRu3g wcm5aZ9/joXlJ3/nusM+GtJkuHKDvr442GHRDqovbRWYSIv/x2Fw1LmDaJEOuzlJCCPe GyjQ== MIME-Version: 1.0 Received: by 10.112.87.194 with SMTP id ba2mr2593112lbb.84.1354401989199; Sat, 01 Dec 2012 14:46:29 -0800 (PST) Sender: elagerway@gmail.com Received: by 10.114.16.10 with HTTP; Sat, 1 Dec 2012 14:46:29 -0800 (PST) In-Reply-To: References: <50B87606.5030802@ericsson.com> <50B90266.4030003@nostrum.com> <50B92BF8.2090303@omnitor.se> <50B93506.3090509@jesup.org> <50B9DB72.8050705@ericsson.com> <50BA802C.3020904@omnitor.se> Date: Sat, 1 Dec 2012 14:46:29 -0800 X-Google-Sender-Auth: g4ze94yeGzybiw0hnlEdXIu1IOk Message-ID: From: Erik Lagerway To: Eric Rescorla Content-Type: multipart/alternative; boundary=f46d0401fdff7307e004cfd24985 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 22:46:31 -0000 --f46d0401fdff7307e004cfd24985 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 *Erik Lagerway | *Hookflash **** On Sat, Dec 1, 2012 at 2:35 PM, Eric Rescorla wrote: > > > On Sat, Dec 1, 2012 at 2:09 PM, Gunnar Hellstr=F6m < > gunnar.hellstrom@omnitor.se> wrote: > >> On 2012-12-01 20:10, Eric Rescorla wrote: >> >>> Without taking a position on whether or not Real-Time Text is >>> important, I really don't understand the arguments for why Data Channel >>> isn't sufficient. It's not like the cost of gatewaying typed characters >>> is going to be excessive and there's no reason to think that data >>> over SCTP won't be plenty fast. >>> >>> Given that, I don't really see that adding a use case adds much >>> value, since the data channel capabilities required to support >>> this are already baked into other use cases. >>> >>> It was just that it was natural to think about RTP transport first >> because RFC 4103 already is an RTP packetization and has SDP defined. Al >> large number of aspects have already been considered when designing RFC >> 4103, such as suitable reliability level, non-delivery out of order, mar= ks >> if text might have been lost, robustness against packet loss bursts, >> multi-party aspects, action in congestion, negotiation, minimal need of >> feedback, so that it can be used in loosely coupled conferences, bandwid= th >> and packet load economy, throtteling, etc. >> >> Going through all these factors and specify it suitably for a new kind o= f >> transport is not tempting. >> >> The data channel spec also says that it is for non-media transport. >> Thinking of real-time text as media causes a need to make exceptions. Of >> course I understand that it is doable. >> >> If the data channel is to be used it seems that a label to be used for >> real-time text needs to be standardized, and the parameters to be used t= o >> achieve suitable characteristics. The procedures for such registration d= oes >> not seem to be defined yet. >> >> I also do not yet see the definitions of how transmission failures are >> reported. E.g. for a semi-reliable channel, how does the receiving >> application get informed that some data may have been lost when it gave = up >> with retries? RFC 4103 use such information to mark the place of possibl= e >> loss och text with a special character. >> >> So, there seems to be a lot to standardize and specify for real-time tex= t >> in the data channel that we already have in RFC 4103 for RTP >> > > Most of these things don't need to specified for data channels because it > already > provides congestion control, reliability (optionally) and sequenced > delivery (optionally). > > I'm sorry, I'm really not seeing the need for something new. It just seem= s > like > you're making the problem unnecessarily complicated. > > -Ekr > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d0401fdff7307e004cfd24985 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

Erik Lagerway | Hookflash= =A0 <= /span>



On Sat, Dec 1, 2012 at 2:35 PM, Eric Res= corla <ekr@rtfm.com> wrote:


On Sat, Dec 1, 2012 at= 2:09 PM, Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor.se>= ; wrote:
On 2012-12-01 20:10, Eric Rescorla wrote:
Without taking a position on whether or not Real-Time Text is
important, I really don't understand the arguments for why Data Channel=
isn't sufficient. It's not like the cost of gatewaying typed charac= ters
is going to be excessive and there's no reason to think that data
over SCTP won't be plenty fast.

Given that, I don't really see that adding a use case adds much
value, since the data channel capabilities required to support
this are already baked into other use cases.

It was just that it was natural to think about RTP transport first because = RFC 4103 already is an RTP packetization and has SDP defined. Al large numb= er of aspects have already been considered when designing RFC 4103, such as= suitable reliability level, non-delivery out of order, marks if text might= have been lost, robustness against packet loss bursts, multi-party aspects= , action in congestion, negotiation, minimal need of feedback, so that it c= an be used in loosely coupled conferences, bandwidth and packet load econom= y, throtteling, etc.

Going through all these factors and specify it suitably for a new kind of t= ransport is not tempting.

The data channel spec also says that it is for non-media transport. Thinkin= g of real-time text as media causes a need to make exceptions. Of course I = understand that it is doable.

If the data channel is to be used it seems that a label to be used for real= -time text needs to be standardized, and the parameters to be used to achie= ve suitable characteristics. The procedures for such registration does not = seem to be defined yet.

I also do not yet see the definitions of how transmission failures are repo= rted. E.g. for a semi-reliable channel, how does the receiving application = get informed that some data may have been lost when it gave up with retries= ? RFC 4103 use such information to mark the place of possible loss och text= with a special character.

So, there seems to be a lot to standardize and specify for real-time text i= n the data channel that we already have in RFC 4103 for RTP

Most of these things don't need to specified= for data channels because it already
provides congestion control, reliability (optionally) and sequenced de= livery (optionally).

I'm sorry, I'm really= not seeing the need for something new. It just seems like
you= 9;re making the problem unnecessarily complicated.

-Ekr


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


--f46d0401fdff7307e004cfd24985-- From jim.barnett@genesyslab.com Sat Dec 1 14:59:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46EBC21F872C for ; Sat, 1 Dec 2012 14:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[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 hdJBRxpelg-X for ; Sat, 1 Dec 2012 14:59:43 -0800 (PST) Received: from service107-us.mimecast.com (service107-us.mimecast.com [207.211.31.84]) by ietfa.amsl.com (Postfix) with ESMTP id 245A421F8964 for ; Sat, 1 Dec 2012 14:59:43 -0800 (PST) Received: from webmail-us.genesyslab.com (168.75.250.3 [168.75.250.3]) (Using TLS) by service107-us.mimecast.com; Sat, 01 Dec 2012 17:59:41 -0500 Received: from GENSJZMBX01.msg.int.genesyslab.com ([fe80::c80a:d985:3cca:a5e7]) by GENSJZFE01.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Sat, 1 Dec 2012 14:59:38 -0800 From: Jim Barnett To: Eric Rescorla , =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= Thread-Topic: [rtcweb] Consensus call on Text Communication Thread-Index: AQHNztlfqmH2x1rUs0WpvX09qvP/dZgCnHiAgACiwQCAAAM7AIAAMY8AgAAKywCAAMZkAIAAkkKAgAAyHACAAAcvAP//gNAg Date: Sat, 1 Dec 2012 22:59:38 +0000 Message-ID: <57A15FAF9E58F841B2B1651FFE16D281BDEC@GENSJZMBX01.msg.int.genesyslab.com> References: <50B87606.5030802@ericsson.com> <50B90266.4030003@nostrum.com> <50B92BF8.2090303@omnitor.se> <50B93506.3090509@jesup.org> <50B9DB72.8050705@ericsson.com> <50BA802C.3020904@omnitor.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.110.233.90] MIME-Version: 1.0 X-MC-Unique: 112120117594101301 Content-Type: multipart/alternative; boundary="_000_57A15FAF9E58F841B2B1651FFE16D281BDECGENSJZMBX01msgintge_" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 22:59:44 -0000 --_000_57A15FAF9E58F841B2B1651FFE16D281BDECGENSJZMBX01msgintge_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable +1 - Jim From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Eric Rescorla Sent: Saturday, December 01, 2012 5:36 PM To: Gunnar Hellstr=F6m Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on Text Communication On Sat, Dec 1, 2012 at 2:09 PM, Gunnar Hellstr=F6m > wrote: On 2012-12-01 20:10, Eric Rescorla wrote: Without taking a position on whether or not Real-Time Text is important, I really don't understand the arguments for why Data Channel isn't sufficient. It's not like the cost of gatewaying typed characters is going to be excessive and there's no reason to think that data over SCTP won't be plenty fast. Given that, I don't really see that adding a use case adds much value, since the data channel capabilities required to support this are already baked into other use cases. It was just that it was natural to think about RTP transport first because = RFC 4103 already is an RTP packetization and has SDP defined. Al large numb= er of aspects have already been considered when designing RFC 4103, such as= suitable reliability level, non-delivery out of order, marks if text might= have been lost, robustness against packet loss bursts, multi-party aspects= , action in congestion, negotiation, minimal need of feedback, so that it c= an be used in loosely coupled conferences, bandwidth and packet load econom= y, throtteling, etc. Going through all these factors and specify it suitably for a new kind of t= ransport is not tempting. The data channel spec also says that it is for non-media transport. Thinkin= g of real-time text as media causes a need to make exceptions. Of course I = understand that it is doable. If the data channel is to be used it seems that a label to be used for real= -time text needs to be standardized, and the parameters to be used to achie= ve suitable characteristics. The procedures for such registration does not = seem to be defined yet. I also do not yet see the definitions of how transmission failures are repo= rted. E.g. for a semi-reliable channel, how does the receiving application = get informed that some data may have been lost when it gave up with retries= ? RFC 4103 use such information to mark the place of possible loss och text= with a special character. So, there seems to be a lot to standardize and specify for real-time text i= n the data channel that we already have in RFC 4103 for RTP Most of these things don't need to specified for data channels because it a= lready provides congestion control, reliability (optionally) and sequenced deliver= y (optionally). I'm sorry, I'm really not seeing the need for something new. It just seems = like you're making the problem unnecessarily complicated. -Ekr --_000_57A15FAF9E58F841B2B1651FFE16D281BDECGENSJZMBX01msgintge_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

- =          Jim

 <= /p>

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Saturday, December 01, 2012 5:36 PM
To: Gunnar Hellstr=F6m
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Consensus call on Text Communication

 

 

On Sat, Dec 1, 2012 at 2:09 PM, Gunnar Hellstr=F6m &= lt;gunnar.= hellstrom@omnitor.se> wrote:

On 2012-12-01 20:10, Eric Rescorla wrote:=

Without taking a posi= tion on whether or not Real-Time Text is
important, I really don't understand the arguments for why Data Channel
isn't sufficient. It's not like the cost of gatewaying typed characters
is going to be excessive and there's no reason to think that data
over SCTP won't be plenty fast.

Given that, I don't really see that adding a use case adds much
value, since the data channel capabilities required to support
this are already baked into other use cases.

It was just that it was natural to think about RTP t= ransport first because RFC 4103 already is an RTP packetization and has SDP= defined. Al large number of aspects have already been considered when desi= gning RFC 4103, such as suitable reliability level, non-delivery out of order, marks if text might have been lost, robu= stness against packet loss bursts, multi-party aspects, action in congestio= n, negotiation, minimal need of feedback, so that it can be used in loosely= coupled conferences, bandwidth and packet load economy, throtteling, etc.

Going through all these factors and specify it suitably for a new kind of t= ransport is not tempting.

The data channel spec also says that it is for non-media transport. Thinkin= g of real-time text as media causes a need to make exceptions. Of course I = understand that it is doable.

If the data channel is to be used it seems that a label to be used for real= -time text needs to be standardized, and the parameters to be used to achie= ve suitable characteristics. The procedures for such registration does not = seem to be defined yet.

I also do not yet see the definitions of how transmission failures are repo= rted. E.g. for a semi-reliable channel, how does the receiving application = get informed that some data may have been lost when it gave up with retries= ? RFC 4103 use such information to mark the place of possible loss och text with a special character.

So, there seems to be a lot to standardize and specify for real-time text i= n the data channel that we already have in RFC 4103 for RTP

 

Most of these things don't need to specified for dat= a channels because it already

provides congestion control, reliability (optionally= ) and sequenced delivery (optionally).

 

I'm sorry, I'm really not seeing the need for someth= ing new. It just seems like

you're making the problem unnecessarily complicated.=

 

-Ekr

 

--_000_57A15FAF9E58F841B2B1651FFE16D281BDECGENSJZMBX01msgintge_-- From gunnar.hellstrom@omnitor.se Sat Dec 1 15:32:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0B721F8C74 for ; Sat, 1 Dec 2012 15:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xW7QRtF9jpI for ; Sat, 1 Dec 2012 15:32:45 -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 DEB8421F8C71 for ; Sat, 1 Dec 2012 15:32:43 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Sun, 2 Dec 2012 00:32:34 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-03-01.atm.binero.net (Postfix) with ESMTPA id 677213A10E; Sun, 2 Dec 2012 00:32:34 +0100 (CET) Message-ID: <50BA9395.901@omnitor.se> Date: Sun, 02 Dec 2012 00:32:37 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eric Rescorla References: <50B87606.5030802@ericsson.com> <50B90266.4030003@nostrum.com> <50B92BF8.2090303@omnitor.se> <50B93506.3090509@jesup.org> <50B9DB72.8050705@ericsson.com> <50BA802C.3020904@omnitor.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070300010204000005090109" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 23:32:46 -0000 This is a multi-part message in MIME format. --------------070300010204000005090109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 2012-12-01 23:35, Eric Rescorla wrote: > > > On Sat, Dec 1, 2012 at 2:09 PM, Gunnar Hellström > > wrote: > > On 2012-12-01 20:10, Eric Rescorla wrote: > > Without taking a position on whether or not Real-Time Text is > important, I really don't understand the arguments for why > Data Channel > isn't sufficient. It's not like the cost of gatewaying typed > characters > is going to be excessive and there's no reason to think that data > over SCTP won't be plenty fast. > > Given that, I don't really see that adding a use case adds much > value, since the data channel capabilities required to support > this are already baked into other use cases. > > It was just that it was natural to think about RTP transport first > because RFC 4103 already is an RTP packetization and has SDP > defined. Al large number of aspects have already been considered > when designing RFC 4103, such as suitable reliability level, > non-delivery out of order, marks if text might have been lost, > robustness against packet loss bursts, multi-party aspects, action > in congestion, negotiation, minimal need of feedback, so that it > can be used in loosely coupled conferences, bandwidth and packet > load economy, throtteling, etc. > > Going through all these factors and specify it suitably for a new > kind of transport is not tempting. > > The data channel spec also says that it is for non-media > transport. Thinking of real-time text as media causes a need to > make exceptions. Of course I understand that it is doable. > > If the data channel is to be used it seems that a label to be used > for real-time text needs to be standardized, and the parameters to > be used to achieve suitable characteristics. The procedures for > such registration does not seem to be defined yet. > > I also do not yet see the definitions of how transmission failures > are reported. E.g. for a semi-reliable channel, how does the > receiving application get informed that some data may have been > lost when it gave up with retries? RFC 4103 use such information > to mark the place of possible loss och text with a special character. > > So, there seems to be a lot to standardize and specify for > real-time text in the data channel that we already have in RFC > 4103 for RTP > > > Most of these things don't need to specified for data channels because > it already > provides congestion control, reliability (optionally) and sequenced > delivery (optionally). > > I'm sorry, I'm really not seeing the need for something new. It just > seems like > you're making the problem unnecessarily complicated. > Maybe. For me it just looks as the real-time text RTP media was forgotten when rtcweb was first specified and that it would be easiest to just add it as it is. And the data channel looks quite under-specified yet, and will need some time before it has everything settled and sorted out. I recognize that rtcweb is in an early stage and of course we can do experimental implementations before everything is settled if some data channel implementations are available. About my questions: Is it true that a label needs to be standardized for real-time text, and the procedures for such standardization and registration are not settled? Are there error returns in the APIs on both sides for indicating that there was a gap in the data sequence when the semi-reliable data channel gave up with transmission in order to not stall the channel? --------------------- Now I read SCtP, and get the impression that the retransmission timeouts are far too long for smooth real-time text. The initial value is 3 seconds. So at least intially in the calls there will be 3 seconds hickups every time a text packet is lost. ( I did not take time to decode how far down this figure is adjusted if roundtrip time is short, maybe this is just an initial problem... ) The redundancy used in RFC 4103 is very inexpensive and rapid. During continued typing, earlier text is sent together with next text packet after the sample time. So, 300 ms after expected first reception, next transmission of the same text is received together with new text. It just costs a few more bytes per packet. If first redundant transmission fails, one more opportunity appears 300 ms later. That creates a smoother media flow even on quite bad connections. Gunnar --------------070300010204000005090109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2012-12-01 23:35, Eric Rescorla wrote:


On Sat, Dec 1, 2012 at 2:09 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:
On 2012-12-01 20:10, Eric Rescorla wrote:
Without taking a position on whether or not Real-Time Text is
important, I really don't understand the arguments for why Data Channel
isn't sufficient. It's not like the cost of gatewaying typed characters
is going to be excessive and there's no reason to think that data
over SCTP won't be plenty fast.

Given that, I don't really see that adding a use case adds much
value, since the data channel capabilities required to support
this are already baked into other use cases.

It was just that it was natural to think about RTP transport first because RFC 4103 already is an RTP packetization and has SDP defined. Al large number of aspects have already been considered when designing RFC 4103, such as suitable reliability level, non-delivery out of order, marks if text might have been lost, robustness against packet loss bursts, multi-party aspects, action in congestion, negotiation, minimal need of feedback, so that it can be used in loosely coupled conferences, bandwidth and packet load economy, throtteling, etc.

Going through all these factors and specify it suitably for a new kind of transport is not tempting.

The data channel spec also says that it is for non-media transport. Thinking of real-time text as media causes a need to make exceptions. Of course I understand that it is doable.

If the data channel is to be used it seems that a label to be used for real-time text needs to be standardized, and the parameters to be used to achieve suitable characteristics. The procedures for such registration does not seem to be defined yet.

I also do not yet see the definitions of how transmission failures are reported. E.g. for a semi-reliable channel, how does the receiving application get informed that some data may have been lost when it gave up with retries? RFC 4103 use such information to mark the place of possible loss och text with a special character.

So, there seems to be a lot to standardize and specify for real-time text in the data channel that we already have in RFC 4103 for RTP

Most of these things don't need to specified for data channels because it already
provides congestion control, reliability (optionally) and sequenced delivery (optionally).

I'm sorry, I'm really not seeing the need for something new. It just seems like
you're making the problem unnecessarily complicated.

Maybe. For me it just looks as the real-time text RTP media was forgotten when rtcweb was first specified and that it would be easiest to just add it as it is.

And the data channel looks quite under-specified yet, and will need some time before it has everything settled and sorted out. I recognize that rtcweb is in an early stage and of course we can do experimental implementations before everything is settled if some data channel implementations are available.  

About my questions:

Is it true that a label needs to be standardized for real-time text, and the procedures for such standardization and registration are not settled?

Are there error returns in the APIs on both sides for indicating that there was a gap in the data sequence when the semi-reliable data channel gave up with transmission in order to not stall the channel?

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

Now I read SCtP, and get the impression that the retransmission timeouts are far too long for smooth real-time text. The initial value is 3 seconds. So at least intially in the calls there will be 3 seconds hickups every time a text packet is lost. ( I did not take time to decode how far down this figure is adjusted if roundtrip time is short, maybe this is just an initial problem... )

The redundancy used in RFC 4103 is very inexpensive and rapid. During continued typing, earlier text is sent together with next text packet after the sample time. So, 300 ms after expected first reception, next transmission of the same text is received together with new text. It just costs a few more bytes per packet. If first redundant transmission  fails, one more opportunity appears 300 ms later.  That creates a smoother media flow even on quite bad connections.

Gunnar
--------------070300010204000005090109-- From Michael.Tuexen@lurchi.franken.de Sat Dec 1 16:21:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EEC21F869F for ; Sat, 1 Dec 2012 16:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCyEVZdUGS3U for ; Sat, 1 Dec 2012 16:21:36 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id CB7A721F869E for ; Sat, 1 Dec 2012 16:21:33 -0800 (PST) Received: from [192.168.1.103] (p5481AB02.dip.t-dialin.net [84.129.171.2]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 303CB1C0C069E; Sun, 2 Dec 2012 01:21:30 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: <50BA9395.901@omnitor.se> Date: Sun, 2 Dec 2012 01:21:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <05C35A21-C23E-40F3-86F3-CF08E3D35C46@lurchi.franken.de> References: <50B87606.5030802@ericsson.com> <50B90266.4030003@nostrum.com> <50B92BF8.2090303@omnitor.se> <50B93506.3090509@jesup.org> <50B9DB72.8050705@ericsson.com> <50BA802C.3020904@omnitor.se> <50BA9395.901@omnitor.se> To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= X-Mailer: Apple Mail (2.1283) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Dec 2012 00:21:39 -0000 On Dec 2, 2012, at 12:32 AM, Gunnar Hellstr=F6m wrote: > On 2012-12-01 23:35, Eric Rescorla wrote: >>=20 >>=20 >> On Sat, Dec 1, 2012 at 2:09 PM, Gunnar Hellstr=F6m = wrote: >> On 2012-12-01 20:10, Eric Rescorla wrote: >> Without taking a position on whether or not Real-Time Text is >> important, I really don't understand the arguments for why Data = Channel >> isn't sufficient. It's not like the cost of gatewaying typed = characters >> is going to be excessive and there's no reason to think that data >> over SCTP won't be plenty fast. >>=20 >> Given that, I don't really see that adding a use case adds much >> value, since the data channel capabilities required to support >> this are already baked into other use cases. >>=20 >> It was just that it was natural to think about RTP transport first = because RFC 4103 already is an RTP packetization and has SDP defined. Al = large number of aspects have already been considered when designing RFC = 4103, such as suitable reliability level, non-delivery out of order, = marks if text might have been lost, robustness against packet loss = bursts, multi-party aspects, action in congestion, negotiation, minimal = need of feedback, so that it can be used in loosely coupled conferences, = bandwidth and packet load economy, throtteling, etc. >>=20 >> Going through all these factors and specify it suitably for a new = kind of transport is not tempting. >>=20 >> The data channel spec also says that it is for non-media transport. = Thinking of real-time text as media causes a need to make exceptions. Of = course I understand that it is doable. >>=20 >> If the data channel is to be used it seems that a label to be used = for real-time text needs to be standardized, and the parameters to be = used to achieve suitable characteristics. The procedures for such = registration does not seem to be defined yet. >>=20 >> I also do not yet see the definitions of how transmission failures = are reported. E.g. for a semi-reliable channel, how does the receiving = application get informed that some data may have been lost when it gave = up with retries? RFC 4103 use such information to mark the place of = possible loss och text with a special character. >>=20 >> So, there seems to be a lot to standardize and specify for real-time = text in the data channel that we already have in RFC 4103 for = RTP >>=20 >> Most of these things don't need to specified for data channels = because it already >> provides congestion control, reliability (optionally) and sequenced = delivery (optionally). >>=20 >> I'm sorry, I'm really not seeing the need for something new. It just = seems like >> you're making the problem unnecessarily complicated. >>=20 > Maybe. For me it just looks as the real-time text RTP media was = forgotten when rtcweb was first specified and that it would be = easiest to just add it as it is. >=20 > And the data channel looks quite under-specified yet, and will need = some time before it has everything settled and sorted out. I recognize = that rtcweb is in an early stage and of course we can do experimental = implementations before everything is settled if some data channel = implementations are available. =20 >=20 > About my questions: >=20 > Is it true that a label needs to be standardized for real-time text, = and the procedures for such standardization and registration are not = settled? >=20 > Are there error returns in the APIs on both sides for indicating that = there was a gap in the data sequence when the semi-reliable data channel = gave up with transmission in order to not stall the channel? When using ordered delivery in SCTP, the socket API can give you the = stream sequence number. If you are using PR-SCTP, the receiver can observe this sequence number and = figure out that messages have been abandoned. I think this is currently information is not = provided by the JS API. Maybe that can be added as an optional argument to the onmessage event = handler for ordered data channels. >=20 > --------------------- >=20 > Now I read SCtP, and get the impression that the retransmission = timeouts are far too long for smooth real-time text. The initial value = is 3 seconds. So at least intially in the calls there will be 3 seconds = hickups every time a text packet is lost. ( I did not take time to = decode how far down this figure is adjusted if roundtrip time is short, = maybe this is just an initial problem... ) Yes, this is the initial value in the RFC. As soon as there are round = trip time measurements, they are used. The FreeBSD implementation uses already the association setup = messages for updates. So timer based data retransmissions would be based on the round trip = time measurements (within RTO.min RTO.max). Please note that for a single packet loss and continued typing = a fast retransmit would be triggered most likely. Best regards Michael >=20 > The redundancy used in RFC 4103 is very inexpensive and rapid. During = continued typing, earlier text is sent together with next text packet = after the sample time. So, 300 ms after expected first reception, next = transmission of the same text is received together with new text. It = just costs a few more bytes per packet. If first redundant transmission = fails, one more opportunity appears 300 ms later. That creates a = smoother media flow even on quite bad connections. >=20 > Gunnar=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Sat Dec 1 23:53:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C267321F8FD0 for ; Sat, 1 Dec 2012 23:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 E5Vy0TZLKOWQ for ; Sat, 1 Dec 2012 23:53:18 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id E93EF21F8EB7 for ; Sat, 1 Dec 2012 23:53:17 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:3453 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Tf4MX-0000Ie-5Y for rtcweb@ietf.org; Sun, 02 Dec 2012 01:53:17 -0600 Message-ID: <50BB08C5.1020106@jesup.org> Date: Sun, 02 Dec 2012 02:52:37 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50B90266.4030003@nostrum.com> <50B92BF8.2090303@omnitor.se> <50B93506.3090509@jesup.org> <50B9DB72.8050705@ericsson.com> <50BA802C.3020904@omnitor.se> <50BA9395.901@omnitor.se> In-Reply-To: <50BA9395.901@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Dec 2012 07:53:18 -0000 On 12/1/2012 6:32 PM, Gunnar Hellström wrote: > > And the data channel looks quite under-specified yet, and will need > some time before it has everything settled and sorted out. I recognize > that rtcweb is in an early stage and of course we can do experimental > implementations before everything is settled if some data channel > implementations are available. See http://mozilla.github.com/webrtc-landing/data_test.html in Firefox Nightly. The JS code for all the call setup is ugly, but the Datachannels are pretty simple to use. Replace {} in createDataChannel() with {outOfOrderAllowed : true, maxRetransmitNum : 0} for the equivalent of UDP. > > About my questions: > > Is it true that a label needs to be standardized for real-time text, > and the procedures for such standardization and registration are not > settled? Yes, and at IETF-85 I proposed (and there seemed to be consensus for) adding a 'protocol' field similar to WebSocket's, which is what you'd want to standardize for. (Side benefit: it would help standardize transmission over WebSockets as well, which have an almost identical API (on purpose)). > > Are there error returns in the APIs on both sides for indicating that > there was a gap in the data sequence when the semi-reliable data > channel gave up with transmission in order to not stall the channel? Not currently. We've planned on adding optional attributes to incoming messages with information, but one problem is that just reporting a sequence number doesn't tell you if the *stream* lost a packet, as the sequence numbers are shared across all streams. Short answer: if you're using partial or no reliability (or reliable out-of-order), you'll need to include in the application protocol a sequence number if you care about them. We might still be persuaded to re-frame the datagrams with a header with a sequence number/etc; we've avoided doing so thus far to simplify transmission/reception re-framing. > The redundancy used in RFC 4103 is very inexpensive and rapid. During > continued typing, earlier text is sent together with next text packet > after the sample time. So, 300 ms after expected first reception, next > transmission of the same text is received together with new text. It > just costs a few more bytes per packet. If first redundant > transmission fails, one more opportunity appears 300 ms later. That > creates a smoother media flow even on quite bad connections. If you decide to use partially-reliable connections, you could still use that if you want. In many cases, I suspect PR-SCTP retransmission might beat a 300ms redundancy implementation in speed of correction, but you can do both if you want. And "quite bad connections" are usually today low bandwidth and high delay or total packet loss for significant periods, not high (random) packet loss. (i.e. WiFi with a poor signal). -- Randell Jesup randell-ietf@jesup.org From Michael.Tuexen@lurchi.franken.de Sun Dec 2 01:00:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3479B21F8D36 for ; Sun, 2 Dec 2012 01:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 qqKMzwvAOEJ7 for ; Sun, 2 Dec 2012 01:00:27 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id D5CB721F8D35 for ; Sun, 2 Dec 2012 01:00:26 -0800 (PST) Received: from [192.168.1.103] (p5481AB02.dip.t-dialin.net [84.129.171.2]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id F23951C0C0693; Sun, 2 Dec 2012 10:00:23 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: <50BB08C5.1020106@jesup.org> Date: Sun, 2 Dec 2012 10:00:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0B9AF20D-C8D8-4557-847F-79E647B3991F@lurchi.franken.de> References: <50B87606.5030802@ericsson.com> <50B90266.4030003@nostrum.com> <50B92BF8.2090303@omnitor.se> <50B93506.3090509@jesup.org> <50B9DB72.8050705@ericsson.com> <50BA802C.3020904@omnitor.se> <50BA9395.901@omnitor.se> <50BB08C5.1020106@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1283) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Dec 2012 09:00:28 -0000 On Dec 2, 2012, at 8:52 AM, Randell Jesup wrote: > On 12/1/2012 6:32 PM, Gunnar Hellstr=F6m wrote: >>=20 >> And the data channel looks quite under-specified yet, and will need = some time before it has everything settled and sorted out. I recognize = that rtcweb is in an early stage and of course we can do experimental = implementations before everything is settled if some data channel = implementations are available. >=20 > See http://mozilla.github.com/webrtc-landing/data_test.html in Firefox = Nightly. The JS code for all the call setup is ugly, but the = Datachannels are pretty simple to use. >=20 > Replace {} in createDataChannel() with {outOfOrderAllowed : true, = maxRetransmitNum : 0} for the equivalent of UDP. >=20 >>=20 >> About my questions: >>=20 >> Is it true that a label needs to be standardized for real-time text, = and the procedures for such standardization and registration are not = settled? >=20 > Yes, and at IETF-85 I proposed (and there seemed to be consensus for) = adding a 'protocol' field similar to WebSocket's, which is what you'd = want to standardize for. (Side benefit: it would help standardize = transmission over WebSockets as well, which have an almost identical API = (on purpose)). >=20 >>=20 >> Are there error returns in the APIs on both sides for indicating that = there was a gap in the data sequence when the semi-reliable data channel = gave up with transmission in order to not stall the channel? >=20 > Not currently. We've planned on adding optional attributes to = incoming messages with information, but one problem is that just = reporting a sequence number doesn't tell you if the *stream* lost a = packet, as the sequence numbers are shared across all streams. Short = answer: if you're using partial or no reliability (or reliable = out-of-order), you'll need to include in the application protocol a = sequence number if you care about them. You are right, SCTP uses a sequence number called TSN, which is shared = between all streams and exposing this to the JS use is of limited use. But SCTP has also a = sequence number called SSN for ordered messages within each stream. So for ordered data channels (no matter if reliable or not) we can = expose this number and for each data channel it would start with 0. It is a 16 bit counter and = the receiver can deduce that messages have been abandoned, if the number increments by = more than one. For unordered data channels this number can't be provided, since = messages are delivered to user as they are received and the sender indicates that ordering is not = important. Best regards Michael >=20 > We might still be persuaded to re-frame the datagrams with a header = with a sequence number/etc; we've avoided doing so thus far to simplify = transmission/reception re-framing. >=20 >> The redundancy used in RFC 4103 is very inexpensive and rapid. During = continued typing, earlier text is sent together with next text packet = after the sample time. So, 300 ms after expected first reception, next = transmission of the same text is received together with new text. It = just costs a few more bytes per packet. If first redundant transmission = fails, one more opportunity appears 300 ms later. That creates a = smoother media flow even on quite bad connections. >=20 > If you decide to use partially-reliable connections, you could still = use that if you want. In many cases, I suspect PR-SCTP retransmission = might beat a 300ms redundancy implementation in speed of correction, but = you can do both if you want. And "quite bad connections" are usually = today low bandwidth and high delay or total packet loss for significant = periods, not high (random) packet loss. (i.e. WiFi with a poor signal). >=20 > --=20 > Randell Jesup > randell-ietf@jesup.org >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From gunnar.hellstrom@omnitor.se Sun Dec 2 01:28:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F7721F8A83 for ; Sun, 2 Dec 2012 01:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0vgUz0zfI5U for ; Sun, 2 Dec 2012 01:28:49 -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 7D32C21F8A7A for ; Sun, 2 Dec 2012 01:28:47 -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 ; Sun, 2 Dec 2012 10:27:58 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id 57F443A181 for ; Sun, 2 Dec 2012 10:27:58 +0100 (CET) Message-ID: <50BB1F22.8000404@omnitor.se> Date: Sun, 02 Dec 2012 10:28:02 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50B90266.4030003@nostrum.com> <50B92BF8.2090303@omnitor.se> <50B93506.3090509@jesup.org> <50B9DB72.8050705@ericsson.com> <50BA802C.3020904@omnitor.se> <50BA9395.901@omnitor.se> <50BB08C5.1020106@jesup.org> In-Reply-To: <50BB08C5.1020106@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Dec 2012 09:28:49 -0000 On 2012-12-02 08:52, Randell Jesup wrote: > > If you decide to use partially-reliable connections, you could still > use that if you want. In many cases, I suspect PR-SCTP retransmission > might beat a 300ms redundancy implementation in speed of correction, > but you can do both if you want. And "quite bad connections" are > usually today low bandwidth and high delay or total packet loss for > significant periods, not high (random) packet loss. (i.e. WiFi with a > poor signal). Yes, I realize that hickups or short blocking occurring now and then should not be a blocking factor for transport selection for real-time text. Hickups and short pauses occur also naturally in human typing, scratching an itching spot, looking up at a bird flying by etc. So they are accepted by receiving parties. Thus, a partially-reliable data channel is likely still among the possible alternative transports for real-time text. /Gunnar From harald@alvestrand.no Sun Dec 2 04:01:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9A821F8D4A for ; Sun, 2 Dec 2012 04:01:48 -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 0undEfCWGfBl for ; Sun, 2 Dec 2012 04:01:43 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6668E21F8D47 for ; Sun, 2 Dec 2012 04:01:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 09CE539E1BD for ; Sun, 2 Dec 2012 10:55: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 XQqM5rfuMOtI for ; Sun, 2 Dec 2012 10:55:18 +0100 (CET) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 57C1039E12F for ; Sun, 2 Dec 2012 10:55:18 +0100 (CET) Message-ID: <50BB2586.8080706@alvestrand.no> Date: Sun, 02 Dec 2012 10:55:18 +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: <50B87606.5030802@ericsson.com> <50B90266.4030003@nostrum.com> <50B92BF8.2090303@omnitor.se> <50B93506.3090509@jesup.org> <50B9DB72.8050705@ericsson.com> <50BA802C.3020904@omnitor.se> <50BA9395.901@omnitor.se> In-Reply-To: <50BA9395.901@omnitor.se> Content-Type: multipart/alternative; boundary="------------030303070802070102020008" Subject: [rtcweb] Sanity plea: change subject! (Re: Consensus call on Text Communication) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Dec 2012 12:01:48 -0000 This is a multi-part message in MIME format. --------------030303070802070102020008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Having been in the position counter's seat before..... When replying to a consensus call response with a note that doesn't state a new position, but instead goes into long arguments about the issue at hand, or even diverts off into completely new avenues, please CHANGE THE SUBJECT! Harald On 12/02/2012 12:32 AM, Gunnar Hellström wrote: > On 2012-12-01 23:35, Eric Rescorla wrote: >> >> >> On Sat, Dec 1, 2012 at 2:09 PM, Gunnar Hellström >> > wrote: >> >> On 2012-12-01 20:10, Eric Rescorla wrote: >> >> Without taking a position on whether or not Real-Time Text is >> important, I really don't understand the arguments for why >> Data Channel >> isn't sufficient. It's not like the cost of gatewaying typed >> characters >> is going to be excessive and there's no reason to think that data >> over SCTP won't be plenty fast. >> >> Given that, I don't really see that adding a use case adds much >> value, since the data channel capabilities required to support >> this are already baked into other use cases. >> >> It was just that it was natural to think about RTP transport >> first because RFC 4103 already is an RTP packetization and has >> SDP defined. Al large number of aspects have already been >> considered when designing RFC 4103, such as suitable reliability >> level, non-delivery out of order, marks if text might have been >> lost, robustness against packet loss bursts, multi-party aspects, >> action in congestion, negotiation, minimal need of feedback, so >> that it can be used in loosely coupled conferences, bandwidth and >> packet load economy, throtteling, etc. >> >> Going through all these factors and specify it suitably for a new >> kind of transport is not tempting. >> >> The data channel spec also says that it is for non-media >> transport. Thinking of real-time text as media causes a need to >> make exceptions. Of course I understand that it is doable. >> >> If the data channel is to be used it seems that a label to be >> used for real-time text needs to be standardized, and the >> parameters to be used to achieve suitable characteristics. The >> procedures for such registration does not seem to be defined yet. >> >> I also do not yet see the definitions of how transmission >> failures are reported. E.g. for a semi-reliable channel, how does >> the receiving application get informed that some data may have >> been lost when it gave up with retries? RFC 4103 use such >> information to mark the place of possible loss och text with a >> special character. >> >> So, there seems to be a lot to standardize and specify for >> real-time text in the data channel that we already have in RFC >> 4103 for RTP >> >> >> Most of these things don't need to specified for data channels >> because it already >> provides congestion control, reliability (optionally) and sequenced >> delivery (optionally). >> >> I'm sorry, I'm really not seeing the need for something new. It just >> seems like >> you're making the problem unnecessarily complicated. >> > Maybe. For me it just looks as the real-time text RTP media was > forgotten when rtcweb was first specified and that it would be easiest > to just add it as it is. > > And the data channel looks quite under-specified yet, and will need > some time before it has everything settled and sorted out. I recognize > that rtcweb is in an early stage and of course we can do experimental > implementations before everything is settled if some data channel > implementations are available. > > About my questions: > > Is it true that a label needs to be standardized for real-time text, > and the procedures for such standardization and registration are not > settled? > > Are there error returns in the APIs on both sides for indicating that > there was a gap in the data sequence when the semi-reliable data > channel gave up with transmission in order to not stall the channel? > > --------------------- > > Now I read SCtP, and get the impression that the retransmission > timeouts are far too long for smooth real-time text. The initial value > is 3 seconds. So at least intially in the calls there will be 3 > seconds hickups every time a text packet is lost. ( I did not take > time to decode how far down this figure is adjusted if roundtrip time > is short, maybe this is just an initial problem... ) > > The redundancy used in RFC 4103 is very inexpensive and rapid. During > continued typing, earlier text is sent together with next text packet > after the sample time. So, 300 ms after expected first reception, next > transmission of the same text is received together with new text. It > just costs a few more bytes per packet. If first redundant > transmission fails, one more opportunity appears 300 ms later. That > creates a smoother media flow even on quite bad connections. > > Gunnar > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------030303070802070102020008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Having been in the position counter's seat before.....

When replying to a consensus call response with a note that doesn't state a new position, but instead goes into long arguments about the issue at hand, or even diverts off into completely new avenues, please CHANGE THE SUBJECT!

       Harald

On 12/02/2012 12:32 AM, Gunnar Hellström wrote:
On 2012-12-01 23:35, Eric Rescorla wrote:


On Sat, Dec 1, 2012 at 2:09 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:
On 2012-12-01 20:10, Eric Rescorla wrote:
Without taking a position on whether or not Real-Time Text is
important, I really don't understand the arguments for why Data Channel
isn't sufficient. It's not like the cost of gatewaying typed characters
is going to be excessive and there's no reason to think that data
over SCTP won't be plenty fast.

Given that, I don't really see that adding a use case adds much
value, since the data channel capabilities required to support
this are already baked into other use cases.

It was just that it was natural to think about RTP transport first because RFC 4103 already is an RTP packetization and has SDP defined. Al large number of aspects have already been considered when designing RFC 4103, such as suitable reliability level, non-delivery out of order, marks if text might have been lost, robustness against packet loss bursts, multi-party aspects, action in congestion, negotiation, minimal need of feedback, so that it can be used in loosely coupled conferences, bandwidth and packet load economy, throtteling, etc.

Going through all these factors and specify it suitably for a new kind of transport is not tempting.

The data channel spec also says that it is for non-media transport. Thinking of real-time text as media causes a need to make exceptions. Of course I understand that it is doable.

If the data channel is to be used it seems that a label to be used for real-time text needs to be standardized, and the parameters to be used to achieve suitable characteristics. The procedures for such registration does not seem to be defined yet.

I also do not yet see the definitions of how transmission failures are reported. E.g. for a semi-reliable channel, how does the receiving application get informed that some data may have been lost when it gave up with retries? RFC 4103 use such information to mark the place of possible loss och text with a special character.

So, there seems to be a lot to standardize and specify for real-time text in the data channel that we already have in RFC 4103 for RTP

Most of these things don't need to specified for data channels because it already
provides congestion control, reliability (optionally) and sequenced delivery (optionally).

I'm sorry, I'm really not seeing the need for something new. It just seems like
you're making the problem unnecessarily complicated.

Maybe. For me it just looks as the real-time text RTP media was forgotten when rtcweb was first specified and that it would be easiest to just add it as it is.

And the data channel looks quite under-specified yet, and will need some time before it has everything settled and sorted out. I recognize that rtcweb is in an early stage and of course we can do experimental implementations before everything is settled if some data channel implementations are available.  

About my questions:

Is it true that a label needs to be standardized for real-time text, and the procedures for such standardization and registration are not settled?

Are there error returns in the APIs on both sides for indicating that there was a gap in the data sequence when the semi-reliable data channel gave up with transmission in order to not stall the channel?

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

Now I read SCtP, and get the impression that the retransmission timeouts are far too long for smooth real-time text. The initial value is 3 seconds. So at least intially in the calls there will be 3 seconds hickups every time a text packet is lost. ( I did not take time to decode how far down this figure is adjusted if roundtrip time is short, maybe this is just an initial problem... )

The redundancy used in RFC 4103 is very inexpensive and rapid. During continued typing, earlier text is sent together with next text packet after the sample time. So, 300 ms after expected first reception, next transmission of the same text is received together with new text. It just costs a few more bytes per packet. If first redundant transmission  fails, one more opportunity appears 300 ms later.  That creates a smoother media flow even on quite bad connections.

Gunnar 


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

--------------030303070802070102020008-- From harald@alvestrand.no Sun Dec 2 04:21:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579E521F8D55 for ; Sun, 2 Dec 2012 04:21: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=[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 OrwSpJ3uC5X2 for ; Sun, 2 Dec 2012 04:21:43 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E38B421F8D4A for ; Sun, 2 Dec 2012 04:21:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6925939E166 for ; Sun, 2 Dec 2012 10:52:39 +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 JwsYVB7pBusl for ; Sun, 2 Dec 2012 10:52:36 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:4977:95e8:5532:be2e] (unknown [IPv6:2001:470:de0a:27:4977:95e8:5532:be2e]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id AEFA939E12F for ; Sun, 2 Dec 2012 10:52:36 +0100 (CET) Message-ID: <50BB24E3.2080902@alvestrand.no> Date: Sun, 02 Dec 2012 10:52:35 +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: multipart/alternative; boundary="------------020708010603010001090105" Subject: Re: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Dec 2012 12:21:49 -0000 This is a multi-part message in MIME format. --------------020708010603010001090105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/01/2012 08:25 PM, Mary Barnes wrote: > I have a concern about this proposal to decide later how you will > divide the meeting time between the 2 groups. These are separate > organizations that are having co-located meetings, but W3C requires > membership and permission to attend as observers for folks that are > not members. Whereas, the IETF part of the meeting is totally open. Speaking as W3C chair: The chairs get to decide whether people can attend as observers, and so far, we haven't turned down a request. We do operate within that ruleset, but we're trying to minimize the damage from it. > I also think this is not quite in the spirit of the policy for > announcing meetings ahead of time. If you want to do this split, then > I think the exact split must be decided and announced no later than > the 30 day window for IETF meeting announcements. I don't think there's a problem in nailing down the split before Jan 5. The driving deadline that meant we had to announce the dates *now* was the squeeze between the W3C requirement for face to face meetings to be announced 8 weeks beforehand and the IETF's requirement for interim meetings to be at least 4 weeks away from "real" IETF meetings. > > Regards, > Mary. > > > On Fri, Nov 30, 2012 at 12:17 PM, Ted Hardie > wrote: > > We will be holding an interim meeting, co-located with the relevant > W3C folks, on February 5th-7th, 2013 in > the Boston area. Many thanks to Hadriel Kaplan for hosting us. We > have not yet established the time split > between the groups; since one possible mechanism is for us to > alternate morning and afternoon, please plan > to be available for the full meeting time. > > regards, > > Ted Hardie, Cullen Jennings, Magnus Westerlund > > > > Details : > > Meeting site: > > Acme Packet > 100 Crosby Drive > Bedford, Massachusetts, 01730 > TEL: 1-781-328-4400 > http://www.acmepacket.com/company/contact-us/directions > > Breakfast, lunch and dinner will be provided on site. > > Hotels: > The following are 15 minutes walk and also have complimentary shuttle > service to/from Acme. > Tell them you're staying for Acme Packet and you should get the > discounted rate shown below. > This may not be cheapest possible price, though, as prices fluctuate. > > DoubleTree by Hilton Hotel > Doubletree discount price- $127 -- corp. code 0002665706 > Boston - Bedford Glen > 44 Middlesex Turnpike > Bedford, Massachusetts, 01730 > TEL: 1-781-275-5500 > http://doubletree3.hilton.com/en/hotels/massachusetts/doubletree-by-hilton-hotel-boston-bedford-glen-BOSBFDT/index.html > > Hampton Inn Bedford - Burlington > Hampton Inn discount price- $115 -- corp. code 0002665706 > 25 Middlesex Turnpike > Billerica, Massachusetts, 01821 > TEL: 1-978-262-9977 > http://hamptoninn3.hilton.com/en/hotels/massachusetts/hampton-inn-bedford-burlington-BOSBIHX/index.html > > Courtyard Boston Billerica Bedford Hotel is about 3 miles away, and > also has an Acme discount and complimentary shuttle service to/from > Acme (and it's a Marriott chain as compared to Hilton): > > Courtyard Marriott (Billerica) discount price- $130 -- corp. code ACM > 270 Concord Road > Billerica, Massachusetts 01821 > TEL: 1-978-670-7500 > http://www.marriott.com/hotels/travel/bosbb-courtyard-boston-billerica-bedford/ > _______________________________________________ > 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 --------------020708010603010001090105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/01/2012 08:25 PM, Mary Barnes wrote:
I have a concern about this proposal to decide later how you will divide the meeting time between the 2 groups.  These are separate organizations that are having co-located meetings, but W3C requires membership and permission to attend as observers for folks that are not members.  Whereas, the IETF part of the meeting is totally open.
Speaking as W3C chair: The chairs get to decide whether people can attend as observers, and so far, we haven't turned down a request. We do operate within that ruleset, but we're trying to minimize the damage from it.
  I also think this is not quite in the spirit of the policy for announcing meetings ahead of time.  If you want to do this split, then I think the exact split must be decided and announced no later than the 30 day window for IETF meeting announcements. 
I don't think there's a problem in nailing down the split before Jan 5. The driving deadline that meant we had to announce the dates *now* was the squeeze between the W3C requirement for face to face meetings to be announced 8 weeks beforehand and the IETF's requirement for interim meetings to be at least 4 weeks away from "real" IETF meetings.


Regards,
Mary. 


On Fri, Nov 30, 2012 at 12:17 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
We will be holding an interim meeting, co-located with the relevant
W3C folks, on February 5th-7th, 2013 in
the Boston area.  Many thanks to Hadriel Kaplan for hosting us.  We
have not yet established the time split
between the groups; since one possible mechanism is for us to
alternate morning and afternoon, please plan
to be available for the full meeting time.

regards,

Ted Hardie, Cullen Jennings, Magnus Westerlund



Details :

Meeting site:

Acme Packet
100 Crosby Drive
Bedford, Massachusetts, 01730
TEL: 1-781-328-4400
http://www.acmepacket.com/company/contact-us/directions

Breakfast, lunch and dinner will be provided on site.

Hotels:
The following  are 15 minutes walk and also have complimentary shuttle
service to/from Acme.
Tell them you're staying for Acme Packet and you should get the
discounted rate shown below.
This may not be cheapest possible price, though, as prices fluctuate.

DoubleTree by Hilton Hotel
Doubletree discount price- $127 – corp. code  0002665706
Boston - Bedford Glen
44 Middlesex Turnpike
Bedford, Massachusetts, 01730
TEL: 1-781-275-5500
http://doubletree3.hilton.com/en/hotels/massachusetts/doubletree-by-hilton-hotel-boston-bedford-glen-BOSBFDT/index.html

Hampton Inn Bedford - Burlington
Hampton Inn discount price- $115 – corp. code  0002665706
25 Middlesex Turnpike
Billerica, Massachusetts, 01821
TEL: 1-978-262-9977
http://hamptoninn3.hilton.com/en/hotels/massachusetts/hampton-inn-bedford-burlington-BOSBIHX/index.html

Courtyard Boston Billerica Bedford Hotel is about 3 miles away, and
also has an Acme discount and complimentary shuttle service to/from
Acme (and it's a Marriott chain as compared to Hilton):

Courtyard Marriott (Billerica) discount price- $130 – corp. code ACM
270 Concord Road
Billerica, Massachusetts 01821
TEL: 1-978-670-7500
http://www.marriott.com/hotels/travel/bosbb-courtyard-boston-billerica-bedford/
_______________________________________________
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

--------------020708010603010001090105-- From stefan.lk.hakansson@ericsson.com Sun Dec 2 05:49:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCD321F8770 for ; Sun, 2 Dec 2012 05:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 GAVI3VoTwfrg for ; Sun, 2 Dec 2012 05:49:24 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A00F621F8764 for ; Sun, 2 Dec 2012 05:49:23 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-f5-50bb22eb9d8f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 72.31.11564.BE22BB05; Sun, 2 Dec 2012 10:44:11 +0100 (CET) Received: from [153.88.58.119] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Sun, 2 Dec 2012 10:44:12 +0100 Message-ID: <50BB22EB.1030803@ericsson.com> Date: Sun, 2 Dec 2012 10:44:11 +0100 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> In-Reply-To: <50B87606.5030802@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvje5rpd0BBlu7LS3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvmnoQWLuCtOTnzD0sA4k7OLkZNDQsBE4lpvByOELSZx4d56 ti5GLg4hgZOMEs8m/2KFcFYxSpx/9YoNpIpXQFti3+kZYDaLgIrE987prCA2m0CgxPX/v5hA bFGBKIlDGw+yQ9QLSpyc+YQFxBYREJbY+qoXrEZYwEpiVtcksLgQ0My5Hx+B2ZwCOhKr720B s5kFbCUuzLkOZctLNG+dzQxRryvx7vU91gmMArOQrJiFpGUWkpYFjMyrGNlzEzNz0ssNNzEC w+zglt+6OxhPnRM5xCjNwaIkzsuVtN9fSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2PJrJrr BpWvrnulysQLG+uF5J++u9ZrXzbHyyeqbRbvly7Zwe76L/x+/P/dySvOuPxwETQXePlR2jiX Z5Plix5HltQQmxVr3ilN5bm6ZMv9Go7l+i8Db/82nPP67pVFWr0fjHb5HZfY/PaOYL3RUe4f QYH+3yNei0xp3OPku6j8Yl9AR+7PTk4lluKMREMt5qLiRAA1fhTvAQIAAA== Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Dec 2012 13:49:28 -0000 On 2012-11-30 10:01, Magnus Westerlund wrote: > WG, > > This is the start of an one week+ call for consensus that will end on > Sunday the 9th of December. The question for consensus is: Shall a use > case be added regarding Text communication within the context of > PeerConnection, i.e. not using the generic capabilites of WebRTC, but > rather provide a specific media type and its transport. > > Please indicate your support or objections for this! I don't think we should add such a use case. It could make sense to create a separate document outlining the uses envisioned and the resulting requirements. I think we will find that those requirements can be met with already existing web technologies (but possibly the WebRTC data channel can offer a performance gain). > > 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 Mon Dec 3 08:49:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658D921F88CB for ; Mon, 3 Dec 2012 08:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=0.364, 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 MsIxFBJihrdE for ; Mon, 3 Dec 2012 08:49:27 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 67F2421F87DB for ; Mon, 3 Dec 2012 08:49:27 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so2290798vcb.31 for ; Mon, 03 Dec 2012 08:49:26 -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:content-transfer-encoding; bh=px2bFd3W1ZNKNtDRZncIgOzaV2njZDRgsGwyuRM8ZX4=; b=AE6ep585aoU8p+ZNn6/q+19kF5a1ubXuvgQYBTUlimq7p6L/HmgHXypuP3cazuFvE7 YnwyR8omKwComXd8iSxFyjuNLNOSVTlZdZ/MD0jx16MeJJVtOFSI9iE9wWKsoX7Kjgce P8j4ShNHeMcuC+VQsFjtNnCe51iK+0xIJ2t20UCbnqgJnXrbwgaZwHrczHTdfBDeAizI pxGgKk4VK27u3UMVJBOIIKdL10oR5V4Q9YhBTl4bFBR5bDLO2AvCKrzPKlMGXygHUdjv nTDDCseTolfixTb7+p+f5fOKuwn2QPCZwBhD7mSL4SxKTFknB1CZ+e3cxFpwPy5skaVs z8bA== MIME-Version: 1.0 Received: by 10.52.240.142 with SMTP id wa14mr2071670vdc.118.1354553366699; Mon, 03 Dec 2012 08:49:26 -0800 (PST) Received: by 10.58.164.35 with HTTP; Mon, 3 Dec 2012 08:49:26 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Dec 2012 08:49:26 -0800 Message-ID: From: Ted Hardie To: Mary Barnes Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Dec 2012 16:49:28 -0000 On Sat, Dec 1, 2012 at 11:25 AM, Mary Barnes w= rote: > I have a concern about this proposal to decide later how you will divide = the > meeting time between the 2 groups. These are separate organizations that > are having co-located meetings, but W3C requires membership and permissio= n > to attend as observers for folks that are not members. Whereas, the IETF > part of the meeting is totally open. I also think this is not quite in = the > spirit of the policy for announcing meetings ahead of time. If you want = to > do this split, then I think the exact split must be decided and announced= no > later than the 30 day window for IETF meeting announcements. > Hi Mary, I agree that we should decide the exact split relatively soon. As Harald notes, we needed to nail down the W3C side in order to get their deadlines met, which drove the selection timing faster than we'd normally do. I'm a little unclear about the other issue. If the IETF side is meeting from 1:00 to close of day on three days, I think we can make it clear that we're under Note Well rules for those times without any issues. Or are you thinking that you or others would like to attend only the IETF side of the meeting and thus would prefer it be some 1 1/2 day period during the currently identified time? Ted > Regards, > Mary. > > > On Fri, Nov 30, 2012 at 12:17 PM, Ted Hardie wrote: >> >> We will be holding an interim meeting, co-located with the relevant >> W3C folks, on February 5th-7th, 2013 in >> the Boston area. Many thanks to Hadriel Kaplan for hosting us. We >> have not yet established the time split >> between the groups; since one possible mechanism is for us to >> alternate morning and afternoon, please plan >> to be available for the full meeting time. >> >> regards, >> >> Ted Hardie, Cullen Jennings, Magnus Westerlund >> >> >> >> Details : >> >> Meeting site: >> >> Acme Packet >> 100 Crosby Drive >> Bedford, Massachusetts, 01730 >> TEL: 1-781-328-4400 >> http://www.acmepacket.com/company/contact-us/directions >> >> Breakfast, lunch and dinner will be provided on site. >> >> Hotels: >> The following are 15 minutes walk and also have complimentary shuttle >> service to/from Acme. >> Tell them you're staying for Acme Packet and you should get the >> discounted rate shown below. >> This may not be cheapest possible price, though, as prices fluctuate. >> >> DoubleTree by Hilton Hotel >> Doubletree discount price- $127 =96 corp. code 0002665706 >> Boston - Bedford Glen >> 44 Middlesex Turnpike >> Bedford, Massachusetts, 01730 >> TEL: 1-781-275-5500 >> >> http://doubletree3.hilton.com/en/hotels/massachusetts/doubletree-by-hilt= on-hotel-boston-bedford-glen-BOSBFDT/index.html >> >> Hampton Inn Bedford - Burlington >> Hampton Inn discount price- $115 =96 corp. code 0002665706 >> 25 Middlesex Turnpike >> Billerica, Massachusetts, 01821 >> TEL: 1-978-262-9977 >> >> http://hamptoninn3.hilton.com/en/hotels/massachusetts/hampton-inn-bedfor= d-burlington-BOSBIHX/index.html >> >> Courtyard Boston Billerica Bedford Hotel is about 3 miles away, and >> also has an Acme discount and complimentary shuttle service to/from >> Acme (and it's a Marriott chain as compared to Hilton): >> >> Courtyard Marriott (Billerica) discount price- $130 =96 corp. code ACM >> 270 Concord Road >> Billerica, Massachusetts 01821 >> TEL: 1-978-670-7500 >> >> http://www.marriott.com/hotels/travel/bosbb-courtyard-boston-billerica-b= edford/ >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > From eburger@standardstrack.com Mon Dec 3 09:26:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E6B21F887D for ; Mon, 3 Dec 2012 09:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.68 X-Spam-Level: X-Spam-Status: No, score=-101.68 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_SORBS_WEB=0.619, 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 SqR7IUjAM322 for ; Mon, 3 Dec 2012 09:26:47 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id C1C2A21F881D for ; Mon, 3 Dec 2012 09:26:47 -0800 (PST) Received: from [207.239.114.206] (port=5396 helo=[192.168.66.49]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TfZn1-0004h6-M6 for rtcweb@ietf.org; Mon, 03 Dec 2012 09:26:43 -0800 From: Eric Burger Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/signed; boundary=Apple-Mail-39-430792018; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 3 Dec 2012 10:13:50 -0500 In-Reply-To: <50BB22EB.1030803@ericsson.com> To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> Message-Id: X-Mailer: Apple Mail (2.1085) 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: Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Dec 2012 17:26:48 -0000 --Apple-Mail-39-430792018 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 If RTT is so trivial it is an extremely short, separate document, then = there is no real reason to not do it now, as part of the base protocol. If RTT is not trivial, then we have bigger problems: if we cannot figure = out how to specify a codec that has virtually no negotiation, has = real-time requirements but is somewhat jitter insensitive, and extremely = low bandwidth, then the idea that rtcweb will deliver voice and video in = our lifetime is a fantasy. Also, many jurisdictions are demanding RTT for real-time communications. = I can see it already: ITU-T H.webrtc supports RTT and IETF WebRTC does = not. Therefore, it will be illegal to deploy a site that does not = support H.webrtc. Are we really adamant about shooting ourselves in the foot, or is this = all an academic exercise? Just do it. On Dec 2, 2012, at 4:44 AM, Stefan H=E5kansson LK wrote: > On 2012-11-30 10:01, Magnus Westerlund wrote: >> WG, >>=20 >> This is the start of an one week+ call for consensus that will end on >> Sunday the 9th of December. The question for consensus is: Shall a = use >> case be added regarding Text communication within the context of >> PeerConnection, i.e. not using the generic capabilites of WebRTC, but >> rather provide a specific media type and its transport. >>=20 >> Please indicate your support or objections for this! >=20 > I don't think we should add such a use case. >=20 > It could make sense to create a separate document outlining the uses = envisioned and the resulting requirements. I think we will find that = those requirements can be met with already existing web technologies = (but possibly the WebRTC data channel can offer a performance gain). >=20 >>=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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-39-430792018 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMjAzMTUxMzUwWjAjBgkqhkiG9w0BCQQxFgQU JqgU8VXF+HP2rISJn8OVzSgJ370wgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAuvcVHyjkiAD0gMIAfN0tt3EzEAo1QgazKpH2qefjRsHtj37zVa0I VuwmqillAjLVnr6iCTs+btJqO8zH1aQsCknDfGM0hQR6y1uo0HN85E36+uscsl4/qX9mu+oo2oX9 WAS8nJcloOveg7l6jrlw7APLnHsL92HxYizC92ORDZVkZFuCo7aTU359gnSgPRel/ZHljZXt8QH6 zEaVO47+MLvdulwsMggyWm17RZRWJ8wLakvWE7Q2n+HQholvr94mj5kbxO9+6nSJ4FGtZjv7oCkf DL+wZgHGRyjsGpIzQIT7JAbaZ01YFWqJC4SZjlrg/UcRXj2tkI74iw2aYRgQnwAAAAAAAA== --Apple-Mail-39-430792018-- From ekr@rtfm.com Mon Dec 3 09:31:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B791A21F86CE for ; Mon, 3 Dec 2012 09:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.648 X-Spam-Level: X-Spam-Status: No, score=-102.648 tagged_above=-999 required=5 tests=[AWL=0.328, 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 kdWqm0hlv6uI for ; Mon, 3 Dec 2012 09:31:54 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEC421F8441 for ; Mon, 3 Dec 2012 09:31:53 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so3265570oag.31 for ; Mon, 03 Dec 2012 09:31:53 -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=zFwE5s5MkSapIUHGaTTAbTSwGm8c5PSY1oZSDWIhBXE=; b=HC6d3Z+lruCpXOlxwjLXYgNv3nikq2/KQWz/KJEuMkIQ0UoHQBcuLogd8SBfj99XIM Xy49HBbLnOwyaqbpJMdxyvuXH2KAhgJbCC+BQaCbw9ZE4OVBseKN+baIb1dYrrKukK+n 7k4cX5HRgQSgh+SJmHNst7UnI71zMBMTj/rXghJJqZgeerdaiEa0A++5zD+d19ZQb6Zv XDkKzBqgSoXWXmTnR6r93op4qed7Z0uRvoPQEkPP4hpg2abPW3f/kSpbUd1eoEpb8Egw 7/tQIpavL/Cid9GynOLUBhR+0y1rwrENl9Wk5biJQ84Hkk0GmEbyKn9rx+27iJ6orh8z g3kg== Received: by 10.182.177.100 with SMTP id cp4mr5155060obc.71.1354555913586; Mon, 03 Dec 2012 09:31:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.136.102 with HTTP; Mon, 3 Dec 2012 09:31:12 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> From: Eric Rescorla Date: Mon, 3 Dec 2012 09:31:12 -0800 Message-ID: To: Eric Burger Content-Type: multipart/alternative; boundary=e89a8f838d9f0ec81104cff620c9 X-Gm-Message-State: ALoCoQlQrtI1vWMI3KjIXQKRfgiZcSk2wujVHPhSrUrltg8/yLTvz7JEavDVEIWfjfxCVpG3JiZJ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Dec 2012 17:31:54 -0000 --e89a8f838d9f0ec81104cff620c9 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 3, 2012 at 7:13 AM, Eric Burger wrote: > If RTT is so trivial it is an extremely short, separate document, then > there is no real reason to not do it now, as part of the base protocol. > > If RTT is not trivial, then we have bigger problems: if we cannot figure > out how to specify a codec that has virtually no negotiation, has real-time > requirements but is somewhat jitter insensitive, and extremely low > bandwidth, then the idea that rtcweb will deliver voice and video in our > lifetime is a fantasy. > This is a false choice. It's trivial to do if you use the infrastructure that WebRTC already provides for this purpose. It appears to be rather a PITA to do the way that Gunnar proposes. -Ekr --e89a8f838d9f0ec81104cff620c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Dec 3, 2012 at 7:13 AM, Eric Bur= ger <eburger@standardstrack.com> wrote:
If RTT is so trivial it is an extremely short, separate document, then ther= e is no real reason to not do it now, as part of the base protocol.

If RTT is not trivial, then we have bigger problems: if we cannot figure ou= t how to specify a codec that has virtually no negotiation, has real-time r= equirements but is somewhat jitter insensitive, and extremely low bandwidth= , then the idea that rtcweb will deliver voice and video in our lifetime is= a fantasy.

This is a false choice.

It's trivial to do if you use the infrastructure that WebRTC alr= eady provides
for this purpose. It appears to be rather a PITA to= do the way that Gunnar
proposes.

-Ekr

--e89a8f838d9f0ec81104cff620c9-- From fluffy@cisco.com Mon Dec 3 09:50:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA13921F8905 for ; Mon, 3 Dec 2012 09:50:51 -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, 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 sfzMC-8rAG6s for ; Mon, 3 Dec 2012 09:50:51 -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 D72E121F88FE for ; Mon, 3 Dec 2012 09:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=175; q=dns/txt; s=iport; t=1354557051; x=1355766651; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xJj8Q0ptqZJ73IeGIRpjYzMXoscxqAM7Hacm10PQpOk=; b=T6a4tbm6+JhhvELCWQYgrW5r2iEg8pQ9rwpVRdafcE0fiZkeK1YU0iPh M2CNJKesbJjcvzKLOgEWWdnYRwtvA33aSupTg+6mOX1ZZnhVn1Xc57ayc vU+r/D4Nz6mKAb7f5H0b/HzcU5uFSeUTbb5FZDtghNGkH4OD1K7eV9P6Q Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FAB/lvFCtJV2a/2dsb2JhbABEhWW6GxZzgh4BAQEDAXkFCwIBCA4UJDIlAgQOBQiIAga+RIxAg2BhA4gpnh+CcoIh X-IronPort-AV: E=McAfee;i="5400,1158,6915"; a="148850252" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 03 Dec 2012 17:50:50 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qB3HooDT010267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Dec 2012 17:50:50 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.109]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 11:50:50 -0600 From: "Cullen Jennings (fluffy)" To: Eric Burger Thread-Topic: [rtcweb] Consensus call on Text Communication Thread-Index: AQHN0X66KNFwtejXm0uKKys1JMShUQ== Date: Mon, 3 Dec 2012 17:50:49 +0000 Message-ID: References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@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.167] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9F04A1FFC681A74DB5630460A8E51961@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Dec 2012 17:50:51 -0000 On Dec 3, 2012, at 8:13 AM, Eric Burger wrote: > Also, many jurisdictions are demanding RTT for real-time communications.= =20 name one From iesg-secretary@ietf.org Mon Dec 3 09:55:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D2E21F890D; Mon, 3 Dec 2012 09:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 2o5vZjh0QjjZ; Mon, 3 Dec 2012 09:55:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB69921F87E7; Mon, 3 Dec 2012 09:55:28 -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.36 Message-ID: <20121203175528.17025.71776.idtracker@ietfa.amsl.com> Date: Mon, 03 Dec 2012 09:55:28 -0800 Cc: rtcweb@ietf.org Subject: [rtcweb] RTCWEB WG 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, 03 Dec 2012 17:55:29 -0000 The RTCWEB working group would like to announce an upcoming 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 the rtcweb list = (http://www.ietf.org/mail-archive/web/rtcweb/current/msg05826.html). From markybox@gmail.com Mon Dec 3 10:16:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15C421F85D7 for ; Mon, 3 Dec 2012 10:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 x3sS4qCAEPY0 for ; Mon, 3 Dec 2012 10:16:10 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D685921F87EB for ; Mon, 3 Dec 2012 10:16:09 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so1283441bku.31 for ; Mon, 03 Dec 2012 10:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=GM/b/1YuPvt9j3N0/tEnuOkCYGzxU6Ui0tAeYe3q6+Q=; b=Eni5SmF1f+c5avjrsYLPvR9aT+dR4UKiZdAXxGL7HqGhIMSxTKQX3gA2SKSDG3SVqe luK+qAvvkP9iSsaws0UlOGF1VHcCS1JFkWNbjfyUKLtsAb4gKfNLglqJpCne3JKPaA/5 MgC3FI2lYeeKQJQr02XmWOelH2wtG5vwZRJGHQZ24YSprvwltma1BcwFmNO7R0bMFhmz x/ZXjhga++N/UhUFiam5SstR18bI5sZMRMea7ejC03/hUWQc2RM1f011oa0T4pP0eCj7 /EalKLZuUIcCcdyKfhl1h0+Z9M58G6foon+w1cykIKxkMJnD64doTPC6sIEHAgiAoT8h Ui2w== Received: by 10.204.157.26 with SMTP id z26mr3177819bkw.101.1354558568766; Mon, 03 Dec 2012 10:16:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.205.80.15 with HTTP; Mon, 3 Dec 2012 10:15:47 -0800 (PST) In-Reply-To: References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> From: Mark Rejhon Date: Mon, 3 Dec 2012 13:15:47 -0500 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Dec 2012 18:16:10 -0000 On Mon, Dec 3, 2012 at 12:31 PM, Eric Rescorla wrote: >> If RTT is not trivial, then we have bigger problems: if we cannot figure >> out how to specify a codec that has virtually no negotiation, has real-time >> requirements but is somewhat jitter insensitive, and extremely low >> bandwidth, then the idea that rtcweb will deliver voice and video in our >> lifetime is a fantasy. > > This is a false choice. > > It's trivial to do if you use the infrastructure that WebRTC already > provides for this purpose. It appears to be rather a PITA to do the way that Gunnar > proposes. As the author of XEP-0301 (real-time text for XMPP, which most commonly runs over TCP/IP) -- the data connection facility within webrtc seems to be fine for real-time text, at least from the perspective of XEP-0301. When things are running reliable (no data loss), on a sufficiently performing server, latency would be a non-issue. Reasoning of my point of view: XEP-0301 uses an XML-based real-time text payload that makes it suitable for almost any kind of channel -- even polled -- it works BOSH too. This is an even higher-level layer with more stall problems than even the webrtc data connection facility, which seems supposedly more real-time than plain TCP/IP from what I've been reading. So XEP-0301 has it worse-off (by XMPP needing to run over TCP/IP) than the webrtc data channel. Side note -- The XML real-time text payload in XEP-0301 is mostly channel protocol independent; it can be polled (BOSH), it can be on a lossy channel (UDP, intermittent wireless connections, etc) as long as latency is not too big. Although it is for XMPP, it was designed as a generic XML-based real time text payload that is channel-independent since it has its own correct-sequence check and an optional method of redundancy. If text smoothing is used (e.g. key press interval encoding), conversations are usable even with a sustained 2 to 3 second latency (only if it is unavoidable, e.g. weak connections, congestion), though I certainly strongly, greatly prefer 300ms. But it's by all means, totally usable (my opinion, for me, at least), and TCP retransmit stalls are only a minor disruption; much smaller than it is for audio and video. There are 'extenuating' moments (i.e. unavoidable connectivity degradations like weak wireless reception) where stalls are impossible to avoid. It's just a fact of life. I also see great potential for the webrtc data channel to be used for other real-time-like connectivity (e.g. video games within webrtc), and there is no doubt that vendors will optimize the data channels; this will only benefit real-time text, whichever technology is piped through them (RFC4103 based, XEP-0301 based) Mark Rejhon Author of XEP-0301 -- XMPP Real-Time Text From richard@shockey.us Mon Dec 3 10:32:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EE321F8911 for ; Mon, 3 Dec 2012 10:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.89 X-Spam-Level: X-Spam-Status: No, score=-101.89 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_16=0.6, 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 XWtm4efzF1oI for ; Mon, 3 Dec 2012 10:32:27 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 4E8BA21F8905 for ; Mon, 3 Dec 2012 10:32:27 -0800 (PST) Received: (qmail 15553 invoked by uid 0); 3 Dec 2012 18:32:01 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 3 Dec 2012 18:32:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=Ak13RGp70BauK/JOmlRVlx57sU3+NKhR0+prjFXSQxc=; b=Vgf+aKXXfhYs8qigu1peNr8xhnw3WRqrQ9EpB/8LeIVC6zRbrTX01EZrdfCiftTW5eWe+nhxH7YDJTU6DWsOBE4h57c2/+sLWm6l++4Jo5alJ85LmgBIm4iI5lVkmNqB; Received: from [71.191.243.130] (port=54234 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TfaoD-0003uM-3y; Mon, 03 Dec 2012 11:32:01 -0700 From: "Richard Shockey" To: "'Eric Burger'" , References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> In-Reply-To: Date: Mon, 3 Dec 2012 13:31:54 -0500 Message-ID: <023e01cdd184$7ce3e210$76aba630$@us> 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: Ac3Re2F3zj+NDUaMRBy63i7gXPmD9gACBmIw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Dec 2012 18:32:28 -0000 Thank you brother Burger...=20 So (rant hat on) we seem to agree on at least 2 MTI audio codecs's = though I've seen no further discussion of SHOULD's like 722 AMR WB which might = be useful to interoperate with nearly every future mobile endpoint and enterprise IP PBX system on the planet.=20 We have zero agreement for MTI on video codec's. =20 Now we have this discussion that the WG should simply not even deal with RTT. If this is the future of interoperable real-time communications... wow!=20 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Eric Burger Sent: Monday, December 03, 2012 10:14 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on Text Communication If RTT is so trivial it is an extremely short, separate document, then = there is no real reason to not do it now, as part of the base protocol. If RTT is not trivial, then we have bigger problems: if we cannot figure = out how to specify a codec that has virtually no negotiation, has real-time requirements but is somewhat jitter insensitive, and extremely low bandwidth, then the idea that rtcweb will deliver voice and video in our lifetime is a fantasy. Also, many jurisdictions are demanding RTT for real-time communications. = I can see it already: ITU-T H.webrtc supports RTT and IETF WebRTC does = not. Therefore, it will be illegal to deploy a site that does not support H.webrtc. Are we really adamant about shooting ourselves in the foot, or is this = all an academic exercise? Just do it. On Dec 2, 2012, at 4:44 AM, Stefan H=E5kansson LK wrote: > On 2012-11-30 10:01, Magnus Westerlund wrote: >> WG, >>=20 >> This is the start of an one week+ call for consensus that will end on = >> Sunday the 9th of December. The question for consensus is: Shall a=20 >> use case be added regarding Text communication within the context of=20 >> PeerConnection, i.e. not using the generic capabilites of WebRTC, but = >> rather provide a specific media type and its transport. >>=20 >> Please indicate your support or objections for this! >=20 > I don't think we should add such a use case. >=20 > It could make sense to create a separate document outlining the uses envisioned and the resulting requirements. I think we will find that = those requirements can be met with already existing web technologies (but = possibly the WebRTC data channel can offer a performance gain). >=20 >>=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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Mon Dec 3 11:00:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D02C21F8862 for ; Mon, 3 Dec 2012 11:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APk18pnlEdcA for ; Mon, 3 Dec 2012 11:00:08 -0800 (PST) Received: from blu0-omc4-s29.blu0.hotmail.com (blu0-omc4-s29.blu0.hotmail.com [65.55.111.168]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6E721F8877 for ; Mon, 3 Dec 2012 11:00:08 -0800 (PST) Received: from BLU405-EAS354 ([65.55.111.137]) by blu0-omc4-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Dec 2012 11:00:07 -0800 X-Originating-IP: [64.122.121.2] X-EIP: [Sddta25dzrleHWVwGhnbEhLBN7javXDS] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Mon, 3 Dec 2012 11:02:37 -0800 To: "Cullen Jennings (fluffy)" X-OriginalArrivalTime: 03 Dec 2012 19:00:07.0557 (UTC) FILETIME=[69461350:01CDD188] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Dec 2012 19:00:09 -0000 I posted references to CVAA, the ACS Report & Order and the Access Board Sec= tion 255/508 refresh earlier. There is also M376 in EU (see http://www.manda= te376.eu/ ) which is similar to Section 255/508 (e.g. a procurement guidelin= e). In reading these documents it's important to keep in mind that "RTT" ca= n mean a capability in some cases and in others can refer to a specific stan= dard (e.g. RFC 4103 or XEP-0301).=20 On Dec 3, 2012, at 9:50, "Cullen Jennings (fluffy)" wrote= : >=20 > On Dec 3, 2012, at 8:13 AM, Eric Burger wrote= : >=20 >> Also, many jurisdictions are demanding RTT for real-time communications. >=20 > name one >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From adam@nostrum.com Mon Dec 3 11:26:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09FF21F8654 for ; Mon, 3 Dec 2012 11:26:56 -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 sknFDdCpkhot for ; Mon, 3 Dec 2012 11:26:56 -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 6B82121F87DB for ; Mon, 3 Dec 2012 11:26:56 -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 qB3JQtrS038724 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 3 Dec 2012 13:26:55 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50BCFCFE.3080104@nostrum.com> Date: Mon, 03 Dec 2012 13:26:54 -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: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.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) Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Dec 2012 19:26:57 -0000 On 12/3/12 13:02, Bernard Aboba wrote: > it's important to keep in mind that "RTT" can mean a capability in some cases and in others can refer to a specific standard (e.g. RFC 4103 or XEP-0301). Which highlights the problem we'll face if we decide to take this work on. We can do RTT right now with data channels. I can hack together a ridiculously simple example on top of Firefox Nightly build if you want to see it. Now, if we decide that we're going to pick through the specific standards called out by the various regulatory regimes around the global -- well in excess of 100 -- in order to make sure that we've put extra special hooks in WebRTC to support whatever technical variant they've specified, then we have no hope of ever finishing. The alternative of picking Gunnar's personal favorite technology (and ignoring any regulations that elect to go another way) would seem to add quite a bit of work to come up with what ends up being a somewhat provincial solution. It would be a half-measure that adds significant work while only partially meeting your implied goal of meeting all regulations presently in place or being contemplated around the globe. /a From adam@nostrum.com Mon Dec 3 11:30:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CBE21F87E7 for ; Mon, 3 Dec 2012 11:30:11 -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 LmXDyUpMPcWY for ; Mon, 3 Dec 2012 11:30:11 -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 2E19421F86CE for ; Mon, 3 Dec 2012 11:30:11 -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 qB3JTtbn038960 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 3 Dec 2012 13:29:55 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50BCFDB3.4010205@nostrum.com> Date: Mon, 03 Dec 2012 13:29: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: Ted Hardie References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; 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] Upcoming Interim meeting, co-located with WEBRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Dec 2012 19:30:11 -0000 On 12/3/12 10:49, Ted Hardie wrote: > I'm a little unclear about the other issue. If the IETF side is > meeting from 1:00 to close of day > on three days, I think we can make it clear that we're under Note Well > rules for those times > without any issues. Or are you thinking that you or others would like > to attend only the IETF > side of the meeting and thus would prefer it be some 1 1/2 day period > during the currently identified > time? The way I read Mary's concern is that non-W3C members might be forced to spend the WebRTC portion of the meeting twiddling their thumbs. If we make it clearer ahead of time that the WebRTC chairs have explicitly granted observation permission to all attendees -- regardless of whether they are W3C members -- then I would imagine that the concerns should be addressed. Is that about right, Mary? /a From stewe@stewe.org Mon Dec 3 11:54:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AFE21F8809 for ; Mon, 3 Dec 2012 11:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxNZjvm9v6zf for ; Mon, 3 Dec 2012 11:54:48 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0E821F87EE for ; Mon, 3 Dec 2012 11:54:48 -0800 (PST) Received: from mail273-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 3 Dec 2012 19:54:47 +0000 Received: from mail273-tx2 (localhost [127.0.0.1]) by mail273-tx2-R.bigfish.com (Postfix) with ESMTP id 374E8740087; Mon, 3 Dec 2012 19:54:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT002.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zzbb2dI98dI1432Izz1de0h1202h1d1ah1d2ah1082kzz1033IL17326ah8275bh8275dhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1155h) Received-SPF: pass (mail273-tx2: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT002.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail273-tx2 (localhost.localdomain [127.0.0.1]) by mail273-tx2 (MessageSwitch) id 1354564484467706_32102; Mon, 3 Dec 2012 19:54:44 +0000 (UTC) Received: from TX2EHSMHS007.bigfish.com (unknown [10.9.14.251]) by mail273-tx2.bigfish.com (Postfix) with ESMTP id 6E2C71840053; Mon, 3 Dec 2012 19:54:44 +0000 (UTC) Received: from BL2PRD0710HT002.namprd07.prod.outlook.com (157.56.240.133) by TX2EHSMHS007.bigfish.com (10.9.99.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 3 Dec 2012 19:54:44 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.9]) by BL2PRD0710HT002.namprd07.prod.outlook.com ([10.255.102.37]) with mapi id 14.16.0245.002; Mon, 3 Dec 2012 19:54:37 +0000 From: Stephan Wenger To: Adam Roach , Ted Hardie Thread-Topic: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC Thread-Index: AQHNzyb6aok1jPBtz0mh+aSyOnfNppgEVPWAgAL5CwCAACzXgP//sxCA Date: Mon, 3 Dec 2012 19:54:36 +0000 Message-ID: In-Reply-To: <50BCFDB3.4010205@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <6BDC56147512D34EAF038B9098595EAC@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Dec 2012 19:54:49 -0000 I'm not Mary, but I observe that W3C "Invited Experts" are as the very minimum subject to the disclosure part of W3Cs patent policy (section 6.10 of http://www.w3.org/Consortium/Patent-Policy-20040205/). In W3C, and compared to the IETF, these obligations are quite onerous because they require that one discloses ALL patents and application the invited expert is aware of (and not only those licensable by the invited expert's employer). Which is why I would be very reluctant to attend any W3C technical meeting. On top of that, licensing obligations of non-members, if they exist (which is not clear from my reading of W3C's patent policy), are a tricky subject. Anything but a royalty free position creates major procedural hurdles and issues in W3C. So not sitting in a W3C meeting and instead twiddling thumbs may actually be a good choice for some of us. OTOH, it's also possible to get some work done :-) Stephan=20 On 12.3.2012 14:29 , "Adam Roach" wrote: >On 12/3/12 10:49, Ted Hardie wrote: >> I'm a little unclear about the other issue. If the IETF side is >> meeting from 1:00 to close of day >> on three days, I think we can make it clear that we're under Note Well >> rules for those times >> without any issues. Or are you thinking that you or others would like >> to attend only the IETF >> side of the meeting and thus would prefer it be some 1 1/2 day period >> during the currently identified >> time? > >The way I read Mary's concern is that non-W3C members might be forced to >spend the WebRTC portion of the meeting twiddling their thumbs. If we >make it clearer ahead of time that the WebRTC chairs have explicitly >granted observation permission to all attendees -- regardless of whether >they are W3C members -- then I would imagine that the concerns should be >addressed. > >Is that about right, Mary? > >/a >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > From ted.ietf@gmail.com Mon Dec 3 12:15:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D73821F884A for ; Mon, 3 Dec 2012 12:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.068 X-Spam-Level: X-Spam-Status: No, score=-3.068 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, J_CHICKENPOX_12=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 6RCaFZo-7cN5 for ; Mon, 3 Dec 2012 12:15:05 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C7BF521F8775 for ; Mon, 3 Dec 2012 12:15:04 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so2296191vbb.31 for ; Mon, 03 Dec 2012 12:15:04 -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=xog4OWP1zjbDxl8J10CadAk0n5nVkdXmqN5M9Kb3AJ8=; b=Rhpaqi2vDI50oqUpN4uYZyweH/hyjNCmiFSH0qbd5x7h67lUFFOEC97bP/wC5f14nG dg/ZBi1ADmPyBfg1w7zK8Txc9AF0RlrGBLvRZMxdX34BbMOM4ZR7TiMjMizabwijc17d 9WrKorEwQ5krZtucBbdv4d/GxRT09VCyNeWTnYdPEcnHIoPc8O4bhtr0PjbQyBeU+QJR Zxzucg53NZLQLBg/xTLEk+S9d2WLhBKAZphtozGDH2p8Wac0O27FDd1j/aZvAVPw7SLC pMMcGItOQIHpJHZuoDC1UDjAsOhzzSsScRlpV3Hby/bR4sa69hQ3RZwGKk2fHB51Or7X F0+Q== MIME-Version: 1.0 Received: by 10.58.221.130 with SMTP id qe2mr9936501vec.14.1354565704332; Mon, 03 Dec 2012 12:15:04 -0800 (PST) Received: by 10.58.164.35 with HTTP; Mon, 3 Dec 2012 12:15:04 -0800 (PST) In-Reply-To: References: <50BCFDB3.4010205@nostrum.com> Date: Mon, 3 Dec 2012 12:15:04 -0800 Message-ID: From: Ted Hardie To: Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Dec 2012 20:15:05 -0000 On Mon, Dec 3, 2012 at 11:54 AM, Stephan Wenger wrote: > I'm not Mary, but I observe that W3C "Invited Experts" are as the very > minimum subject to the disclosure part of W3Cs patent policy (section 6.10 > of http://www.w3.org/Consortium/Patent-Policy-20040205/). I think there is a difference between "invited expert" and "observer" in the W3C rules, but I will leave it the W3C chairs to elaborate. Harald, Stefan, have I got that right? Ted From richard@shockey.us Mon Dec 3 12:58:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CB821F8817 for ; Mon, 3 Dec 2012 12:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.537 X-Spam-Level: X-Spam-Status: No, score=-101.537 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_05=-1.11, 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 m-AydhOF84Eh for ; Mon, 3 Dec 2012 12:58:31 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 6ECB321F87DB for ; Mon, 3 Dec 2012 12:58:31 -0800 (PST) Received: (qmail 5627 invoked by uid 0); 3 Dec 2012 18:24:41 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy11.bluehost.com with SMTP; 3 Dec 2012 18:24:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=wZF49asan4BBSqZNQtnVsXz0l8DARNTFsvqnAyV9X6g=; b=ODNmwCbVCUUVSbPb3alW0JfF3IN5Hi+3/U9jDrsGRK2/JipSEq8gQkaHuOE5N3tb2cn0W68mZRV1/GbstxlX6mg0VGprNkB25q/9F08dJSYZw8wF8HyWr/lJRijw759V; Received: from [71.191.243.130] (port=54232 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Tfah7-0005d7-IS; Mon, 03 Dec 2012 11:24:41 -0700 From: "Richard Shockey" To: "'Cullen Jennings \(fluffy\)'" , References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> In-Reply-To: Date: Mon, 3 Dec 2012 13:24:41 -0500 Message-ID: <023d01cdd183$76e5e030$64b1a090$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHN0X66KNFwtejXm0uKKys1JMShUZgHYhPQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Dec 2012 20:58:32 -0000 The US ... for a start ... we'd have to check with our ECRIT friends, Hannes etal but the moves in the EC along similar lines are equally striking. http://transition.fcc.gov/cgb/dro/cvaa.html Should I remind folks that this is the 20th anniversary of SMS...the most profitable product on planet Earth other than crack cocaine and laser toner? -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings (fluffy) Sent: Monday, December 03, 2012 12:51 PM To: Eric Burger Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on Text Communication On Dec 3, 2012, at 8:13 AM, Eric Burger wrote: > Also, many jurisdictions are demanding RTT for real-time communications. name one _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From prvs=4684be4466=aallen@rim.com Mon Dec 3 13:03:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB23C21F88BD for ; Mon, 3 Dec 2012 13:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.903 X-Spam-Level: X-Spam-Status: No, score=-4.903 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, 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 u-pbPo4aHdRa for ; Mon, 3 Dec 2012 13:03:23 -0800 (PST) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0654821F8817 for ; Mon, 3 Dec 2012 13:03:22 -0800 (PST) X-AuditID: 0a412830-b7f866d000003a99-84-50bd138d1b5a Received: from XCT105ADS.rim.net (xct105ads.rim.net [10.67.111.46]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id F4.7A.15001.D831DB05; Mon, 3 Dec 2012 15:03:09 -0600 (CST) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 15:03:08 -0600 From: Andrew Allen To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC Thread-Index: AQHNzyb8NcFMmUpiv0CmgfBL57AEvJgEuYqAgAL5CwCAACzXgIAABuYAgAAFtwD//6YpkA== Date: Mon, 3 Dec 2012 21:03:08 +0000 Message-ID: References: <50BCFDB3.4010205@nostrum.com> 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.254] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsXC5Zyvp9srvDfA4OhmG4u1/9rZHRg9liz5 yRTAGNXAaJOUWFIWnJmep29nk5iXl1+SWJKqkJJanGyr5JOanpijEFCUWZaYXKngklmcnJOY mZtapKSQmWKrZKKkUJCTmJyam5pXYquUWFCQmpeiZMelgAFsgMoy8xRS85LzUzLz0m2VPIP9 dS0sTC11DZXsdBM6eTKWrH/GXrCPt+LF0nVMDYxfuLoYOTkkBEwkjnbOY4WwxSQu3FvP1sXI xSEk0MYkMevFMSYIZxOjxIu7XxlBqtgElCWW/54BZosIqEtcfniBHcQWFnCTmLT1DRNE3F3i 8eUuoKkcQHaYxPMp+iBhFgEVics7DoAt4xXwkLh+exHU/BOMEpubr4DN4RQIlPh6bxFYESPQ Rd9PrQGbySwgLnHryXwmiEsFJJbsOc8MYYtKvHz8D+oDRYllJ06yQdTrSCzY/QnK1pZYtvA1 M8RiQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVo2BuRrGBmWFyXrJeUWauXl5qySZGUPQ7 ahjsYHz/3uIQowAHoxIP78xnewKEWBPLiitzDzFKcDArifC+Zt8bIMSbklhZlVqUH19UmpNa fIjRFRgsE5mluJPzgYkpryTe2MAAN0dJnPdQ5fYAIYF0YPrJTk0tSC2CmcPEwQmyh0tKpBiY RFKLEktLMuJBqS6+GJjspBoYV3S9UDnMec795lf/NW4Xt/ft+zFjWddhqzQNxhNrD6U9i+/z v6zCk5D3r3IZf/76H2Gv8mK+r1gkoBVumpx18KP+SfnkUIH+uVE7PP59Y9LpMbgndXC1+dem q3wTfZRf6qkUzDrX7Hhi9+0i0/BsuRMr+98tC/7sFDShzrxm7td4H4O3k41slFiKMxINtZiL ihMBhOypdj8DAAA= Subject: Re: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Dec 2012 21:03:23 -0000 I think for interim meetings it would be very helpful to have the agenda out= as far in advance as possible in order to help justify the expense of trave= lling for what looks like maybe a day and a half meeting for at least some f= rom the IETF side. It was made clear in Atlanta that the video codec MTI issue will not be disc= ussed but what is planned to be? RTCweb has many active drafts encompassing a broad range of topics so it wou= ld be very useful to know before committing to travel if the issues you have= interest in are likely to be discussed otherwise it may end up as 3 days of= thumb twiddling at considerable expense for some and potentially jeopardize= the likelihood of them obtaining travel authorization for future meetings. Andrew > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Ted Hardie > Sent: Monday, December 03, 2012 2:15 PM > To: Stephan Wenger > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC > > On Mon, Dec 3, 2012 at 11:54 AM, Stephan Wenger wrote: > > I'm not Mary, but I observe that W3C "Invited Experts" are as the very > > minimum subject to the disclosure part of W3Cs patent policy (section > 6.10 > > of http://www.w3.org/Consortium/Patent-Policy-20040205/). > > I think there is a difference between "invited expert" and "observer" in > the W3C > rules, but I will leave it the W3C chairs to elaborate. Harald, > Stefan, have I got > that right? > > Ted > _______________________________________________ > 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 roman@telurix.com Mon Dec 3 13:03:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA7621F88E0 for ; Mon, 3 Dec 2012 13:03:45 -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 7l9scEq3jOae for ; Mon, 3 Dec 2012 13:03:44 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A52A621F881F for ; Mon, 3 Dec 2012 13:03:44 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so2346233vbb.31 for ; Mon, 03 Dec 2012 13:03:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=g5w7ktIiITGE1gK+XRSZ2DFuqA5E1rKVrrLpQ6ZH1a0=; b=ff7Y2M8EdWh5iuWyjCPcPX6qytV2e8uFnP/tlyM+gAEQe/AsDkM5Cj2sYC8nry44z2 WpNjsfog+SJnCdhe0ySFhCQ7RjXw6sw5tAe4vpeRJ/qTDGxJVLNXkdbyhPAIXKaAfvSw D41OFUlw9Xh4Sn8j3SBs2qBGKubrKdSK30UIAjkPe7GxHoWsktHiA7X7d9giRTcx40o4 fd8gWDrBc4lvcgHBxulnck2DjWjq+jSWB3zjL+Uuz+J01PwV9msVRJ09SZ6MmRSDr3L2 eIdnXgwmr+h+Lfq7idqJpoh3bQxNGNdRzq2zRDMK+da5dfGrKjV2Y8KUI8AAzs70ZSIi 3MfQ== Received: by 10.220.153.212 with SMTP id l20mr9645923vcw.1.1354568624072; Mon, 03 Dec 2012 13:03:44 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by mx.google.com with ESMTPS id j3sm649194vdv.0.2012.12.03.13.03.42 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2012 13:03:43 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so2346201vbb.31 for ; Mon, 03 Dec 2012 13:03:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.16.12 with SMTP id m12mr9715738vca.14.1354568621040; Mon, 03 Dec 2012 13:03:41 -0800 (PST) Received: by 10.58.102.202 with HTTP; Mon, 3 Dec 2012 13:03:40 -0800 (PST) In-Reply-To: <023d01cdd183$76e5e030$64b1a090$@us> References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> <023d01cdd183$76e5e030$64b1a090$@us> Date: Mon, 3 Dec 2012 23:03:40 +0200 Message-ID: From: Roman Shpount To: Richard Shockey Content-Type: multipart/alternative; boundary=bcaec54b46c47b263b04cff915d4 X-Gm-Message-State: ALoCoQnd+t9knJ64rHbgEGeeyfGEgnHNZBxnNpBhEGRd0bRFxED7BgqlIXLPRah/tXrsfOKDzWhO Cc: "Cullen Jennings \(fluffy\)" , rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Dec 2012 21:03:45 -0000 --bcaec54b46c47b263b04cff915d4 Content-Type: text/plain; charset=ISO-8859-1 Out of curiosity what commercially available phones/terminals/clients currently support real time text apart from Real Jabber? What protocols do they currently support? _____________ Roman Shpount On Mon, Dec 3, 2012 at 8:24 PM, Richard Shockey wrote: > The US ... for a start ... we'd have to check with our ECRIT friends, > Hannes > etal but the moves in the EC along similar lines are equally striking. > > http://transition.fcc.gov/cgb/dro/cvaa.html > > Should I remind folks that this is the 20th anniversary of SMS...the most > profitable product on planet Earth other than crack cocaine and laser > toner? > > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of > Cullen Jennings (fluffy) > Sent: Monday, December 03, 2012 12:51 PM > To: Eric Burger > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Consensus call on Text Communication > > > On Dec 3, 2012, at 8:13 AM, Eric Burger > wrote: > > > Also, many jurisdictions are demanding RTT for real-time communications. > > name one > > _______________________________________________ > 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 > --bcaec54b46c47b263b04cff915d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Out of curiosity what=A0commercially=A0available phones/terminals/clients c= urrently support real time text apart from Real Jabber? What protocols do t= hey currently support?
_____________
Roman Shpount


On Mon, Dec 3, 2012 at 8:24 PM, Richard = Shockey <richard@shockey.us> wrote:
The US ... for a start ... we'd have to check with our ECRIT friends, H= annes
etal but the moves in the EC along similar lines are equally striking.

h= ttp://transition.fcc.gov/cgb/dro/cvaa.html

Should I remind folks that this is the 20th anniversary of SMS...the most profitable product on planet Earth other than crack cocaine and laser toner= ?


-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.or= g] On Behalf Of
Cullen Jennings (fluffy)
Sent: Monday, December 03, 2012 12:51 PM
To: Eric Burger
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Consensus call on Text Communication


On Dec 3, 2012, at 8:13 AM, Eric Burger <eburger@standardstrack.com> wrote:

> Also, many jurisdictions are demanding RTT for real-time communication= s.

name one

_______________________________________________
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

--bcaec54b46c47b263b04cff915d4-- From gunnar.hellstrom@omnitor.se Mon Dec 3 13:17:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FC021F88B8 for ; Mon, 3 Dec 2012 13:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoLBCqucEXvs for ; Mon, 3 Dec 2012 13:17:09 -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 07FE421F84D9 for ; Mon, 3 Dec 2012 13:17:08 -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 ; Mon, 3 Dec 2012 22:17:01 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id 15EFA3A162 for ; Mon, 3 Dec 2012 22:17:01 +0100 (CET) Message-ID: <50BD16CD.3030208@omnitor.se> Date: Mon, 03 Dec 2012 22:17:01 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> <50BCFCFE.3080104@nostrum.com> In-Reply-To: <50BCFCFE.3080104@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Real-time text implementation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Dec 2012 21:17:10 -0000 I changed subject as Harald asked us to do. On 2012-12-03 20:26, Adam Roach wrote: > On 12/3/12 13:02, Bernard Aboba wrote: >> it's important to keep in mind that "RTT" can mean a capability in >> some cases and in others can refer to a specific standard (e.g. RFC >> 4103 or XEP-0301). > > Which highlights the problem we'll face if we decide to take this work > on. > > We can do RTT right now with data channels. I can hack together a > ridiculously simple example on top of Firefox Nightly build if you > want to see it. > > Now, if we decide that we're going to pick through the specific > standards called out by the various regulatory regimes around the > global -- well in excess of 100 -- in order to make sure that we've > put extra special hooks in WebRTC to support whatever technical > variant they've specified, then we have no hope of ever finishing. > > The alternative of picking Gunnar's personal favorite technology (and > ignoring any regulations that elect to go another way) would seem to > add quite a bit of work to come up with what ends up being a somewhat > provincial solution. It would be a half-measure that adds significant > work while only partially meeting your implied goal of meeting all > regulations presently in place or being contemplated around the globe. > Thanks, Yes, please do a " ridiculously simple example" . It is doable, and that is similar to how we started in both H.320 , H.323 and SIP once. It is better to be able to show something simple than to discuss the best way to do it forever. Someone asked for regulations: Here is one: The European Electronic Communication Framework directives were revised in 2009, by 2009/136/EC, and for example introduced a new definition of "Publicly available telephone services" that must be provided to anyone who needs it: "Publicly available telephone services also include means of communication specifically intended for disabled end-users using text relay or total conversation services." And "total conversation services" are defined in ITU-T F.703 to provide video, real-time text and audio. Since May 2011 this shall be valid in all European countries. There are not many technology specific variants in regulations. They instead tend to describe the requirement in quite general terms like the European one. So, we are free to specify a good way to do it in rtcweb as long as it is feasible to gateway it together with audio and video into a SIP session with audio, video and RFC 4103. Even if we end up using the rtcweb data channel, I think a standard specification should be done. It is best if we do it with the view that it will become a popular mainstream feature. The research references I supplied the other day show that that is feasible. Looking forward to see your example Adam. //Gunnar Gunnar From markybox@gmail.com Mon Dec 3 13:58:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C744D21F8920 for ; Mon, 3 Dec 2012 13:58:36 -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 1LZNMNbSu2sd for ; Mon, 3 Dec 2012 13:58:35 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 98EAA21F88FE for ; Mon, 3 Dec 2012 13:58:35 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1433784wey.31 for ; Mon, 03 Dec 2012 13:58:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=sdJzAJj9453yX8Vuyb+vJiZ/RJ9vTAnE6sEslYvJwmY=; b=BmQ39vU0srLxNUW7r2Fm1HYML/S/fd1JHVxBnv8VmF74i6Ugs3kogZZmbdNuBZ9Y1L 8UC84YRf11u1ZFoGKwGnV4ijqQ1+mu0n8YR6H0IuFvPjdC9olCWS0G4MvyQsMaBqaOSl 131RxAyziGTC78GUDsZ/+3YxR4gfk6pwEhHZemwkFi//acuQLipf44biBIXbPPFTP0rr H3Qd/uSEI1MdRxiWc1yDAGLZXBrTaZPsOAh91LHXOIfCSChI4V7qbYcrp4MLJUutNU34 J6k2vOwFrXpeMdcfO3lR/BU9lIPLgyeSDXNrQJs+3/lH6EKWLurC2QJBegjjG2cSwHt6 gdiw== Received: by 10.216.193.70 with SMTP id j48mr3595446wen.122.1354571914576; Mon, 03 Dec 2012 13:58:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.18.142 with HTTP; Mon, 3 Dec 2012 13:58:14 -0800 (PST) From: Mark Rejhon Date: Mon, 3 Dec 2012 16:58:14 -0500 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=ISO-8859-1 Cc: "Cullen Jennings \(fluffy\)" , rtcweb@ietf.org Subject: Re: [rtcweb] Real-time text implementation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Dec 2012 21:58:36 -0000 On Mon, Dec 3, 2012 at 4:03 PM, Roman Shpount wrote: > Out of curiosity what commercially available phones/terminals/clients > currently support real time text apart from Real Jabber? What protocols do > they currently support? > _____________ > Roman Shpount Several examples: -- There is a Real-Time IM feature found in AOL Instant Messenger. A great collaboration with Gallaudet University, but poorly marketed (unadvertised feature) and proprietary. http://tap.gallaudet.edu/text/aol/ -- A component within Total Conversation, used by Reach112 in Europe, a currently-operating accessible emergency service with real-time text. http://www.reach112.eu -- Relay services for the deaf, and caption telephone providers http://www.i711.com -- http://www.relaycall.com -- http://www.sprintrelayonline.com -- http://www.sprintcaptel.com -- etc. (dozens of URL's, depending on country.) (WebRTC would have massive benefit for these.) -- Text telephones, aka TDD, TTY, textphones, etc. Terminal devices used by the deaf, are legacy real-time text devices. They are less popular now, as more now use messaging, even at the loss of real-time-ness. There are others, but the above are the most common. Some use standard RTT protocols, and some use proprietary RTT protocols. You will observe that it is currently mostly accessible applications. at the moment. However, there's also mainstream interest, since several parties have expressed interest in XEP-0301 once it gets more finalized, with its status upgraded. Some love it, some don't like it, but the same is said for audio or video -- and I've noticed among my testing audience (once educated on the feature, such as via explanations from http://www.fasttext.org ) -- RTT became a more popular feature than video; it's got more useful mainstream use cases. Yet it also simultaneously provides accessible communication. So it can gradually be adopted by mainstream instant messengers over the long term (the question is: a few years, a decade, etc?). XEP-0301 is the world's first open real-time text standard designed for seamless instant messaging integration; making it possible to be a mainstream feature; so I expect as status gets upgraded and actual mainstream app vendors implement it in at least a couple (then the "me-too's" follows) within a decade, it's going to gradually catch attention of regulators. (It already has -- U.S. Access Board is asking me when the status of XEP-0301 is being upgraded.) Mark Rejhon From gunnar.hellstrom@omnitor.se Mon Dec 3 14:12:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8FE21F8908 for ; Mon, 3 Dec 2012 14:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kayrWSadYzRY for ; Mon, 3 Dec 2012 14:12:23 -0800 (PST) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 3AC7921F8593 for ; Mon, 3 Dec 2012 14:12:22 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Mon, 3 Dec 2012 23:12:15 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id CCFD53A11A for ; Mon, 3 Dec 2012 23:12:15 +0100 (CET) Message-ID: <50BD23C0.3010509@omnitor.se> Date: Mon, 03 Dec 2012 23:12:16 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> <023d01cdd183$76e5e030$64b1a090$@us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [rtcweb] Real-time text implementations X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Dec 2012 22:12:35 -0000 Again moving off the voting subject as requested by Harald. On 2012-12-03 22:03, Roman Shpount wrote: > Out of curiosity what commercially available phones/terminals/clients > currently support real time text apart from Real Jabber? What > protocols do they currently support? > _____________ > Roman Shpount > Here are some ( I hope it is OK to mention a bunch of brand names here - a bit off habit in standards work ) Asterisk PBX T.140/RFC4103 Omnitor Allan eC Windows total conversation softphone T.140/RFC4103 Omnitor eCmobile Android app T.140/RFC 4103 Omnitor eCtouch Android app T.140/RFC4103 Omnitor eCpad hard pad T.140/RFC4103 multi-party bridge T.140/RFC4103 Aupix TCPhone Windows softphone T.140/RFC4103 Aupix TCPhone Android app T.140/RFC4103 Aupix TCPhone IOS app T.140/RFC4103 Aupix call center T.140/RFC4103 Leadtek 8A10 hard pad T.140/RFC4103 ivés Djanah Windows softphone T.140/RFC4103 ivés call center T.140/RFC4103 T-Meeting TM-9000 hard pad T.140/RFC4103 nWise MMX5 call center and soft phone T.140/RFC4103 A number of emergency service PSAP NG911/NG112 systems T.140/RFC4103 Tenacity IP-TTY Windows softphone T.140/RFC4103 SBNTech hard pad T.140/RFC4103 AOL soft chat client - proprietary Ultratec Captel soft client - proprietary Texttelefoni.se soft web client for relay - proprietary RealJabber Soft XMPP client XEP-0301 //Gunnar From richard@shockey.us Mon Dec 3 16:28:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1CB21F8912 for ; Mon, 3 Dec 2012 16:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.175 X-Spam-Level: X-Spam-Status: No, score=-102.175 tagged_above=-999 required=5 tests=[AWL=0.424, 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 WhSqRw+GlHLO for ; Mon, 3 Dec 2012 16:28:26 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 151BF21F865F for ; Mon, 3 Dec 2012 16:28:26 -0800 (PST) Received: (qmail 24673 invoked by uid 0); 3 Dec 2012 20:40:46 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy11.bluehost.com with SMTP; 3 Dec 2012 20:40:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=glV46YMCssL7k+t8KeCq9ZJDX+m+Vsaq3LxclNjphTk=; b=ExjlaPinIqf1wGIycMA3tdyWf6AHeXU4sNtezfNa15H18sgVnKRNEz3d9zKnoZ+IDVjtgXFLIZX3Zpa7JBIeNvWWHbAh/09WpEQNRMTE0awx2ei62b5DEJYdn5lSfnWF; Received: from [71.191.243.130] (port=55955 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Tfcoo-0002zt-A2; Mon, 03 Dec 2012 13:40:46 -0700 From: "Richard Shockey" To: "'Adam Roach'" , References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> <50BCFCFE.3080104@nostrum.com> In-Reply-To: <50BCFCFE.3080104@nostrum.com> Date: Mon, 3 Dec 2012 15:40:46 -0500 Message-ID: <000001cdd196$796cde90$6c469bb0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3RjCpd9VbhIO7CT720tv9hwprQNQAB6bKg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 00:28:26 -0000 On 12/3/12 13:02, Bernard Aboba wrote: > it's important to keep in mind that "RTT" can mean a capability in some cases and in others can refer to a specific standard (e.g. RFC 4103 or XEP-0301). Which highlights the problem we'll face if we decide to take this work on. We can do RTT right now with data channels. I can hack together a ridiculously simple example on top of Firefox Nightly build if you want to see it. [RS> ] I have no doubt .. :-) Now, if we decide that we're going to pick through the specific standards called out by the various regulatory regimes around the global -- well in excess of 100 -- in order to make sure that we've put extra special hooks in WebRTC to support whatever technical variant they've specified, then we have no hope of ever finishing. The alternative of picking Gunnar's personal favorite technology (and ignoring any regulations that elect to go another way) would seem to add quite a bit of work to come up with what ends up being a somewhat provincial solution. It would be a half-measure that adds significant work while only partially meeting your implied goal of meeting all regulations presently in place or being contemplated around the globe. [RS> ] [RS> ] Adam this is a fair position to take. I suspect the general objection is that given all the requirements for RTCWEB that are out there right now it's a near impossible task to sort through as it is much less decide on something new. A reasonable position. RTT is thus a "distraction". That said, the opposite position is RTT is just to big to ignore for any number of reasons and we do need to remember that this week is the 20th anniversary of SMS and text is near and dear to the hearts of the hearing impaired community, ES 911 proponents not to mention nearly every human being under the age of 25. Remember the enormous failures of IM were they did not interoperate thus granting SMS an open field to market domination. Silos don't work. You have to choose. I still think Bernard's general approach is correct.. try and document what is out there now and can one or more be selected for MTI with the assumption that everything else is going to be sent through a gateway. The regulatory authorities .. if you read CVAA closely for instance, understand there may be multiple technical approaches to compliance. It's is the attempt to comply that is "safe harbor" in legal terms. /a _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Mon Dec 3 22:07:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA4C21F89CA for ; Mon, 3 Dec 2012 22:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 kG6t+mUwm1T6 for ; Mon, 3 Dec 2012 22:07:25 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id D3ECD21F89B2 for ; Mon, 3 Dec 2012 22:07:25 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:3233 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Tflf6-0007sj-6y for rtcweb@ietf.org; Tue, 04 Dec 2012 00:07:20 -0600 Message-ID: <50BD92ED.1000703@jesup.org> Date: Tue, 04 Dec 2012 01:06:37 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> <023d01cdd183$76e5e030$64b1a090$@us> <50BD23C0.3010509@omnitor.se> In-Reply-To: <50BD23C0.3010509@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Real-time text implementations X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 06:07:26 -0000 On 12/3/2012 5:12 PM, Gunnar Hellström wrote: > Again moving off the voting subject as requested by Harald. > On 2012-12-03 22:03, Roman Shpount wrote: >> Out of curiosity what commercially available phones/terminals/clients >> currently support real time text apart from Real Jabber? What >> protocols do they currently support? >> _____________ >> Roman Shpount >> > Here are some ( I hope it is OK to mention a bunch of brand names here > - a bit off habit in standards work ) That list says to me that real-world implementation of RFC 4103 is spotty at best. That's not to say it might not increase significantly when national accessibility/emergency requirements go into effect, but I'd say right now it's pretty sparse among VoIP softclients (mostly ones specifically meant for Deaf/HoH it seems). And Asterisk seems big, until you realize it's a PBX and "support" there mean it passes it through, I assume. -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Mon Dec 3 22:30:25 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FC321F89B1 for ; Mon, 3 Dec 2012 22:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 CLKaOkzYgxfG for ; Mon, 3 Dec 2012 22:30:24 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A163621F8986 for ; Mon, 3 Dec 2012 22:30:24 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:3289 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Tfm1P-000DBY-Rd for rtcweb@ietf.org; Tue, 04 Dec 2012 00:30:24 -0600 Message-ID: <50BD9854.6050801@jesup.org> Date: Tue, 04 Dec 2012 01:29:40 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> <50BCFCFE.3080104@nostrum.com> <000001cdd196$796cde90$6c469bb0$@us> In-Reply-To: <000001cdd196$796cde90$6c469bb0$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 06:30:25 -0000 On 12/3/2012 3:40 PM, Richard Shockey wrote: > > On 12/3/12 13:02, Bernard Aboba wrote: >> it's important to keep in mind that "RTT" can mean a capability in some > cases and in others can refer to a specific standard (e.g. RFC 4103 or > XEP-0301). > > Which highlights the problem we'll face if we decide to take this work on. > > We can do RTT right now with data channels. I can hack together a > ridiculously simple example on top of Firefox Nightly build if you want to > see it. > > [RS> ] I have no doubt .. :-) > > > Now, if we decide that we're going to pick through the specific standards > called out by the various regulatory regimes around the global > -- well in excess of 100 -- in order to make sure that we've put extra > special hooks in WebRTC to support whatever technical variant they've > specified, then we have no hope of ever finishing. > > The alternative of picking Gunnar's personal favorite technology (and > ignoring any regulations that elect to go another way) would seem to add > quite a bit of work to come up with what ends up being a somewhat provincial > solution. It would be a half-measure that adds significant work while only > partially meeting your implied goal of meeting all regulations presently in > place or being contemplated around the globe. > [RS> ] > [RS> ] Adam this is a fair position to take. I suspect the general objection > is that given all the requirements for RTCWEB that are out there right now > it's a near impossible task to sort through as it is much less decide on > something new. A reasonable position. RTT is thus a "distraction". > > That said, the opposite position is RTT is just to big to ignore for any > number of reasons and we do need to remember that this week is the 20th > anniversary of SMS and text is near and dear to the hearts of the hearing > impaired community, ES 911 proponents not to mention nearly every human > being under the age of 25. Remember the enormous failures of IM were they > did not interoperate thus granting SMS an open field to market domination. > Silos don't work. You have to choose. That's fine, but I think the right solution is to do that as a separate effort - to standardize RTT over DataChannels (whether it's T.140 or XEP-301 or something else). I think the rtcweb's position should be that RTT should be done over a DataChannel, and thus standardized separately. If other countries require a different RTT protocol, that can be standardized as well (or ones which aren't mandated, such as XEP-301 today). This pushes the *implementation* into the JS layer in a browser, but that's not a bad thing. If there are UI elements that would make supporting it easier in a browser, those can be taken up with the W3C and/or the browser vendors. Even if it were built into core of the browser as a MediaStream, it would still need to surface to the JS app to do the display and input handling anyways. > I still think Bernard's general approach is correct.. try and document what > is out there now and can one or more be selected for MTI with the assumption > that everything else is going to be sent through a gateway. The regulatory > authorities .. if you read CVAA closely for instance, understand there may > be multiple technical approaches to compliance. It's is the attempt to > comply that is "safe harbor" in legal terms. My understanding is that all of these apply to applications (certainly in the FCC world), and so not directly to a browser implementing rtcweb - but we want to make sure applications can comply with standards all over the world - and standards to come. -- Randell Jesup randell-ietf@jesup.org From stefan.lk.hakansson@ericsson.com Mon Dec 3 23:18:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7B321F8932 for ; Mon, 3 Dec 2012 23:18: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.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m9AdYJnGFq1 for ; Mon, 3 Dec 2012 23:18:47 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE7B21F850E for ; Mon, 3 Dec 2012 23:18:46 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-9c-50bda3d4eee8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B4.FB.11564.4D3ADB05; Tue, 4 Dec 2012 08:18:45 +0100 (CET) Received: from [150.132.142.241] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Tue, 4 Dec 2012 08:18:44 +0100 Message-ID: <50BDA3D3.2090707@ericsson.com> Date: Tue, 4 Dec 2012 08:18:43 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ted Hardie References: <50BCFDB3.4010205@nostrum.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUyM+Jvje7VxXsDDCZ857bY83cRu8Wxvi42 i7X/2tktrjduYrdonGvnwOpxZcIVVo+ds+6yeyxZ8pPJY9bOJywei9e/ZwxgjeKySUnNySxL LdK3S+DK6Lh0k7ngEmvFpQUL2RoY97N0MXJwSAiYSFx7mN7FyAlkiklcuLeerYuRi0NI4CSj xJ6Pn1kgnDWMEge3H2MEqeIV0JboWbiTCcRmEVCR2H1pDiuIzSZgI7G2ewpYXFQgQGLxknPs EPWCEidnPmEBsUUElCX2XtkBtoFZYC6jRPeVeWANwgJuEi871rJDbDvCKPHvbQdYB6dAoMTX e4vANjAL2EpcmHOdBcKWl9j+dg4ziC0koCvx7vU91gmMgrOQLJyFpGUWkpYFjMyrGNlzEzNz 0ssNNzECA/rglt+6OxhPnRM5xCjNwaIkzsuVtN9fSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dU A6PXeaF1/w4cdFq8q2DbjQnnO1VWX/HufTwntdQ8/3+XZ/jr5HnVD9KrGt0i9t6etHVpyPEJ qVebE3QelW2IZD6f+yBc9PPN3RNkLxeeK7UKj2oQmNV3TE9kvd59Gxb/mVMUN92r6MxtWzW/ u7d7W7FGe+kU099345Utt7zI0188KbwsfKVdprsSS3FGoqEWc1FxIgBjekraNgIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 07:18:48 -0000 On 12/03/2012 09:15 PM, Ted Hardie wrote: > On Mon, Dec 3, 2012 at 11:54 AM, Stephan Wenger wrote: >> I'm not Mary, but I observe that W3C "Invited Experts" are as the very >> minimum subject to the disclosure part of W3Cs patent policy (section 6.10 >> of http://www.w3.org/Consortium/Patent-Policy-20040205/). > > I think there is a difference between "invited expert" and "observer" in the W3C > rules, but I will leave it the W3C chairs to elaborate. Harald, > Stefan, have I got > that right? AFAIK, that is correct. You don't make any IPR commitments as observer (and, after all, you're just observing); that is something that is done if and when joining the WG. > > Ted > From bernard_aboba@hotmail.com Mon Dec 3 23:31:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4DD21F8968 for ; Mon, 3 Dec 2012 23:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.121 X-Spam-Level: X-Spam-Status: No, score=-101.121 tagged_above=-999 required=5 tests=[AWL=-1.123, BAYES_50=0.001, 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 JFyNJaZUuhS4 for ; Mon, 3 Dec 2012 23:31:44 -0800 (PST) Received: from blu0-omc4-s16.blu0.hotmail.com (blu0-omc4-s16.blu0.hotmail.com [65.55.111.155]) by ietfa.amsl.com (Postfix) with ESMTP id ADDDF21F895B for ; Mon, 3 Dec 2012 23:31:44 -0800 (PST) Received: from BLU002-W54 ([65.55.111.137]) by blu0-omc4-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Dec 2012 23:31:44 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_01be79f1-77fd-4848-806b-b4454f9d12bc_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: Randell Jesup , "rtcweb@ietf.org" Date: Mon, 3 Dec 2012 23:31:44 -0800 Importance: Normal In-Reply-To: <50BD9854.6050801@jesup.org> References: <50B87606.5030802@ericsson.com>,<50BB22EB.1030803@ericsson.com> , <50BCFCFE.3080104@nostrum.com> <000001cdd196$796cde90$6c469bb0$@us>,<50BD9854.6050801@jesup.org> MIME-Version: 1.0 X-OriginalArrivalTime: 04 Dec 2012 07:31:44.0053 (UTC) FILETIME=[68E14650:01CDD1F1] Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 07:31:45 -0000 --_01be79f1-77fd-4848-806b-b4454f9d12bc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Randell said:=20 > My understanding is that all of these apply to applications (certainly in= the FCC world)=2C and so not directly to a browser implementing rtcweb - b= ut=20 > we want to make sure applications can comply with standards all over the = world - and standards to come. [BA] Please take a look at the text of the CVAA=2C M376=2C the Section 255/= 508 Update and the ACS Report and Order. There is nothing in any of those = texts that grants special dispensation to applications or services that are= browser-based. For some background on the history of the movement for ac= cessible communications services=2C the following volume may be of interest= : Karen Peltz Strauss=2C "A New Civil Right: Telecommunications Equality for = Deaf and Hard of Hearing Americans"=2C ISBN-10: 1563682915=2C 2006. = --_01be79f1-77fd-4848-806b-b4454f9d12bc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Randell said:

>= =3B My understanding is that all of these apply to applications (certainly = in the FCC world)=2C and so not directly to a browser implementing rtcweb -= but
>=3B we want to make sure applications can comply with standards= all over the world - and standards to come.

[BA] Please take a look= at the text of the CVAA=2C M376=2C the Section 255/508 Update and the ACS = Report and Order. =3B There is nothing in any of those texts that grant= s special dispensation to applications or services that are browser-based.&= nbsp=3B =3B For some background on the history of the movement for acce= ssible communications services=2C the following volume may be of interest:<= br>
Karen Peltz Strauss=2C "A New Civil Right: Telecommunications Equali= ty for Deaf and Hard of Hearing Americans"=2C IS= BN-10: 1563682915=2C 2006.

= --_01be79f1-77fd-4848-806b-b4454f9d12bc_-- From bernard_aboba@hotmail.com Mon Dec 3 23:45:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464DF21F8920 for ; Mon, 3 Dec 2012 23:45:08 -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.264, 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 JcbRqSCs3qm9 for ; Mon, 3 Dec 2012 23:45:07 -0800 (PST) Received: from blu0-omc2-s30.blu0.hotmail.com (blu0-omc2-s30.blu0.hotmail.com [65.55.111.105]) by ietfa.amsl.com (Postfix) with ESMTP id 20FE821F8500 for ; Mon, 3 Dec 2012 23:45:07 -0800 (PST) Received: from BLU002-W141 ([65.55.111.71]) by blu0-omc2-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Dec 2012 23:45:06 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_1c252704-85d5-41fc-89e9-c278f1ddace5_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: 'Adam Roach' , "rtcweb@ietf.org" Date: Mon, 3 Dec 2012 23:45:06 -0800 Importance: Normal In-Reply-To: <000001cdd196$796cde90$6c469bb0$@us> References: <50B87606.5030802@ericsson.com>,<50BB22EB.1030803@ericsson.com> , <50BCFCFE.3080104@nostrum.com>, <000001cdd196$796cde90$6c469bb0$@us> MIME-Version: 1.0 X-OriginalArrivalTime: 04 Dec 2012 07:45:06.0520 (UTC) FILETIME=[47300580:01CDD1F3] Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 07:45:08 -0000 --_1c252704-85d5-41fc-89e9-c278f1ddace5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I still think Bernard's general approach is correct.. try and document wh= at > is out there now and can one or more be selected for MTI with the assumpt= ion > that everything else is going to be sent through a gateway. The regulato= ry > authorities .. if you read CVAA closely for instance=2C understand there = may > be multiple technical approaches to compliance. It's is the attempt to > comply that is "safe harbor" in legal terms. =20 [BA] Since we are engineers in the IETF=2C it seems to me that we should tr= y to approach this as an engineering problem. That is=2C first figure out = in some detail what it is we're trying to build=2C then after that=2C figur= e out if there is anything missing from our toolkit that would prevent us f= rom building it. WebRTC combining as it does realtime communications with = other facilities of the Web (including accessibility functionality) would a= ppear to have promise as a platform for the creation and deployment of acce= ssible communications applications and services. =20 = --_1c252704-85d5-41fc-89e9-c278f1ddace5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B I still think Be= rnard's general approach is correct.. try and document what
>=3B is ou= t there now and can one or more be selected for MTI with the assumption
= >=3B that everything else is going to be sent through a gateway. The reg= ulatory
>=3B authorities .. if you read CVAA closely for instance=2C u= nderstand there may
>=3B be multiple technical approaches to complianc= e. It's is the attempt to
>=3B comply that is "safe harbor" in legal = terms.

[BA] Since we are engineers in the IETF=2C it seems to me t= hat we should try to approach this as an engineering problem. =3B That = is=2C first figure out in some detail what it is we're trying to build=2C t= hen after that=2C figure out if there is anything missing from our toolkit = that would prevent us from building it. =3B WebRTC combining as it does= realtime communications with other facilities of the Web (including access= ibility functionality) would appear to have promise as a platform for the c= reation and deployment of accessible communications applications and servic= es. =3B
= --_1c252704-85d5-41fc-89e9-c278f1ddace5_-- From stefan.lk.hakansson@ericsson.com Mon Dec 3 23:50:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D3821F8967 for ; Mon, 3 Dec 2012 23:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZB6M5JopzDf for ; Mon, 3 Dec 2012 23:50:02 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B503721F8690 for ; Mon, 3 Dec 2012 23:50:01 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-bb-50bdab223430 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2C.FF.26143.22BADB05; Tue, 4 Dec 2012 08:49:54 +0100 (CET) Received: from [150.132.142.241] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Tue, 4 Dec 2012 08:49:54 +0100 Message-ID: <50BDAB22.4060702@ericsson.com> Date: Tue, 4 Dec 2012 08:49:54 +0100 From: Stefan Hakansson LK 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: <50B87606.5030802@ericsson.com>, <50BB22EB.1030803@ericsson.com> , <50BCFCFE.3080104@nostrum.com> <000001cdd196$796cde90$6c469bb0$@us>, <50BD9854.6050801@jesup.org> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+Jvja7S6r0BBt3TdS3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpHO92wFe9kr3rbPZmlg/M7axcjJISFgIrF94y12CFtM4sK9 9WxdjFwcQgInGSWefWtggXDWMEpMv3+LDaSKV0Bb4snz5UA2BweLgIrEwg91IGE2ARuJtd1T mEBsUYEAicVLzrFDlAtKnJz5hAXEFhEQltj6qhesRljASmJW1ySo+e3MEtNa/4IlOIESZ3bu BWtgFrCVuDDnOpQtL7H97RxmEFtIQFfi3et7rBMYBWYh2TELScssJC0LGJlXMbLnJmbmpJcb bWIEBtrBLb9VdzDeOSdyiFGag0VJnNd66x5/IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYzd hbnhL77G3med/5Ax5krXw0qG9CvXmpMNN184rmkvV+WV3p7mozAvnE/ClOda4JuOjayTCvRk Z4b1LfMU07a+xeX/UeNp3Md6qwTDgrq3t6JeCp30ffDML2Mt03v5pCU6txzbwjTTXzyrDa9I 0OdbZ57hbTzDX3z7uklOQqwv2ovMmFaeVWIpzkg01GIuKk4EAHIQk+ICAgAA Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 07:50:02 -0000 On 12/04/2012 08:31 AM, Bernard Aboba wrote: > Randell said: > > > My understanding is that all of these apply to applications > (certainly in the FCC world), and so not directly to a browser > implementing rtcweb - but > > we want to make sure applications can comply with standards all over > the world - and standards to come. > > [BA] Please take a look at the text of the CVAA, M376, the Section > 255/508 Update and the ACS Report and Order. There is nothing in any of > those texts that grants special dispensation to applications or services > that are browser-based. The key words to me are "applications or services". This responsibility lies with those developing the apps and offering the services, not with the browser itself. That said, why don't we go ahead and study this as a separate work item (as already proposed) to make sure it is possible to support (with a reasonable effort) using a browser as platform? From christer.holmberg@ericsson.com Tue Dec 4 00:14:38 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA57B21F89B0 for ; Tue, 4 Dec 2012 00:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.855 X-Spam-Level: X-Spam-Status: No, score=-5.855 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQuatLm8p1Tt for ; Tue, 4 Dec 2012 00:14:37 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EB8DC21F8988 for ; Tue, 4 Dec 2012 00:14:36 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-a6-50bdb0eb77d1 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 83.74.26143.BE0BDB05; Tue, 4 Dec 2012 09:14:35 +0100 (CET) Received: from ESESSHC016.ericsson.se (153.88.183.66) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 4 Dec 2012 09:14:35 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0318.001; Tue, 4 Dec 2012 09:14:35 +0100 From: Christer Holmberg To: Andrew Allen , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC Thread-Index: AQHN0YyfvTpLR8h5xEGflJOq3FHpFpgHbC4AgAAFtwCAAA1uAIAAzCAg Date: Tue, 4 Dec 2012 08:14:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B04DD7F@ESESSMB209.ericsson.se> References: <50BCFDB3.4010205@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvje7rDXsDDC5c1beY1rmV2WLtv3Z2 ByaPJUt+MnlM+LKSJYApissmJTUnsyy1SN8ugStj4cbsgkdiFXvmXGNpYHwt1MXIySEhYCKx 9+4uJghbTOLCvfVsXYxcHEICJxkl/v6cwALh7GCUaDl4lwnCWcwosf/MWsYuRg4ONgELie5/ 2iDdIgJuEnv2XmAGsYWB7Elb3zBBxN0lHl/uYgUpB6k5Nl0OJMwioCJx9sAjFhCbV8Bbor3x DtTidiaJrZfawBKcAp4SbSvugdmMQNd9P7UGbCazgLjErSfzoa4WkFiy5zwzhC0q8fLxP1YI W1Fi59l2Zoh6HYkFuz+xQdjaEssWvmaGWCwocXLmE7D5QkDxlsUT2Ccwis9CsmIWkvZZSNpn IWlfwMiyipE9NzEzJ73caBMjMHYObvmtuoPxzjmRQ4zSHCxK4rzWW/f4CwmkJ5akZqemFqQW xReV5qQWH2Jk4uCUamDMWOjTwhM/92X901X1dxbbrjJx3PuV/8+upLP3N0ZcW/z+292jPI7l d44IzDLlnWy1y2fGN+fzqbOZNJp7/rrs3PTx4ClFZS79Oz8vn/TlnneX4ylXHKvIrSk975ju dzdFt/Vf3jXr3/LL0tXGbHmsF6UUX9/IdtVU9zW92PeK+3XnlOsfsvPMlFiKMxINtZiLihMB Kj4RAmsCAAA= Subject: Re: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 08:14:39 -0000 Hi Andrew, It was earlier indicated that the main focus will be on JSEP and SDP. Regards, Christer -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Andrew Allen Sent: 3. joulukuuta 2012 23:03 To: rtcweb@ietf.org Subject: Re: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC I think for interim meetings it would be very helpful to have the agenda ou= t as far in advance as possible in order to help justify the expense of tra= velling for what looks like maybe a day and a half meeting for at least som= e from the IETF side. It was made clear in Atlanta that the video codec MTI issue will not be dis= cussed but what is planned to be?=20 RTCweb has many active drafts encompassing a broad range of topics so it wo= uld be very useful to know before committing to travel if the issues you ha= ve interest in are likely to be discussed otherwise it may end up as 3 days= of thumb twiddling at considerable expense for some and potentially jeopar= dize the likelihood of them obtaining travel authorization for future meeti= ngs. Andrew > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 > Behalf Of Ted Hardie > Sent: Monday, December 03, 2012 2:15 PM > To: Stephan Wenger > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC >=20 > On Mon, Dec 3, 2012 at 11:54 AM, Stephan Wenger wrote: > > I'm not Mary, but I observe that W3C "Invited Experts" are as the=20 > > very minimum subject to the disclosure part of W3Cs patent policy=20 > > (section > 6.10 > > of http://www.w3.org/Consortium/Patent-Policy-20040205/). >=20 > I think there is a difference between "invited expert" and "observer"=20 > in the W3C rules, but I will leave it the W3C chairs to elaborate. =20 > Harald, Stefan, have I got that right? >=20 > Ted > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Tue Dec 4 00:37:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0835221F84FC for ; Tue, 4 Dec 2012 00:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 XneVezjIC4DA for ; Tue, 4 Dec 2012 00:37:00 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE3D21F88D8 for ; Tue, 4 Dec 2012 00:37:00 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:4739 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Tfnzv-0008dB-9x for rtcweb@ietf.org; Tue, 04 Dec 2012 02:36:59 -0600 Message-ID: <50BDB5FF.3020605@jesup.org> Date: Tue, 04 Dec 2012 03:36:15 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com>, <50BB22EB.1030803@ericsson.com> , <50BCFCFE.3080104@nostrum.com> <000001cdd196$796cde90$6c469bb0$@us>, <50BD9854.6050801@jesup.org> <50BDAB22.4060702@ericsson.com> In-Reply-To: <50BDAB22.4060702@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 08:37:01 -0000 On 12/4/2012 2:49 AM, Stefan Hakansson LK wrote: > On 12/04/2012 08:31 AM, Bernard Aboba wrote: >> Randell said: >> >> > My understanding is that all of these apply to applications >> (certainly in the FCC world), and so not directly to a browser >> implementing rtcweb - but >> > we want to make sure applications can comply with standards all over >> the world - and standards to come. >> >> [BA] Please take a look at the text of the CVAA, M376, the Section >> 255/508 Update and the ACS Report and Order. There is nothing in any of >> those texts that grants special dispensation to applications or services >> that are browser-based. > > The key words to me are "applications or services". This > responsibility lies with those developing the apps and offering the > services, not with the browser itself. That said, why don't we go > ahead and study this as a separate work item (as already proposed) to > make sure it is possible to support (with a reasonable effort) using a > browser as platform? Correct IMHO. And if you read a bunch of the FCC rulemaking (see the stuff I linked last week), you'll see they very purposely put the onus on service providers and equipment manufacturers, and not on any others inbetween (and in practice it's largely on the service provider). I.e. if you have an "advanced communication service", you're beholden for it to be accessible, and to choose tools/etc that allow you to do that. Thus, we should make certain webrtc is a viable *tool*, but browser vendors (if they don't also act as Service Providers with apps) are not directly responsible to the FCC on this. Note: IANAL of course; I just play one on mailing lists. (God, I thought I'd gotten away from being an amateur FCC lawyer when I stopped working for a company supplying VRS Service Providers with hardware....) :-( -- Randell Jesup randell-ietf@jesup.org From gunnar.hellstrom@omnitor.se Tue Dec 4 01:38:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A6F21F86AB for ; Tue, 4 Dec 2012 01:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mv-RmmCJOjtG for ; Tue, 4 Dec 2012 01:38:42 -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 AA57F21F85EE for ; Tue, 4 Dec 2012 01:38:41 -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 ; Tue, 4 Dec 2012 10:37:51 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-09-01.atm.binero.net (Postfix) with ESMTPA id 31EF93A142 for ; Tue, 4 Dec 2012 10:37:51 +0100 (CET) Message-ID: <50BDC46F.3070705@omnitor.se> Date: Tue, 04 Dec 2012 10:37:51 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com>, <50BB22EB.1030803@ericsson.com> , <50BCFCFE.3080104@nostrum.com> <000001cdd196$796cde90$6c469bb0$@us>, <50BD9854.6050801@jesup.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040009030604070508010401" Subject: [rtcweb] Reasons for real-time text and implementation variants X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 09:38:43 -0000 This is a multi-part message in MIME format. --------------040009030604070508010401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Aain taking subject off from the voting subject. On 2012-12-04 08:31, Bernard Aboba wrote: > Randell said: > > > My understanding is that all of these apply to applications > (certainly in the FCC world), and so not directly to a browser > implementing rtcweb - but > > we want to make sure applications can comply with standards all over > the world - and standards to come. > > [BA] Please take a look at the text of the CVAA, M376, the Section > 255/508 Update and the ACS Report and Order. There is nothing in any > of those texts that grants special dispensation to applications or > services that are browser-based. For some background on the history > of the movement for accessible communications services, the following > volume may be of interest: > > Karen Peltz Strauss, "A New Civil Right: Telecommunications Equality > for Deaf and Hard of Hearing Americans", ISBN-10:1563682915, 2006. Yes, regulations require real-time text anywhere where there is voice communication. Only where the call control environment is known, the exact technical method is sometimes prescribed. As for SIP it is in some cases required to be T.140/RFC 4103. It is not more strange than rtcweb defining if H.264 or VP8 shall be the mandated fall-back for video in order to assure interoperability. I hope that we can focus less on the regulated requirements and instead try to specify and do something of mainstream interest that also fulfills the regulations. The usability research I pointed at recently, and the self test I described you can make, clearly indicate that real-time text would be a popular mainstream feature. So let us try to define it with that goal. RTCWEB gives the image of being at the front end of innovation, so it would be logical to pick up this indication from usability research and combine a better way of texting together with video and audio. I still see four main options for the implementation: 1. As a third RTP carried medium in rtcweb, using T.140/RFC4103 with redundancy. (over AVPF profile as required in rtcweb.) 2. T.140 transmitted over a well specified use of the rtcweb data channel, using a partially-reliable variant with delivery in order and indication of loss. I think time-sampled transmission in 300 ms chunks is best in order to not overload narrow channels and internal signaling in case of use for rapid text streams as from speech-to-text. 3. XMPP with XEP-0301 XML based real-time text separately implemented but well coordinated in the same web page as rtcweb audio and video. In all three cases, there is a need to be able to combine the call and the media into a SIP session by a gateway, and this must be possible for both the cases when the other party uses AVPF and AVP for its RTP. Many implementations do not use AVPF today for any of its media, so there will be a need to take rtcweb media through a media gateway anyway for audio and video as well as for real-time text. More reasoning around the options: 1. T.140/RFC 4103 as a new rtcweb medium. Real-time text is seen as a third medium in the call as it has been done before in SIP, H.320, H.323, H.324. It handles its own reliability through inexpensive and rapid redundancy. API:s to JS are needed. Coordination with SIP need often to be done in gateways, because no current implementation of AVPF based RFC4103 exists. ( same for other media ). 2. T.140/rtcweb data channel. It may be true that the rtcweb data channel is a good mechanism to select for transport of T.140 text. My first impression was that it was immaturely specified that it would not be safe to use it as a base. But that will surely be amended. We can use Adam's offered rapid development as a proof of concept, and make sure that the data channel and the use of it for real-time text will be sufficiently specified to assure interoperability and good functionality. The coordination with the call and the other media in a gateway looks doable. All three will at least be managed through SDP, and mapping between SDP for data channel and SDP for RTP/RFC4103 looks manageable. 3. Separate XMPP/XEP-0301. If there are big actors planning to combine rtcweb audio and video with XMPP messaging into a standardized multimedia service, I would recommend to use XEP-0301 in that environment to get more life into the text part of this concept. It would be adaptation to both mainstream users preferences and regulative requirements. The coordination with SIP calls need to be done in a gateway for this case as well, and may be more tricky than for case 2, because the rtt medium is not at all SDP negotiated on the browser side. Summary: I think that the gatewaying issues are crucial for selecting the right way here. Have anything been done to specify gateway procedures? How would case 2 and 3 be handled in gateways? And, even if case 3 is selected, where the transport of real-time text itself is not a rtcweb issue, specification in close coordination with rtcweb progress is needed because of the interoperability requirements. //Gunnar --------------040009030604070508010401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Aain taking subject off from the voting subject.

On 2012-12-04 08:31, Bernard Aboba wrote:
Randell said:

> My understanding is that all of these apply to applications (certainly in the FCC world), and so not directly to a browser implementing rtcweb - but
> we want to make sure applications can comply with standards all over the world - and standards to come.

[BA] Please take a look at the text of the CVAA, M376, the Section 255/508 Update and the ACS Report and Order.  There is nothing in any of those texts that grants special dispensation to applications or services that are browser-based.   For some background on the history of the movement for accessible communications services, the following volume may be of interest:

Karen Peltz Strauss, "A New Civil Right: Telecommunications Equality for Deaf and Hard of Hearing Americans", ISBN-10: 1563682915, 2006.

Yes, regulations require real-time text anywhere where there is voice communication. Only where the call control environment is known, the exact technical method is sometimes prescribed. As for SIP it is in some cases required to be T.140/RFC 4103.
It is not more strange than rtcweb defining if H.264 or VP8 shall be the mandated fall-back for video in order to assure interoperability.

I hope that we can focus less on the regulated requirements and instead try to specify and do something of mainstream interest that also fulfills the regulations.

The usability research I pointed at recently, and the self test I described you can make, clearly indicate that real-time text would be a popular mainstream feature. So let us try to define it with that goal. RTCWEB gives the image of being at the front end of innovation, so it would be logical to pick up this indication from usability research and combine a better way of texting together with video and audio.

I still see four main options for the implementation:

1. As a third RTP carried medium in rtcweb, using T.140/RFC4103 with redundancy. (over AVPF profile as required in rtcweb.)

2. T.140 transmitted over a well specified use of the rtcweb data channel, using a partially-reliable variant with delivery in order and indication of loss. I think time-sampled transmission in 300 ms chunks is best in order to not overload narrow channels and internal signaling in case of use for rapid text streams as from speech-to-text.

3. XMPP with XEP-0301 XML based real-time text separately implemented but well coordinated in the same web page as rtcweb audio and video.

In all three cases, there is a need to be able to combine the call and the media into a SIP session by a gateway, and this must be possible for both the cases when the other party uses AVPF and AVP for its RTP. Many implementations do not use AVPF today for any of its media, so there will be a need to take rtcweb media through a media gateway anyway for audio and video as well as for real-time text.

More reasoning around the options:

1. T.140/RFC 4103 as a new rtcweb medium.
Real-time text is seen as a third medium in the call as it has been done before in SIP, H.320, H.323, H.324. It handles its own reliability through inexpensive and rapid redundancy. API:s to JS are needed.
Coordination with SIP need often to be done in gateways, because no current implementation of AVPF based RFC4103 exists.
( same for other media ).

2. T.140/rtcweb data channel. It may be true that the rtcweb data channel is a good mechanism to select for transport of T.140 text. My first impression was that it was immaturely specified that it would not be safe to use it as a base. But that will surely be amended. We can use Adam's offered rapid development as a proof of concept, and make sure that the data channel and the use of it for real-time text will be sufficiently specified to assure interoperability and good functionality. The coordination with the call and the other media in a gateway looks doable. All three will at least be managed through SDP, and mapping between SDP for data channel and SDP for RTP/RFC4103 looks manageable.

3. Separate XMPP/XEP-0301. If there are big actors planning to combine rtcweb audio and video with XMPP messaging into a standardized multimedia service, I would recommend to use XEP-0301 in that environment to get more life into the text part of this concept. It would be adaptation to both mainstream users preferences and regulative requirements. The coordination with SIP calls need to be done in a gateway for this case as well, and may be more tricky than for case 2, because the rtt medium is not at all SDP negotiated on the browser side.

Summary:
I think that the gatewaying issues are crucial for selecting the right way here. Have anything been done to specify gateway procedures? How would case 2 and 3 be handled in gateways?

And, even if case 3 is selected, where the transport of real-time text itself is not a rtcweb issue, specification in close coordination with rtcweb progress is needed because of the interoperability requirements.

//Gunnar

--------------040009030604070508010401-- From eburger@standardstrack.com Tue Dec 4 05:25:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1067021F8A88 for ; Tue, 4 Dec 2012 05:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_16=0.6, 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 esXDYBVd8O9s for ; Tue, 4 Dec 2012 05:25:01 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 822CA21F871F for ; Tue, 4 Dec 2012 05:25:01 -0800 (PST) Received: from dhcp63-140-165-138.hil-sjchshx.sjc.wayport.net ([63.140.165.138]:64478) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TfsUe-0000Mn-HB for rtcweb@ietf.org; Tue, 04 Dec 2012 05:25:00 -0800 From: Eric Burger Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/signed; boundary=Apple-Mail-87-510662327; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 4 Dec 2012 05:25:00 -0800 In-Reply-To: <50BD9854.6050801@jesup.org> To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> <50BCFCFE.3080104@nostrum.com> <000001cdd196$796cde90$6c469bb0$@us> <50BD9854.6050801@jesup.org> Message-Id: <38F9046C-6AA1-44ED-B4C0-9F9E0BA876F1@standardstrack.com> X-Mailer: Apple Mail (2.1085) 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: Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 13:25:02 -0000 --Apple-Mail-87-510662327 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii WOAH! If it is a simple matter of implementation in the JS layer of the = browser to do RTT, then I need to give Cullen his CDN 100 back, because = what this is saying is RTCWEB was finished before it started: I could do = any media in a browser in the JS layer. It was Cullen who took me for a = sucker bet, not the other way around, because RTCWEB had nothing to do. = [The bet was that RTCWEB would be *finished* in one year. I took, how = shall we say, the long view.] Others have piped in with US and European *laws* requiring RTT or other = support for hearing impaired (and visually impaired and speech impaired) = individuals, so I will not reiterate them here. As for the stance that we do not need to care about these laws and = regulations because the onus is on the people actually deploying the = applications and not the manufacturers of the applications, browsers, or = servers, I would offer that for once the governing bodies and regulators = got it right. Would you rather have a law that says, "Make sure you = meet this goal" or a law that says, "You must implement this technology = in this way with these tools"? Note that if we do not bake in support, = the latter approach is what we are likely to end up with. =20 And, that is how we end up with H.rtcweb. No joke. The converse may also be true. While there are a few approaches to RTT, = I would offer that if we bake one into RTCWEB, or at least have one as a = reference implementation, I would not be surprised if those = jurisdictions with other approaches either migrate our way or gateway = from our way. This is an opportunity for IETF leadership. That is a = much better situation than IETF irrelevance. If pretty much every RTC application made available in the Western world = requires RTT support, is our position going to be that every developer = has to build, buy, copy, or steal RTT support infrastructure? Or, is = our position that since pretty much every RTC application needs it, it = should be a part of the infrastructure, i.e., supplied by the browser? = If the logic is applications can do it on their own, then let's again = declare victory and not spend the next five years arguing over video = codecs as that can be done above the browser. On Dec 3, 2012, at 10:29 PM, Randell Jesup wrote: > That's fine, but I think the right solution is to do that as a = separate effort > - to standardize RTT over DataChannels (whether it's T.140 or XEP-301 = or > something else). I think the rtcweb's position should be that RTT = should be > done over a DataChannel, and thus standardized separately. If other = countries > require a different RTT protocol, that can be standardized as well (or = ones > which aren't mandated, such as XEP-301 today). >=20 > This pushes the *implementation* into the JS layer in a browser, but = that's > not a bad thing. If there are UI elements that would make supporting = it easier > in a browser, those can be taken up with the W3C and/or the browser = vendors. > Even if it were built into core of the browser as a MediaStream, it = would still > need to surface to the JS app to do the display and input handling = anyways. --Apple-Mail-87-510662327 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMjA0MTMyNTAxWjAjBgkqhkiG9w0BCQQxFgQU Kgw1h/5sr4VQkgxkFTJY7qCp2DUwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAT63VcbEf4enk23qC5lhGP1R67mF/kzMPHLofsyK7LgFnkzuQ1w6/ kXHSfoAUoj+cljTB4/dmzwjLgp90W5Z5Y8rqufGivhn8hgQRcvha1H93wEd88bnMF4B+J1oNVSbq dYf4tcUemvTRBiT3CBA38vBFY1FdEWBHtLwfTtdAVwr5nz7c7BPWKvci7q8zeKfzRZOxOksh+L3M VjQRWm3xZZ1OEerQojvnjtHXCyu0RwgW5HOs5gENxuRQ6hBIR2sSgRjBeR8Ku3XHHKeHWxcqPg/g 59JJSe9m89Z/kK0XP2L/Vpq4xCW+tMJ8Ww1lMNf/97KASMqxPJfl2nuEqgFOGQAAAAAAAA== --Apple-Mail-87-510662327-- From richard@shockey.us Tue Dec 4 06:20:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85B621F8B97 for ; Tue, 4 Dec 2012 06:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.093 X-Spam-Level: X-Spam-Status: No, score=-102.093 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPHoBYTmAaV5 for ; Tue, 4 Dec 2012 06:20:11 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id A675621F8A85 for ; Tue, 4 Dec 2012 06:20:11 -0800 (PST) Received: (qmail 12826 invoked by uid 0); 4 Dec 2012 14:19:50 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy8.bluehost.com with SMTP; 4 Dec 2012 14:19:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=CPuHSDijcMmf8JvPM3HEzzby+3+8FAneF6LXuoAirhg=; b=dv0ucVeIceURs2au4XzPucg9S2M81dBh3UUwB3PqG2oBqeGG6SscyTyPBkOz+hLbTvaJIJb5ZzxY68jIR2onZQrCFEEtUGZG9QTWmvVf/1eIyGhH2CEvhYeKgubFBwe+; Received: from [71.191.243.130] (port=50993 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TftLh-0005JR-OY; Tue, 04 Dec 2012 07:19:49 -0700 From: "Richard Shockey" To: "'Randell Jesup'" , References: <50B87606.5030802@ericsson.com>, <50BB22EB.1030803@ericsson.com> , <50BCFCFE.3080104@nostrum.com> <000001cdd196$796cde90$6c469bb0$@us>, <50BD9854.6050801@jesup.org> <50BDAB22.4060702@ericsson.com> <50BDB5FF.3020605@jesup.org> In-Reply-To: <50BDB5FF.3020605@jesup.org> Date: Tue, 4 Dec 2012 09:19:50 -0500 Message-ID: <00dd01cdd22a$6c7ca5a0$4575f0e0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3R+ou8/rwpUwJNTceWasDn/I2NSQAL0Npg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 14:20:16 -0000 Correct IMHO. And if you read a bunch of the FCC rulemaking (see the stuff I linked last week), you'll see they very purposely put the onus on service providers and equipment manufacturers, and not on any others inbetween (and in practice it's largely on the service provider). I.e. if you have an "advanced communication service", you're beholden for it to be accessible, and to choose tools/etc that allow you to do that. Thus, we should make certain webrtc is a viable *tool*, but browser vendors (if they don't also act as Service Providers with apps) are not directly responsible to the FCC on this. Note: IANAL of course; I just play one on mailing lists. (God, I thought I'd gotten away from being an amateur FCC lawyer when I stopped working for a company supplying VRS Service Providers with hardware....) :-( [RS> ] [RS> ] Sigh ... it's a dirty job but some of us have to do it. From harald@alvestrand.no Tue Dec 4 06:21:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5DE21F8AF1 for ; Tue, 4 Dec 2012 06:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.414 X-Spam-Level: X-Spam-Status: No, score=-110.414 tagged_above=-999 required=5 tests=[AWL=0.184, 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 VjPufw+u6dX2 for ; Tue, 4 Dec 2012 06:21:00 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9E96921F8AE4 for ; Tue, 4 Dec 2012 06:20:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A4FE739E238 for ; Tue, 4 Dec 2012 15:20: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 kfibWyNJ5Sz6 for ; Tue, 4 Dec 2012 15:20:57 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:99c7:ec3c:d07d:2736] (unknown [IPv6:2001:470:de0a:27:99c7:ec3c:d07d:2736]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id C68D539E11A for ; Tue, 4 Dec 2012 15:20:57 +0100 (CET) Message-ID: <50BE06C9.6050605@alvestrand.no> Date: Tue, 04 Dec 2012 15:20:57 +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: <50B87606.5030802@ericsson.com>, <50BB22EB.1030803@ericsson.com> , <50BCFCFE.3080104@nostrum.com>, <000001cdd196$796cde90$6c469bb0$@us> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070802020903030906060803" Subject: [rtcweb] Engineering approach to RTT communication (Re: Consensus call on Text Communication) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 14:21:01 -0000 This is a multi-part message in MIME format. --------------070802020903030906060803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Changing the subject as usual... On 12/04/2012 08:45 AM, Bernard Aboba wrote: > > > I still think Bernard's general approach is correct.. try and > document what > > is out there now and can one or more be selected for MTI with the > assumption > > that everything else is going to be sent through a gateway. The > regulatory > > authorities .. if you read CVAA closely for instance, understand > there may > > be multiple technical approaches to compliance. It's is the attempt to > > comply that is "safe harbor" in legal terms. > > [BA] Since we are engineers in the IETF, it seems to me that we should > try to approach this as an engineering problem. That is, first figure > out in some detail what it is we're trying to build, then after that, > figure out if there is anything missing from our toolkit that would > prevent us from building it. WebRTC combining as it does realtime > communications with other facilities of the Web (including > accessibility functionality) would appear to have promise as a > platform for the creation and deployment of accessible communications > applications and services. ... and phrased like this, the question then becomes: Is this within charter for RTCWEB, or does it require a new effort? --------------070802020903030906060803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Changing the subject as usual...

On 12/04/2012 08:45 AM, Bernard Aboba wrote:

> I still think Bernard's general approach is correct.. try and document what
> is out there now and can one or more be selected for MTI with the assumption
> that everything else is going to be sent through a gateway. The regulatory
> authorities .. if you read CVAA closely for instance, understand there may
> be multiple technical approaches to compliance. It's is the attempt to
> comply that is "safe harbor" in legal terms.

[BA] Since we are engineers in the IETF, it seems to me that we should try to approach this as an engineering problem.  That is, first figure out in some detail what it is we're trying to build, then after that, figure out if there is anything missing from our toolkit that would prevent us from building it.  WebRTC combining as it does realtime communications with other facilities of the Web (including accessibility functionality) would appear to have promise as a platform for the creation and deployment of accessible communications applications and services. 

... and phrased like this, the question then becomes:

Is this within charter for RTCWEB, or does it require a new effort?


--------------070802020903030906060803-- From richard@shockey.us Tue Dec 4 06:38:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1886121F8AF0 for ; Tue, 4 Dec 2012 06:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.121 X-Spam-Level: X-Spam-Status: No, score=-102.121 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoeNvT-LZALD for ; Tue, 4 Dec 2012 06:38:24 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 1796121F8ACA for ; Tue, 4 Dec 2012 06:38:24 -0800 (PST) Received: (qmail 27993 invoked by uid 0); 4 Dec 2012 14:37:59 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 4 Dec 2012 14:37:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=ihUNgdAS/E/4aVgWWqCAAVczDTVdUpIXLFT9YjxUBBw=; b=IWB5t6C6pxo4EwBzYPsj0fvSLrA1JD5+0xGMydVIc/GWrNCVDKK4Dqq5u2YNn7hSXOMa3QfEJTK3DnfHr0FJQ7YOd6piFdYqQ39lzfH3c4Iv7MW5z6aG/ShYXvLOzRJQ; Received: from [71.191.243.130] (port=51548 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TftdG-0007dx-R2 for rtcweb@ietf.org; Tue, 04 Dec 2012 07:37:59 -0700 From: "Richard Shockey" To: References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> <50BCFCFE.3080104@nostrum.com> <000001cdd196$796cde90$6c469bb0$@us> <50BD9854.6050801@jesup.org> <38F9046C-6AA1-44ED-B4C0-9F9E0BA876F1@standardstrack.com> In-Reply-To: <38F9046C-6AA1-44ED-B4C0-9F9E0BA876F1@standardstrack.com> Date: Tue, 4 Dec 2012 09:37:59 -0500 Message-ID: <00de01cdd22c$f5a15f40$e0e41dc0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3SIsibn1ih6mXIRQWj3AvG8Sri0AACS9sg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 14:38:31 -0000 The converse may also be true. While there are a few approaches to RTT, I would offer that if we bake one into RTCWEB, or at least have one as a reference implementation, I would not be surprised if those jurisdictions with other approaches either migrate our way or gateway from our way. This is an opportunity for IETF leadership. That is a much better situation than IETF irrelevance. [RS> ] [RS> ] Thank you again. You have summarized my point better than I could have. You cannot simply say, "Well the browser doesn't need to deal with this." It's a recipe for fragmentation and silos. Evaluate the options, as Bernard suggests, but for the sake of interoperability choose at least one reference implementation. If pretty much every RTC application made available in the Western world requires RTT support, is our position going to be that every developer has to build, buy, copy, or steal RTT support infrastructure? Or, is our position that since pretty much every RTC application needs it, it should be a part of the infrastructure, i.e., supplied by the browser? If the logic is applications can do it on their own, then let's again declare victory and not spend the next five years arguing over video codecs as that can be done above the browser. On Dec 3, 2012, at 10:29 PM, Randell Jesup wrote: From mary.ietf.barnes@gmail.com Tue Dec 4 07:48:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394E621F8C3B for ; Tue, 4 Dec 2012 07:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.555 X-Spam-Level: X-Spam-Status: No, score=-103.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 iG6UB7aDpjvR for ; Tue, 4 Dec 2012 07:47:59 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF2921F8C3A for ; Tue, 4 Dec 2012 07:47:59 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3485153lah.31 for ; Tue, 04 Dec 2012 07:47:58 -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=R3OSQAhHt+RgDloPsQ1DKJ6ha6FIYBUws7p3IeqgoWg=; b=ZEw3Ww7RhsA+PplzmVjw5MgkSammF/orPKYbJZkXqFKYNZGXDkccJb+Cnn/fMgEVVF QgmMPtkJusXRJF1c0leqjsn67dyRyhPVN0wIwvJWl9Uvir1sctCWS3h4f7n2zL3MmwEG t6A4b6oFeRp+B91dH7uGrgL//LGBJ29YCxBU62t+vjN5LHiN5SZQDlFYeUbctQUpqYSw il6DTy30MF3qP4BkMOeRMG1ayXfg6VRiV/B/qW5qPY6ET+hZlXCk2/EGZO5YKWtn7pAZ Aq69K89TN/Yg22vOdWQXx4wrhkQpW+ey3CzRJ5g0lT09TR7YuKu6OegI95d6y/KcYaVK lGrg== MIME-Version: 1.0 Received: by 10.112.103.135 with SMTP id fw7mr6036169lbb.17.1354636078335; Tue, 04 Dec 2012 07:47:58 -0800 (PST) Received: by 10.114.20.41 with HTTP; Tue, 4 Dec 2012 07:47:58 -0800 (PST) In-Reply-To: <50BCFDB3.4010205@nostrum.com> References: <50BCFDB3.4010205@nostrum.com> Date: Tue, 4 Dec 2012 09:47:58 -0600 Message-ID: From: Mary Barnes To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 15:48:00 -0000 On Mon, Dec 3, 2012 at 1:29 PM, Adam Roach wrote: > On 12/3/12 10:49, Ted Hardie wrote: >> >> I'm a little unclear about the other issue. If the IETF side is >> meeting from 1:00 to close of day >> on three days, I think we can make it clear that we're under Note Well >> rules for those times >> without any issues. Or are you thinking that you or others would like >> to attend only the IETF >> side of the meeting and thus would prefer it be some 1 1/2 day period >> during the currently identified >> time? > > > The way I read Mary's concern is that non-W3C members might be forced to > spend the WebRTC portion of the meeting twiddling their thumbs. If we make > it clearer ahead of time that the WebRTC chairs have explicitly granted > observation permission to all attendees -- regardless of whether they are > W3C members -- then I would imagine that the concerns should be addressed. > > Is that about right, Mary? [MB] That was partly my concern. My understanding was that each individual needs to request permission to attend as an observer. As Harald noted, at this point, no one has been turned down and I honestly don't know how strict they have been in ensuring that all observers had been approved. However, I did not read Harald's email as a blanket approval. My initial concern was Ted's statement that we should plan to be there for all three days as they had not yet decided how to split the time. If the split is posted by the date that Harald noted, then that's fine - we can all plan accordingly. If it's not decided until we get there, that's a problem. I do think it must be quite clear what meeting we might be sitting in on at any point in time. [/MB] > > /a From ted.ietf@gmail.com Tue Dec 4 08:05:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F1721F8C3D for ; Tue, 4 Dec 2012 08:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.06 X-Spam-Level: X-Spam-Status: No, score=-3.06 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, J_CHICKENPOX_12=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 p02hFqKCxTso for ; Tue, 4 Dec 2012 08:05:09 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D4D2B21F8C3F for ; Tue, 4 Dec 2012 08:05:08 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so3564094vcb.31 for ; Tue, 04 Dec 2012 08:05:08 -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=isoJV086L4Whp1ylGjA+zXmJAjh1HfjZcetAOkbdoLM=; b=eGBH2sNlN/fjcaBIc1jMcwX7HzRSQzkpVHVyzTaFh7Ufqg6+omjPODKNcccnSHh07H 5vV2rOBq0HM8ilONDsYK8eMu2Nt5Jk9CWAIYHYiTjf7gdQpK7W1CC7oDFPc5mFrtkGM0 H9mUKIBVMsmiUKM/SbeetcKBWG/dkt2/Jbnu0yuDbli86z+sgdWzTQmctJqK6gVbHtWH EUqBf4uKfcOYrwiIjwYmOX6lYtZgOx+8xv1VRmPnTxkVJNbeP8+K6Er1QbMi3lLhCets B9TQWk9g415B4C1jjMT3Ezsr5vdd4bwE7MWNiTKzSMKC36J2R/HNBrmzfH8lIuDTcqrt Ss8g== MIME-Version: 1.0 Received: by 10.52.179.231 with SMTP id dj7mr10371710vdc.108.1354637108141; Tue, 04 Dec 2012 08:05:08 -0800 (PST) Received: by 10.58.164.35 with HTTP; Tue, 4 Dec 2012 08:05:08 -0800 (PST) In-Reply-To: <50BE06C9.6050605@alvestrand.no> References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> <50BCFCFE.3080104@nostrum.com> <000001cdd196$796cde90$6c469bb0$@us> <50BE06C9.6050605@alvestrand.no> Date: Tue, 4 Dec 2012 08:05:08 -0800 Message-ID: From: Ted Hardie To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Engineering approach to RTT communication (Re: Consensus call on Text Communication) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 16:05:10 -0000 Comments in-line. On Tue, Dec 4, 2012 at 6:20 AM, Harald Alvestrand wrote: > Changing the subject as usual... > > On 12/04/2012 08:45 AM, Bernard Aboba wrote: > > >> I still think Bernard's general approach is correct.. try and document >> what >> is out there now and can one or more be selected for MTI with the >> assumption >> that everything else is going to be sent through a gateway. The regulatory >> authorities .. if you read CVAA closely for instance, understand there may >> be multiple technical approaches to compliance. It's is the attempt to >> comply that is "safe harbor" in legal terms. > > [BA] Since we are engineers in the IETF, it seems to me that we should try > to approach this as an engineering problem. That is, first figure out in > some detail what it is we're trying to build, then after that, figure out if > there is anything missing from our toolkit that would prevent us from > building it. WebRTC combining as it does realtime communications with other > facilities of the Web (including accessibility functionality) would appear > to have promise as a platform for the creation and deployment of accessible > communications applications and services. > > > ... and phrased like this, the question then becomes: > > Is this within charter for RTCWEB, or does it require a new effort? > I think the answer to this depends on whether the aim is for RTCWeb/WebRTC to provide the rendezvous service for a real-time communication based entirely in the web or not. As I read the charter that work would involve us being reasonably certain that the underlying architecture works when the media being carried is real-time text, rather than audio or video, and that the negotiation works for picking a media type. After that a reference to RFC 4103 for currently standard payload format seems to round out the work that falls squarely into the charter. The second potential piece of work I'm much less sanguine about, as that would be interworking with gateways. The Real Time Text Task force (www.realtimetext.org) seems to indicate that there is already work going on in defining gateway/transcoding and it might be better done there as part of that effort (for those who don't know Arnoud van Wijk, he started this work as part of ISOC's efforts Enabling Access initiative before r3tf came into being.) Doing it independently seems likely to create a gateway mechanism that aims at a past standard rather than upcoming states of play. Would the working group like the chairs to start a liaison effort with the R3TF? regards, Ted Hardie > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From charles-pierre@videodesk.com Tue Dec 4 08:08:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE8021F8BCB for ; Tue, 4 Dec 2012 08:08:20 -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 XiD+7eYfm1OR for ; Tue, 4 Dec 2012 08:08:20 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 31E6821F8A73 for ; Tue, 4 Dec 2012 08:08:20 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so2403885qca.31 for ; Tue, 04 Dec 2012 08:08:19 -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 :x-gm-message-state; bh=b+8b0oqYuyTOinclACZ8vw/x2ZIhJOopCc9vR3q40FE=; b=aPDD6OjfR3ThVfvTuuIPdhU95DZndaFkZpCtiajXSqsKTxMmDfAnA6zrB5DG3XubQq SW/NkmqPQNPWdwwOe6rmFoz2rzwchyHcyiSLkS9LvGMiRqm6gzW/kOU1uYIfJWEb4IbN Nu0etXx0NBXx7gVKDAMyWchLslz/VvzhxCtZ5R0P2KtR6F7ZyJGH0wDgmiwqZcPX/Fst tATk7OzHCexm4dUAmXGYAug8A3S0lD4ASWgttxXOV6OMHjDg9adD1g3rPblgIgEMx5Kj dCMMFJZUMI3oDmbbn1JH1vVVxDT+0I5SmT6EIo9dEkKXDoontqJGFqZyZ/9/gTGI//TA Ncrg== Received: by 10.229.244.81 with SMTP id lp17mr5412228qcb.64.1354637299560; Tue, 04 Dec 2012 08:08:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.119.3 with HTTP; Tue, 4 Dec 2012 08:07:59 -0800 (PST) From: Charles-Pierre Astolfi Date: Tue, 4 Dec 2012 17:07:59 +0100 Message-ID: To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=001636c5b3e90a319d04d0091316 X-Gm-Message-State: ALoCoQlLBTIfAvkicYVwnxrGHB+9CeVucan97ZZfX08P3iVZRPnmUxF/FZmqjc+Q+UgRHxKCr8xn Subject: [rtcweb] Experiments with Chrome and Firefox X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 16:08:21 -0000 --001636c5b3e90a319d04d0091316 Content-Type: text/plain; charset=ISO-8859-1 Hi, Is there a simple webapp that shows webrtc communication between firefox and chrome? Something like https://apprtc.appspot.com/ (the demo from webrtc.org) but that works across the 2 browsers. I am not even sure it is possible, I couldn't find much doc/information about it. Many thanks, -- Charles-Pierre Astolfi --001636c5b3e90a319d04d0091316 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Is there a simple webapp that shows webrt= c communication between firefox and chrome?

Someth= ing like=A0https://apprtc.appspot.c= om/ (the demo from webrtc.org) but th= at works across the 2 browsers.
I am not even sure it is possible, I couldn't find much doc/inform= ation about it.

Many thanks,
--=A0
Charle= s-Pierre Astolfi

--001636c5b3e90a319d04d0091316-- From randell-ietf@jesup.org Tue Dec 4 08:53:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD96221F87EF for ; Tue, 4 Dec 2012 08:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 U-isPdxynf3r for ; Tue, 4 Dec 2012 08:53:39 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id F108A21F8BDF for ; Tue, 4 Dec 2012 08:53:38 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:2226 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TfvkU-000AsY-8g for rtcweb@ietf.org; Tue, 04 Dec 2012 10:53:34 -0600 Message-ID: <50BE2A5E.6040904@jesup.org> Date: Tue, 04 Dec 2012 11:52:46 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com>, <50BB22EB.1030803@ericsson.com> , <50BCFCFE.3080104@nostrum.com>, <000001cdd196$796cde90$6c469bb0$@us> <50BE06C9.6050605@alvestrand.no> In-Reply-To: <50BE06C9.6050605@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Engineering approach to RTT communication (Re: Consensus call on Text Communication) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 16:53:39 -0000 On 12/4/2012 9:20 AM, Harald Alvestrand wrote: > Changing the subject as usual... > > On 12/04/2012 08:45 AM, Bernard Aboba wrote: >> >> > I still think Bernard's general approach is correct.. try and >> document what >> > is out there now and can one or more be selected for MTI with the >> assumption >> > that everything else is going to be sent through a gateway. The >> regulatory >> > authorities .. if you read CVAA closely for instance, understand >> there may >> > be multiple technical approaches to compliance. It's is the attempt to >> > comply that is "safe harbor" in legal terms. >> >> [BA] Since we are engineers in the IETF, it seems to me that we >> should try to approach this as an engineering problem. That is, first >> figure out in some detail what it is we're trying to build, then >> after that, figure out if there is anything missing from our toolkit >> that would prevent us from building it. WebRTC combining as it does >> realtime communications with other facilities of the Web (including >> accessibility functionality) would appear to have promise as a >> platform for the creation and deployment of accessible communications >> applications and services. > > ... and phrased like this, the question then becomes: > > Is this within charter for RTCWEB, or does it require a new effort? As that's a charter question, I'll leave it to those with time to re-read the charter :-) I think we absolutely should define how accessibility can be handled within rtcweb, and if we can include a reference implementation and/or build in the hooks (or more), I'm all for that. And I agree; if we select something it will go a fair ways towards pushing implementations (not just in rtcweb) and regulations towards that standard (or towards requirements that can be fulfilled by that standard). I would suggest it's at least a separate standards document; whether that's within rtcweb or not is, as mentioned, a process issue I really don't care about. To actually surface this to users does involve the applications/websites, since they define most of the UI seen by the user. We can support that with protocols (either reference impls or baked in) and perhaps with DOM/W3 changes to provide useful tools, but we can't bake the entire UI into the browser without totally stifling innovative uses. This is a tough area for regulators, as the actual applications (and the UI) are provided by the website authors. The classic telecom regulatory framework starts to fray when it hits the web. (To which regulators must a website answer to? What if they're contradictory? What if they only target users from one country? What if they aren't a paid service?) Before we make core changes to the rtcweb spec we need to consider these issues. Another reason I think a separate standards-track document is in order. -- Randell Jesup randell-ietf@jesup.org From matthew@matthew.at Tue Dec 4 09:26:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC9121F872C for ; Tue, 4 Dec 2012 09:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1bGhNXejA0w for ; Tue, 4 Dec 2012 09:26:31 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF40021F846B for ; Tue, 4 Dec 2012 09:26:31 -0800 (PST) Received: from [10.80.69.205] (unknown [131.107.192.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 4C4E9148086 for ; Tue, 4 Dec 2012 09:26:31 -0800 (PST) Message-ID: <50BE322F.6070206@matthew.at> Date: Tue, 04 Dec 2012 09:26:07 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com>, <50BB22EB.1030803@ericsson.com> , <50BCFCFE.3080104@nostrum.com>, <000001cdd196$796cde90$6c469bb0$@us> <50BE06C9.6050605@alvestrand.no> <50BE2A5E.6040904@jesup.org> In-Reply-To: <50BE2A5E.6040904@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Engineering approach to RTT communication (Re: Consensus call on Text Communication) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 17:26:32 -0000 On 12/4/2012 8:52 AM, Randell Jesup wrote: > > Before we make core changes to the rtcweb spec we need to consider > these issues. Another reason I think a separate standards-track > document is in order. > There's a bunch of real engineering issues to consider as well. If we allow sending of T.140/RFC4103 text on a PeerConnection from JavaScript then: (just to bring up some examples off the top of my head) - Is the JavaScript rate-limited such that it cannot use this channel as a congestion-unconstrained browser-to-browser data channel? - Will there be a consent dialog raised before the JavaScript can send on this channel? - Do there need to be safeguards to prevent a malicious website or malicious injected content from modifying the text that is typed by the user? (In other words, is the text channel also able to be marked the same way a camera and microphone can be marked to prevent modification of the content, and if so, how could that even work?) - Do there need to be safeguards to prevent a malicious website or malicious injected content from calling a PSAP on your behalf and engaging in "SWATing" over this channel? Matthew Kaufman From markybox@gmail.com Tue Dec 4 09:43:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7108A21F8C57 for ; Tue, 4 Dec 2012 09:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 jXG33-hiIn88 for ; Tue, 4 Dec 2012 09:43:48 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6264E21F8C34 for ; Tue, 4 Dec 2012 09:43:48 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so1853872bku.31 for ; Tue, 04 Dec 2012 09:43:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=G9zE2nvx0VCyc2SOxWx30dNFgiRlweWsEDK1Q6rvf1s=; b=C+FR41RPP6+9H6WTnTgFlSzG9rvOeOioTtPksIz22jaJJiz0/X4ykf4f1Upo7hCxnn +WqfwydtdO4V1nWRSQnQLz6S2LUgtjSMXgs5G9OTgpvak9ydyCvUwB3ZKMJKzaikuNSc xHi6HltxY37tm89jOiSSJNzbRz/YblWS3q27EBlBroQfEeH2gEZWQiE2d3LxCoa8mmx9 wemtXJgISEoOqn/47iF+XduwK3QQRSm0L4MBrZMc7yzWRVZe74U3t3KLv4ivaEdctKS7 S6TLN/RtYORPhW57kxP8PBBlQRpRDZ5GkCoymyYtMfaVtsma9ZuI0M+cTWf9cdlRdKXn uf4g== Received: by 10.204.4.145 with SMTP id 17mr4426931bkr.34.1354643027331; Tue, 04 Dec 2012 09:43:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.205.80.15 with HTTP; Tue, 4 Dec 2012 09:43:26 -0800 (PST) In-Reply-To: References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> <50BCFCFE.3080104@nostrum.com> <000001cdd196$796cde90$6c469bb0$@us> <50BE06C9.6050605@alvestrand.no> <50BE2A5E.6040904@jesup.org> <50BE322F.6070206@matthew.at> From: Mark Rejhon Date: Tue, 4 Dec 2012 12:43:26 -0500 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [rtcweb] Engineering approach to RTT communication (Re: Consensus call on Text Communication) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 17:43:49 -0000 On Tue, Dec 4, 2012 at 12:26 PM, Matthew Kaufman wrote: > - Is the JavaScript rate-limited such that it cannot use this channel as a > congestion-unconstrained browser-to-browser data channel? Not from the perspective of XEP-0301. XEP-0301 allows rate-smoothing methods that turns random intermittent arrival of packets (300ms, 100ms, 1000ms, 500ms) into smoothed text output. It's usable even up to 2-3 second jitter (poor wireless reception, satellite connections, etc). That said, the more steady and reliable, the better. It's a graceful degradation of service, but far less abrupt than it is for audio/video (which suffers more greatly). Therefore, I pretty much assume the data channel will be perfectly fine for XEP-0301 during situations where audio is fully intelligible and video isn't too glitchy. > - Will there be a consent dialog raised before the JavaScript can send of this channel? I sure hope it's no more cumbersome than it will be for audio/video, and that it can be a single-step authorization process for the entire webrtc environment, otherwise it would not be well-adopted. Standardization of indicators of function might be recommended (like the lock icon for SSL), to indicate that live communication is in progress -- like a red flashing dot ("we're LIVE!") There are some privacy guidelines in Security Considerations of XEP-0301: http://xmpp.org/extensions/xep-0301.html#security_considerations From gunnar.hellstrom@omnitor.se Tue Dec 4 10:17:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C62021F8C17 for ; Tue, 4 Dec 2012 10:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D13Sf1r9AKoz for ; Tue, 4 Dec 2012 10:17:50 -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 0CA2621F8BAC for ; Tue, 4 Dec 2012 10:17:48 -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 ; Tue, 4 Dec 2012 19:17:39 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-09-01.atm.binero.net (Postfix) with ESMTPA id 2725C3A123 for ; Tue, 4 Dec 2012 19:17:39 +0100 (CET) Message-ID: <50BE3E44.5000000@omnitor.se> Date: Tue, 04 Dec 2012 19:17:40 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com>, <50BB22EB.1030803@ericsson.com> , <50BCFCFE.3080104@nostrum.com>, <000001cdd196$796cde90$6c469bb0$@us> <50BE06C9.6050605@alvestrand.no> <50BE2A5E.6040904@jesup.org> <50BE322F.6070206@matthew.at> In-Reply-To: <50BE322F.6070206@matthew.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Engineering approach to RTT communication (Re: Consensus call on Text Communication) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 18:17:51 -0000 Answers inline On 2012-12-04 18:26, Matthew Kaufman wrote: > On 12/4/2012 8:52 AM, Randell Jesup wrote: >> >> Before we make core changes to the rtcweb spec we need to consider >> these issues. Another reason I think a separate standards-track >> document is in order. >> > > There's a bunch of real engineering issues to consider as well. If we > allow sending of T.140/RFC4103 text on a PeerConnection from > JavaScript then: > > (just to bring up some examples off the top of my head) > > - Is the JavaScript rate-limited such that it cannot use this channel > as a congestion-unconstrained browser-to-browser data channel? Could be if needed. In RFC 4103 there is a default transmission limit of 30 characters per second, that can be negotiated by an sdp parameter. 30 characters per second is regarded sufficient for human input, even from speech-to-text applications but for safety sake, I think a limit of 50 characters per second would be safer - usability wise. > - Will there be a consent dialog raised before the JavaScript can send > on this channel? The normal thing in a total conversation call is to activate all three media as soon as possible after call completion. A video channel can do much more harm than the RTT channel. > > - Do there need to be safeguards to prevent a malicious website or > malicious injected content from modifying the text that is typed by > the user? (In other words, is the text channel also able to be marked > the same way a camera and microphone can be marked to prevent > modification of the content, and if so, how could that even work?) If you can do it with audio and video, you should be able to do it with real-time text. But that may have limitations for example when interworking with a legacy SIP device. > - Do there need to be safeguards to prevent a malicious website or > malicious injected content from calling a PSAP on your behalf and > engaging in "SWATing" over this channel? Sounds to be questions to be solved in coordination with video and audio. Are these issues solved for the other media? //Gunnar From matthew@matthew.at Tue Dec 4 10:53:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710E321F8CC8 for ; Tue, 4 Dec 2012 10:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQo7JRKO8nXh for ; Tue, 4 Dec 2012 10:53:44 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E8121F8CC4 for ; Tue, 4 Dec 2012 10:53:43 -0800 (PST) Received: from [10.81.144.21] (unknown [131.107.192.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id C4005148093 for ; Tue, 4 Dec 2012 10:53:43 -0800 (PST) Message-ID: <50BE46A0.8050608@matthew.at> Date: Tue, 04 Dec 2012 10:53:20 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com>, <50BB22EB.1030803@ericsson.com> , <50BCFCFE.3080104@nostrum.com>, <000001cdd196$796cde90$6c469bb0$@us> <50BE06C9.6050605@alvestrand.no> <50BE2A5E.6040904@jesup.org> <50BE322F.6070206@matthew.at> <50BE3E44.5000000@omnitor.se> In-Reply-To: <50BE3E44.5000000@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Engineering approach to RTT communication (Re: Consensus call on Text Communication) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 18:53:45 -0000 On 12/4/2012 10:17 AM, Gunnar Hellström wrote: > Answers inline > > On 2012-12-04 18:26, Matthew Kaufman wrote: >> On 12/4/2012 8:52 AM, Randell Jesup wrote: >>> >>> Before we make core changes to the rtcweb spec we need to consider >>> these issues. Another reason I think a separate standards-track >>> document is in order. >>> >> >> There's a bunch of real engineering issues to consider as well. If we >> allow sending of T.140/RFC4103 text on a PeerConnection from >> JavaScript then: >> >> (just to bring up some examples off the top of my head) >> >> - Is the JavaScript rate-limited such that it cannot use this channel >> as a congestion-unconstrained browser-to-browser data channel? > Could be if needed. In RFC 4103 there is a default transmission limit > of 30 characters per second, that can be negotiated by an sdp > parameter. 30 characters per second is regarded sufficient for human > input, even from speech-to-text applications but for safety sake, I > think a limit of 50 characters per second would be safer - usability > wise. Since the application author (and the JavaScript) can make arbitrary changes to the SDP, the browser will need to enforce an upper bound on this data rate. >> - Will there be a consent dialog raised before the JavaScript can >> send on this channel? > The normal thing in a total conversation call is to activate all three > media as soon as possible after call completion. A video channel can > do much more harm than the RTT channel. Did you come in late to the RTCWEB work? For privacy there's a requirement for camera and microphone access to raise a consent dialog in the browser before the camera or microphone is activated. On the other hand, there is no requirement to raise a consent dialog before opening a data channel. What's the answer for this case? >> >> - Do there need to be safeguards to prevent a malicious website or >> malicious injected content from modifying the text that is typed by >> the user? (In other words, is the text channel also able to be marked >> the same way a camera and microphone can be marked to prevent >> modification of the content, and if so, how could that even work?) > If you can do it with audio and video, you should be able to do it > with real-time text. But that may have limitations for example when > interworking with a legacy SIP device. I don't think it has anything to do with interworking with a legacy SIP device. You can ensure that the audio from the microphone and the video from the camera have not been manipulated by JavaScript prior to encoding and sending over the RTP channel, and make corresponding identity assertions as well. But I don't see how you plan to ensure that keys pressed on the keyboard have not been manipulated by JavaScript prior to encoding and sending over the RTP channel... unless the plan is to have the keyboard be a MediaCapture device, have a consent dialog, and bypass the JavaScript entirely. >> - Do there need to be safeguards to prevent a malicious website or >> malicious injected content from calling a PSAP on your behalf and >> engaging in "SWATing" over this channel? > Sounds to be questions to be solved in coordination with video and > audio. Are these issues solved for the other media? Yes, to the extent that it is possible to ensure that the Audio and Video being sent over the channel are actually sourced from the local camera and microphone and have not been manipulated it is solved for the other media. Additionally, the barrier to entry to inserting bogus reports of crime is exponentially higher for audio as compared to text, and again for video as compared to audio, so I think that the risk for RTT is greatest. Again, is the plan to make the keyboard a MediaCapture device or is the plan to allow arbitrary JavaScript the ability to generate the characters that are being sent over the RTT channel? Matthew Kaufman From gunnar.hellstrom@omnitor.se Tue Dec 4 11:55:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71FB21F8C53 for ; Tue, 4 Dec 2012 11:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouU12LVgT6Ar for ; Tue, 4 Dec 2012 11:55:00 -0800 (PST) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 6E91121F8C81 for ; Tue, 4 Dec 2012 11:54:58 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Tue, 4 Dec 2012 20:54:50 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id 9DC4F3A1CA for ; Tue, 4 Dec 2012 20:54:50 +0100 (CET) Message-ID: <50BE550B.9020801@omnitor.se> Date: Tue, 04 Dec 2012 20:54:51 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com>, <50BB22EB.1030803@ericsson.com> , <50BCFCFE.3080104@nostrum.com>, <000001cdd196$796cde90$6c469bb0$@us> <50BE06C9.6050605@alvestrand.no> <50BE2A5E.6040904@jesup.org> <50BE322F.6070206@matthew.at> <50BE3E44.5000000@omnitor.se> <50BE46A0.8050608@matthew.at> In-Reply-To: <50BE46A0.8050608@matthew.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Engineering approach to RTT communication (Re: Consensus call on Text Communication) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 19:55:00 -0000 On 2012-12-04 19:53, Matthew Kaufman wrote: > On 12/4/2012 10:17 AM, Gunnar Hellström wrote: >> Answers inline >> >> On 2012-12-04 18:26, Matthew Kaufman wrote: >>> On 12/4/2012 8:52 AM, Randell Jesup wrote: >>>> >>>> Before we make core changes to the rtcweb spec we need to consider >>>> these issues. Another reason I think a separate standards-track >>>> document is in order. >>>> >>> >>> There's a bunch of real engineering issues to consider as well. If >>> we allow sending of T.140/RFC4103 text on a PeerConnection from >>> JavaScript then: >>> >>> (just to bring up some examples off the top of my head) >>> >>> - Is the JavaScript rate-limited such that it cannot use this >>> channel as a congestion-unconstrained browser-to-browser data channel? >> Could be if needed. In RFC 4103 there is a default transmission limit >> of 30 characters per second, that can be negotiated by an sdp >> parameter. 30 characters per second is regarded sufficient for human >> input, even from speech-to-text applications but for safety sake, I >> think a limit of 50 characters per second would be safer - usability >> wise. > > Since the application author (and the JavaScript) can make arbitrary > changes to the SDP, the browser will need to enforce an upper bound on > this data rate. For T.140 , 50 characters per second is a safe highest limit. For XEP-0301 it might be harder to predict, because it has retransmission for synchronization, and for editing a bit back that can cause huge bursts of data. However, data channels for other purposes might need a lot more. Do all data channels need to be standardised and their names and restrictions be coded into the browser itself? If not, the malicious application sets up another data channel to do its malicious activity without restrictions. > >>> - Will there be a consent dialog raised before the JavaScript can >>> send on this channel? >> The normal thing in a total conversation call is to activate all >> three media as soon as possible after call completion. A video >> channel can do much more harm than the RTT channel. > > Did you come in late to the RTCWEB work? For privacy there's a > requirement for camera and microphone access to raise a consent dialog > in the browser before the camera or microphone is activated. On the > other hand, there is no requirement to raise a consent dialog before > opening a data channel. What's the answer for this case? Yes, I came in late. When I saw that rtcweb was shaping up and gaining momentum, I thought it was time to check if real-time text and other features of accessibility interest was catered for. If an incoming session can just grab keyboard input and send it, then yes you would need a consent dialogue. It would be good if the most common case of session setup still has the concept of calling and answering often used in other personal communication tools, and that the concent can be implicit in these operations. But of course other use cases are possible where explicit consent might be needed so that what you intended for local typing in another app not just suddenly is sent over an incoming session. > > >>> >>> - Do there need to be safeguards to prevent a malicious website or >>> malicious injected content from modifying the text that is typed by >>> the user? (In other words, is the text channel also able to be >>> marked the same way a camera and microphone can be marked to prevent >>> modification of the content, and if so, how could that even work?) >> If you can do it with audio and video, you should be able to do it >> with real-time text. But that may have limitations for example when >> interworking with a legacy SIP device. > > I don't think it has anything to do with interworking with a legacy > SIP device. You can ensure that the audio from the microphone and the > video from the camera have not been manipulated by JavaScript prior to > encoding and sending over the RTP channel, and make corresponding > identity assertions as well. But I don't see how you plan to ensure > that keys pressed on the keyboard have not been manipulated by > JavaScript prior to encoding and sending over the RTP channel... > unless the plan is to have the keyboard be a MediaCapture device, have > a consent dialog, and bypass the JavaScript entirely. Yes, I thought about end-to-end protection from manipulation in the middle. That may be feasible by applying SRTP or the corresponding security in the data channel when data goes end-to-end. But if there is a gateway that needs to break the secured connection and do transcoding, it also can inject malicious contents. But you talked about the local path through Javascript between keyboard and browser, and the risk that the app contains malicious code. Yes, there will be a tricky balance. There will be valid reasons to use other than keypress as text input. e.g. voice-to-text, or assistive technology producing text in other ways. Having keyboard input directly to the browser might cause unwanted restrictions. I think you can create a suitable security level better than I can and draw the conclusions on what is the most feasible implementation strategy. > >>> - Do there need to be safeguards to prevent a malicious website or >>> malicious injected content from calling a PSAP on your behalf and >>> engaging in "SWATing" over this channel? >> Sounds to be questions to be solved in coordination with video and >> audio. Are these issues solved for the other media? > > Yes, to the extent that it is possible to ensure that the Audio and > Video being sent over the channel are actually sourced from the local > camera and microphone and have not been manipulated it is solved for > the other media. Have you sacrificed the function for sending prerecorded video and speech from a file? > > Additionally, the barrier to entry to inserting bogus reports of crime > is exponentially higher for audio as compared to text, and again for > video as compared to audio, so I think that the risk for RTT is greatest. > > Again, is the plan to make the keyboard a MediaCapture device or is > the plan to allow arbitrary JavaScript the ability to generate the > characters that are being sent over the RTT channel? Most of the discussions lean towards Javascript control over text transmission. Your concerns might pull it a bit towards the other side - Browser controlled. As usual, the security issues need to be included in the specifications, and you can help to bring up the issues and conclusions. /Gunnar > Matthew Kaufman > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From worley@shell01.TheWorld.com Tue Dec 4 12:10:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1804921F8CC2 for ; Tue, 4 Dec 2012 12:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeP3riClb0mi for ; Tue, 4 Dec 2012 12:10:07 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD3D21F8CBB for ; Tue, 4 Dec 2012 12:10:06 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qB4K89Pe002439 for ; Tue, 4 Dec 2012 15:08:12 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id qB4K899V2361600 for ; Tue, 4 Dec 2012 15:08:09 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qB4K89YA2370719; Tue, 4 Dec 2012 15:08:09 -0500 (EST) Date: Tue, 4 Dec 2012 15:08:09 -0500 (EST) Message-Id: <201212042008.qB4K89YA2370719@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: rtcweb@ietf.org In-reply-to: <50BD92ED.1000703@jesup.org> (randell-ietf@jesup.org) References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> <023d01cdd183$76e5e030$64b1a090$@us> <50BD23C0.3010509@omnitor.se> <50BD92ED.1000703@jesup.org> Subject: Re: [rtcweb] Real-time text implementations X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 20:10:08 -0000 > From: Randell Jesup > > That list says to me that real-world implementation of RFC 4103 is > spotty at best. [...] > And Asterisk seems big, until > you realize it's a PBX and "support" there mean it passes it through, I > assume. Your statement is completely correct but it also obscures an important point: Asterisk passes through RTP packets (or has them bypass the switching host entirely), and so it supports *all* media carried by RTP. In one sense, that means its support for text/t140 RTP was trivial to implement. In another sense, it means that supporting text/t140 RTP in a PBX is simple because it *is* RTP. (Similarly, the series of PBX products derived from the sipX open-source project (sipXecs, EADS/PlantCML Patriot/Sentinel, SIPez, Avaya SCS/AvayaLive Connect) all support text/t140 in the same trivial manner.) Dale From gunnar.hellstrom@omnitor.se Tue Dec 4 12:39:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821A421F870E for ; Tue, 4 Dec 2012 12:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVD4lAhR+uow for ; Tue, 4 Dec 2012 12:39:05 -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 8DF0821F8651 for ; Tue, 4 Dec 2012 12:39:04 -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 ; Tue, 4 Dec 2012 21:38:56 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-06-01.atm.binero.net (Postfix) with ESMTPA id 8A8153A188 for ; Tue, 4 Dec 2012 21:38:56 +0100 (CET) Message-ID: <50BE5F61.2050005@omnitor.se> Date: Tue, 04 Dec 2012 21:38:57 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> <023d01cdd183$76e5e030$64b1a090$@us> <50BD23C0.3010509@omnitor.se> <50BD92ED.1000703@jesup.org> <201212042008.qB4K89YA2370719@shell01.TheWorld.com> In-Reply-To: <201212042008.qB4K89YA2370719@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Real-time text implementations X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 20:39:05 -0000 On 2012-12-04 21:08, Dale R. Worley wrote: >> From: Randell Jesup >> >> That list says to me that real-world implementation of RFC 4103 is >> spotty at best. [...] >> And Asterisk seems big, until >> you realize it's a PBX and "support" there mean it passes it through, I >> assume. > Your statement is completely correct but it also obscures an important > point: Asterisk passes through RTP packets (or has them bypass the > switching host entirely), and so it supports *all* media carried by > RTP. In one sense, that means its support for text/t140 RTP was > trivial to implement. In another sense, it means that supporting > text/t140 RTP in a PBX is simple because it *is* RTP. > > (Similarly, the series of PBX products derived from the sipX > open-source project (sipXecs, EADS/PlantCML Patriot/Sentinel, SIPez, > Avaya SCS/AvayaLive Connect) all support text/t140 in the same trivial > manner.) Well. Many SIP products support T.140/RFC4103 in the trivial sense you mean. Just pass through. But Asterisk can do a bit more. It has text APIs that can generate and receive text from an RTP channel with RFC 4103 activated. It also can resolve packet loss and recover text from redundancy to correct the text stream. It is therefore a good environment for gateways for real-time text. Because of its reasonable multi-media characteristics it can also handle calls with combination of audio, video and real-time text. Gunnar From worley@shell01.TheWorld.com Tue Dec 4 12:42:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A379F21F8909 for ; Tue, 4 Dec 2012 12:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7U8JEKyANgW for ; Tue, 4 Dec 2012 12:42:03 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 16EF721F88FD for ; Tue, 4 Dec 2012 12:42:01 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qB4KetYa019018 for ; Tue, 4 Dec 2012 15:40:57 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id qB4Kesp82374700 for ; Tue, 4 Dec 2012 15:40:54 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qB4Kesnl2368891; Tue, 4 Dec 2012 15:40:54 -0500 (EST) Date: Tue, 4 Dec 2012 15:40:54 -0500 (EST) Message-Id: <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: rtcweb@ietf.org In-reply-to: <50B82D25.3030806@jesup.org> (randell-ietf@jesup.org) References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 20:42:03 -0000 > From: Randell Jesup > > Not so simply; MediaStreams in Firefox currently have a strong idea that > data has a time for display and a duration. This could be worked around, > and might need to for other reasons - but there was no design goal for > carrying non-media data in MediaStreams. I'm not understanding you here. RTT *is* media. It may be that you receive RTT media after its desired display time, but the same thing can happen with audio and video, and you need some sort of strategy for coping with that. (I assume that there is an explicit or implicit "expiration time", the time after which the data should be discarded rather than an attempt made at catching up. But one can construct an expiration time for RTT media as well as audio or video media.) > > - Because there is only one implementation per browser, there is less > > total implementation effort and the average implementation is more > > likely to work well. It will also have a consistent UI if the user > > uses the same browser with multiple web sites. > > I'll note that virtually nothing in webrtc, let alone rtcweb, really > touches on UI - UI is generally (and almost must be) handled by the JS > application. Assuming the UI is tied to the signaling and media > components/hardware is the classic SIP hardware UA way to look at it (or > SIP software application). > > We'd need to define a way to inject keystrokes into the stream, and get > them out (and perhaps process them into a displayable string). In theory > the W3C could define RTT display elements you could hook an RTT media > track to; or it could be subsumed into existing audio/video media > elements (though there's still the input side, and this might be unduly > restrictive of possible applications layouts and uses). My understanding, or really, assumption, is that the display of WebRTC video will be done with something that looks and acts somewhat like current browser video players. And that, from the Javascript point of view, it will run as an autonomous process. The Javascript will make API calls to tell the video player that RTP packets arriving on a certain port, with certain codec numbers, are to be decoded with a certain codec, and then displayed via the video player. That way, once the video stream is set up, the Javascript doesn't touch the media data. This shields the process of video display from any real-time limitations of the Javascript engine. It also allows the browser engineers to isolate the real time problems of video display into a small, non-programmable part of the browser. Similarly, the Javascript establishes a connection between the video input device, and a particular RTP port, destination address/port, codec number, codec, etc., but does not need to perform any action to support ongoing video transmission. And I expect that audio reception and transmission will handled in a similar way, with adjustments for how the Javascript specifies the UI input and output devices. *Within this conceptualization*, the most *uniform* implementation of RTT is for it to be handled as "another media type", and that the Javascript will set up the connection between the RTP and some sort of RTT input and RTT output widgets, but once the Javascript calls the APIs to establish the connection, the Javascript does not need to handle the media data. However, RTT can be considered to be different from other media: - The data rate of RTT media is several orders of magnitude lower than other media, and so it is plausible to have Javascript process the RTT media. But this leaves RTT processing at the mercy of Javascript execution, and my experiencde suggests that Javascript execution is unreliable on the sub-second timescale. - The Javascript programmer can plausibly desire to program his own RTT input/output widget (whereas we do not expect him to do so with audio and video). But this is likely to lead to a proliferation of mediocre RTT input/output widgets with inconsistent UIs. (By comparison, free-form long-text input fields are implemented directly by browsers and do not need Javascript support.) And *requiring* the Javascript programmer to program his own RTT input/output widget will lead to very scattered implementation. - If we carry the RTT media in some manner other than RTP, different machinery will be needed to hook the RTT input/output widget to the transport than is used for audio and video media. But if we want to handle RTT as a first-class media type, it seems to me we aren't increasing the total amount of work by handling it like we do audio and video. The most significant change is that we're specifying the real-time part of RTT to be handled directly by the browser, rather than having every WebRTC coder implement it individually. Dale From martin.thomson@gmail.com Tue Dec 4 14:06:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54FD21F8AA3 for ; Tue, 4 Dec 2012 14:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.765 X-Spam-Level: X-Spam-Status: No, score=-4.765 tagged_above=-999 required=5 tests=[AWL=-1.166, 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 Fh7sJH1mEeaU for ; Tue, 4 Dec 2012 14:06:57 -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 9133421F8A9C for ; Tue, 4 Dec 2012 14:06:48 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3921482lbk.31 for ; Tue, 04 Dec 2012 14:06:47 -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=tPI6+jys0G5VBMS8iPrhoWo0vA8L9Qc35T25j0Yw1Zk=; b=CTsMfONIB5pobL8rd40eiteS61kvg3xFLA+mD1tmSONLzXNTvLvKENrVrZ3N9Se1NY tYQVmxmBnwGGBGWNwFJL/0luRynoeNCI79ERMNJJc19rD2V1UzlAUcp2LiJfRATybPez pkk3vvRnULWrhuVaLtQjjwuVbqAr22ijVcoJ/iPFpsZw7t2YhIPjKnVkwtgqvzkol93K gyNZ2ICQ3Q05ilAHeRAKtZfspD/XQl1O6xKtzvLtj80eOfhHi4vU+3XvhGhopa5WrPWA P0BJzEIJDibWHCtIn44vmW4lB2vDy6rTU1fPmofkjm+q5sFbFju7n26YDzQpjqq3oEpg xX8A== MIME-Version: 1.0 Received: by 10.152.148.40 with SMTP id tp8mr14508700lab.30.1354658807485; Tue, 04 Dec 2012 14:06:47 -0800 (PST) Received: by 10.112.83.2 with HTTP; Tue, 4 Dec 2012 14:06:47 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Dec 2012 14:06:47 -0800 Message-ID: From: Martin Thomson To: Charles-Pierre Astolfi Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Experiments with Chrome and Firefox X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 22:06:59 -0000 On 4 December 2012 08:07, Charles-Pierre Astolfi wrote: > Is there a simple webapp that shows webrtc communication between firefox and > chrome? Unless something has changed dramatically in the last few weeks, this is not currently possible. From gunnar.hellstrom@omnitor.se Tue Dec 4 14:20:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8058D21F8BBD for ; Tue, 4 Dec 2012 14:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2sSOocf6EZn for ; Tue, 4 Dec 2012 14:20:51 -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 2827E21F8BBF for ; Tue, 4 Dec 2012 14:20:46 -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 ; Tue, 4 Dec 2012 23:20:39 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-03-01.atm.binero.net (Postfix) with ESMTPA id A20663A110 for ; Tue, 4 Dec 2012 23:20:39 +0100 (CET) Message-ID: <50BE7738.8090403@omnitor.se> Date: Tue, 04 Dec 2012 23:20:40 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> In-Reply-To: <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 22:20:52 -0000 On 2012-12-04 21:40, Dale R. Worley wrote: > - If we carry the RTT media in some manner other than RTP, different > machinery will be needed to hook the RTT input/output widget to the > transport than is used for audio and video media. > > But if we want to handle RTT as a first-class media type, it seems to > me we aren't increasing the total amount of work by handling it like > we do audio and video. The most significant change is that we're > specifying the real-time part of RTT to be handled directly by the > browser, rather than having every WebRTC coder implement it > individually. I think there are a lot of good reasoning in you entry. A Real-time text UI can be quite tricky and quite processor-consuming. Imagine two rapid typers, typing along with over 10 characters per second, one local and one remote typing simultaneously with a UI showing their entries building up in the real-time text preview style, as traditional chat but with the last entries being real-time entries continuously building up by entered text. It might be heavy for JS to recalculate and display the text area in such conditions. It might be more fair to the programmers to have the browser provide widgets for such RTT UI, and the JS level just assign a window placement, size, size of characters etc, and then let the browser handle the presentation. Gunnar From matthew.kaufman@skype.net Tue Dec 4 14:25:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F120021F8AF8 for ; Tue, 4 Dec 2012 14:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, 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 RTle0agKEx-O for ; Tue, 4 Dec 2012 14:25:31 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 6898021F8933 for ; Tue, 4 Dec 2012 14:25:31 -0800 (PST) Received: from mail209-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Dec 2012 22:25:30 +0000 Received: from mail209-ch1 (localhost [127.0.0.1]) by mail209-ch1-R.bigfish.com (Postfix) with ESMTP id 5FF8D40161; Tue, 4 Dec 2012 22:25:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zzc89bh542I1432Izz1de0h1202h1d1ah1d2ahzz1033IL8275dhz2fh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1155h) Received-SPF: pass (mail209-ch1: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail209-ch1 (localhost.localdomain [127.0.0.1]) by mail209-ch1 (MessageSwitch) id 135465992966738_18686; Tue, 4 Dec 2012 22:25:29 +0000 (UTC) Received: from CH1EHSMHS034.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail209-ch1.bigfish.com (Postfix) with ESMTP id 0584E20102; Tue, 4 Dec 2012 22:25:29 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS034.bigfish.com (10.43.70.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Dec 2012 22:25:28 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.149]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Tue, 4 Dec 2012 22:25:27 +0000 From: Matthew Kaufman To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Text communication in RTCWEB sessions Thread-Index: AQHN0l/UecySEjUbZkSMOtCSkSZ7s5gJNm8AgAABDhA= Date: Tue, 4 Dec 2012 22:25:26 +0000 Message-ID: References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> <50BE7738.8090403@omnitor.se> In-Reply-To: <50BE7738.8090403@omnitor.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: skype.net Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 22:25:32 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Gunnar Hellstr=F6m > I think there are a lot of good reasoning in you entry. > A Real-time text UI can be quite tricky and quite processor-consuming. > Imagine two rapid typers, typing along with over 10 characters per second= , > one local and one remote typing simultaneously with a UI showing their > entries building up in the real-time text preview style, as traditional c= hat but > with the last entries being real-time entries continuously building up by > entered text. It might be heavy for JS to recalculate and display the tex= t area > in such conditions. >=20 > It might be more fair to the programmers to have the browser provide > widgets for such RTT UI, and the JS level just assign a window placement, > size, size of characters etc, and then let the browser handle the > presentation. If you want browser vendors to add native "RTT" input and output widgets an= d map this to GetUserMedia, you really need to take this to the W3C mailing= list. It is public. Matthew Kaufman From martin.thomson@gmail.com Tue Dec 4 14:41:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F3321F8941 for ; Tue, 4 Dec 2012 14:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.324 X-Spam-Level: X-Spam-Status: No, score=-4.324 tagged_above=-999 required=5 tests=[AWL=-1.025, BAYES_00=-2.599, 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 JDCB21GOWpSe for ; Tue, 4 Dec 2012 14:41:12 -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 3B7AD21F88FD for ; Tue, 4 Dec 2012 14:41:12 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3943079lbk.31 for ; Tue, 04 Dec 2012 14:41:11 -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:content-transfer-encoding; bh=M+pzFdHhKsk2xRM9/XlEOuDZKSvMrRcoPgOzhmDBL8E=; b=TJChc/mgWMGM/uzFDmCo9tiOPuUoPlR8r1XXV2ycnZZlIJgue6eGO45xtGK92tQEe5 BXhtFpPYvxgxV+jGieStSwsTDUIym/LUgdCrXt0oESMcwWM0BrXwGTsK3RhN5b2cabO8 DGqHPTZ/84GWuK9VUlQhKhLotifVgcdGDt5zuznxN7afXBGCOtfxrL8ZuihwCuRpHsMN t+eFLlDHBs7AHdtbRGi2kCDF2mkjDy+k/qG9hWsdXImnXwf2hotG1uWek3Oy1DI8Fawy JuH/guJq+6k4xNiU9v2diufLQLPiFuaaW+CQcLnYXCncOW1xq8/3ZkNe6NYYZ5zcfdt4 7gAg== MIME-Version: 1.0 Received: by 10.152.109.203 with SMTP id hu11mr14361603lab.12.1354660871184; Tue, 04 Dec 2012 14:41:11 -0800 (PST) Received: by 10.112.83.2 with HTTP; Tue, 4 Dec 2012 14:41:11 -0800 (PST) In-Reply-To: <50BE550B.9020801@omnitor.se> References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> <50BCFCFE.3080104@nostrum.com> <000001cdd196$796cde90$6c469bb0$@us> <50BE06C9.6050605@alvestrand.no> <50BE2A5E.6040904@jesup.org> <50BE322F.6070206@matthew.at> <50BE3E44.5000000@omnitor.se> <50BE46A0.8050608@matthew.at> <50BE550B.9020801@omnitor.se> Date: Tue, 4 Dec 2012 14:41:11 -0800 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Engineering approach to RTT communication (Re: Consensus call on Text Communication) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 22:41:13 -0000 On 4 December 2012 11:54, Gunnar Hellstr=C3=B6m wrote: > However, data channels for other purposes might need a lot more. Do all d= ata > channels need to be standardised and their names and restrictions be code= d > into the browser itself? If not, the malicious application sets up anothe= r > data channel to do its malicious activity without restrictions. The data channel is congestion controlled, though the details of that congestion control are TBD. Currently, if we assume SCTP congestion control, that would be approximately the same as a single TCP flow. That would lead to something no worse than a websocket. RTP uses less rigorously defined congestion control. So the issue that Matthew raises is a valid one. Typical usage scenarios are actually irrelevant in this context. WRT consent, I think that keyboard focus could solve the issue, but that could require specific widgets. But then if you consider RTT to follow a media pipeline to display as Dale suggests, that implies new display widgets as well. Note that the browser already has access to your keyboard input...as long as you have the window in (keyboard) focus. >From that perspective, I can see how Adam reaches his conclusion - it removes a lot of these sorts of questions. ~~~~ On the other hand, if you want to consider end-to-end (keyboard to display) authentication, integrity and confidentiality, then you might naturally wish to require the control provided by having specific widgets. That involves all the tainting stuff and wotnot. This is the point that I'd like to see debated a little more. --Martin From gunnar.hellstrom@omnitor.se Tue Dec 4 15:14:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA78921F8AF8 for ; Tue, 4 Dec 2012 15:14:33 -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=[AWL=0.016, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuPihFUgpPf1 for ; Tue, 4 Dec 2012 15:14:32 -0800 (PST) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 5B89721F8AF9 for ; Tue, 4 Dec 2012 15:14:32 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Wed, 5 Dec 2012 00:14:25 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id 425AF3A12B for ; Wed, 5 Dec 2012 00:14:25 +0100 (CET) Message-ID: <50BE83D2.5040404@omnitor.se> Date: Wed, 05 Dec 2012 00:14:26 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Real-time text specfication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 23:14:34 -0000 Just as an example of a specification that includes real-time text in a natural and neutral way as one medium among others for conversational purposes, I want to provide a link to 3GPP TS 26.114 IMS Multimedia Telephony codec considerations. http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-b51.zip This is not a request that we shall use the same codec or transport in our case. It is just to show that real-time text can be included on the technical level on equal terms with the other conversational media without a word about accessibility and regulation and user groups. The reasons to do it can be saved for other documents. Gunnar -- From matthew@matthew.at Tue Dec 4 15:22:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D3521F8A8B for ; Tue, 4 Dec 2012 15:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNslA1OIwYad for ; Tue, 4 Dec 2012 15:22:30 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E4F21F8A72 for ; Tue, 4 Dec 2012 15:22:26 -0800 (PST) Received: from [10.81.144.21] (unknown [131.107.192.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 2E2B2250021 for ; Tue, 4 Dec 2012 15:22:24 -0800 (PST) Message-ID: <50BE85AE.6020805@matthew.at> Date: Tue, 04 Dec 2012 15:22:22 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> <50BCFCFE.3080104@nostrum.com> <000001cdd196$796cde90$6c469bb0$@us> <50BE06C9.6050605@alvestrand.no> <50BE2A5E.6040904@jesup.org> <50BE322F.6070206@matthew.at> <50BE3E44.5000000@omnitor.se> <50BE46A0.8050608@matthew.at> <50BE550B.9020801@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Engineering approach to RTT communication (Re: Consensus call on Text Communication) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 23:22:32 -0000 On 12/4/2012 2:41 PM, Martin Thomson wrote: > On the other hand, if you want to consider end-to-end (keyboard to > display) authentication, integrity and confidentiality, then you might > naturally wish to require the control provided by having specific > widgets. That involves all the tainting stuff and wotnot. This is the > point that I'd like to see debated a little more. --Martin Sure. But not here. That whole conversation needs to move to the w3c public list. Matthew Kaufman From markybox@gmail.com Tue Dec 4 15:29:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540FD21F8AF8 for ; Tue, 4 Dec 2012 15:29: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 GqeVz4adaB7w for ; Tue, 4 Dec 2012 15:29:52 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 96AC521F8AD2 for ; Tue, 4 Dec 2012 15:29:52 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so2010052wey.31 for ; Tue, 04 Dec 2012 15:29:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=/rvtEqlYw32Do/7y+hd7fuTlaFK0u09Lpf/zmetjSBw=; b=PNM69Wyw45ZpXSyemXKC8hkPjEDbgkBc0kotQIH+ZQZe+y7f/TGLax4JuCAe3k9Kbq 4P9aNK6nBQxrf6is+/yLyEmThcbWmlHRaIxuoq6yLc57sZHb8rs9WlFiCeOgzM9AzMtG nEMj1i0DIYjIt5VfeWvTJu6nbDo6fSGbt9PdAmg1lo3+Y44ra6p9+EcKEMQyVEZ2qJER wIrbNI3m7iUQiNPbU818IzSbbg1LcpObTv62HbVnG+keSP+VpQmLjzXXc1tUEDN+//lF 5suxjHp8ZHNdgrlaPTi2aLkWhOf3l3CcT7loeoclcaA3S2Ppu60ACyAhkp12cw1RF8wY kOQg== Received: by 10.180.102.234 with SMTP id fr10mr34179wib.17.1354663791630; Tue, 04 Dec 2012 15:29:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.18.142 with HTTP; Tue, 4 Dec 2012 15:29:31 -0800 (PST) In-Reply-To: References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> <50BE7738.8090403@omnitor.se> From: Mark Rejhon Date: Tue, 4 Dec 2012 18:29:31 -0500 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 23:29:53 -0000 On Tue, Dec 4, 2012 at 5:25 PM, Matthew Kaufman wrote: >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Gunnar Hellstr=F6m >> I think there are a lot of good reasoning in you entry. >> A Real-time text UI can be quite tricky and quite processor-consuming. >> Imagine two rapid typers, typing along with over 10 characters per secon= d, >> one local and one remote typing simultaneously with a UI showing their >> entries building up in the real-time text preview style, as traditional = chat but >> with the last entries being real-time entries continuously building up b= y >> entered text. It might be heavy for JS to recalculate and display the te= xt area >> in such conditions. I should note that this isn't true anymore for modern optimized browsers, especially on GPU accelerated platforms. They are surprisingly efficient, thanks to nearly two decades of browser wars. I'm able to update text inside a fixed-size
using JavaScript well north of tens or hundreds of thousand times a second in desktop browser programming, the optimizations in browsers really show. My preference: I'd say let rtcweb provide simple text receive/delivery API's (bare simple minimum to meet legislative requirements), and let JavaScript provide presentation -- it's just one line of text, such as divTag.InnerHTML =3D "hello, world"; It's high-performance nowadays in modern, optimized browsers, especially when using fixed CSS bounding boxes (to prevent text reflow overheads). Just let the web developer worry about presentation of real-time text, IMHO. It simplifies things, it keeps webrtc to just the details and API level stu= ff. No need to complicate things and bring W3C stuff into play for RTT. Mark Rejhon Author of XEP-0301 - XMPP Real-Time Text From matthew@matthew.at Tue Dec 4 15:39:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CF221F8AB4 for ; Tue, 4 Dec 2012 15:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSm+Mal-p4bX for ; Tue, 4 Dec 2012 15:39:11 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC1421F8AA6 for ; Tue, 4 Dec 2012 15:39:10 -0800 (PST) Received: from [10.81.144.21] (unknown [131.107.192.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 2878D250021 for ; Tue, 4 Dec 2012 15:39:07 -0800 (PST) Message-ID: <50BE899A.4020604@matthew.at> Date: Tue, 04 Dec 2012 15:39:06 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> <50BE7738.8090403@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 23:39:12 -0000 On 12/4/2012 3:29 PM, Mark Rejhon wrote: > I should note that this isn't true anymore for modern optimized > browsers, especially on GPU accelerated platforms. They are > surprisingly efficient, thanks to nearly two decades of browser wars. Agree. > My preference: I'd say let rtcweb provide simple text receive/delivery > API's (bare simple minimum to meet legislative requirements), and let > JavaScript provide presentation Then we need answers to my other questions. How do we rate-limit that data channel, how do you prevent malicious script from tampering (or do you not care), etc? Matthew Kaufman From bernard_aboba@hotmail.com Tue Dec 4 15:39:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382CE21F8BC5 for ; Tue, 4 Dec 2012 15:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.028 X-Spam-Level: X-Spam-Status: No, score=-102.028 tagged_above=-999 required=5 tests=[AWL=0.270, 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 J24ELnDaTwUZ for ; Tue, 4 Dec 2012 15:39:44 -0800 (PST) Received: from blu0-omc4-s4.blu0.hotmail.com (blu0-omc4-s4.blu0.hotmail.com [65.55.111.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC4921F8AD3 for ; Tue, 4 Dec 2012 15:39:44 -0800 (PST) Received: from BLU002-W74 ([65.55.111.135]) by blu0-omc4-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Dec 2012 15:39:43 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_ca9db786-1fe2-44fe-9011-98682a64543b_" X-Originating-IP: [131.107.0.91] From: Bernard Aboba To: Martin Thomson , =?iso-8859-1?B?R3VubmFyIEhlbGxzdHL2bQ==?= Date: Tue, 4 Dec 2012 15:39:42 -0800 Importance: Normal In-Reply-To: References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com>, , , , <50BCFCFE.3080104@nostrum.com> <000001cdd196$796cde90$6c469bb0$@us>, , <50BE06C9.6050605@alvestrand.no> <50BE2A5E.6040904@jesup.org>,<50BE322F.6070206@matthew.at> <50BE3E44.5000000@omnitor.se>,<50BE46A0.8050608@matthew.at> <50BE550B.9020801@omnitor.se>, MIME-Version: 1.0 X-OriginalArrivalTime: 04 Dec 2012 23:39:43.0332 (UTC) FILETIME=[A2D3F240:01CDD278] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Engineering approach to RTT communication (Re: Consensus call on Text Communication) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Dec 2012 23:39:45 -0000 --_ca9db786-1fe2-44fe-9011-98682a64543b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Martin said:=20 > On the other hand=2C if you want to consider end-to-end (keyboard to > display) authentication=2C integrity and confidentiality=2C then you migh= t > naturally wish to require the control provided by having specific > widgets. That involves all the tainting stuff and wotnot. This is > the point that I'd like to see debated a little more. [BA] I think that the need for end-to-end RTT support might depend on the s= cenario. If we are talking about a scenario which includes video (which mi= ght include ASL signing) and audio (which might include speech from the int= erpreter) then the audio/video would always be protected by SRTP (potential= ly end-to-end if DTLS/SRTP is used). In such an environment=2C problems = with the integrity of realtime text delivered hop-by-hop might be detectabl= e by at least one participant in the conversation. On the other hand if re= altime text is all that is provided (e.g. the user is hearing and speech im= paired and voice/video is either not used or is not brought up) then integr= ity issues might not be detectable=2C because there is nothing to compare i= t against.=20 Also=2C there are probably some scenarios in which additional latency might= become annoying (such as a multi-user-chat where the delays might cause pe= ople to have to revise their replies-in-progress as characters stream in by= fits and starts). For example=2C in a scenario with some packet loss whe= re re-transmissions are occurring=2C TCP-based transport (e.g. XEP-0301 run= ning over BOSH) would exhibit head-of-line blocking and it might not be pos= sible to accurately mimic the inter-character timing of the sender. =20 = --_ca9db786-1fe2-44fe-9011-98682a64543b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Martin said:

>=3B= On the other hand=2C if you want to consider end-to-end (keyboard to
&g= t=3B display) authentication=2C integrity and confidentiality=2C then you m= ight
>=3B naturally wish to require the control provided by having spe= cific
>=3B widgets. That involves all the tainting stuff and wotnot. = This is
>=3B the point that I'd like to see debated a little more.
[BA] I think that the need for end-to-end RTT support might depend on = the scenario. =3B If we are talking about a scenario which includes vid= eo (which might include ASL signing) and audio (which might include speech = from the interpreter) then the audio/video would always be protected by SRT= P (potentially end-to-end if DTLS/SRTP is used). =3B =3B In such an= environment=2C =3B problems with the integrity of realtime text delive= red hop-by-hop might be detectable by at least one participant in the conve= rsation. =3B On the other hand if realtime text is all that is provided= (e.g. the user is hearing and speech impaired and voice/video is either no= t used or is not brought up) then integrity issues might not be detectable= =2C because there is nothing to compare it against.

Also=2C there a= re probably some scenarios in which additional latency might become annoyin= g (such as a multi-user-chat where the delays might cause people to have to= revise their replies-in-progress as characters stream in by fits and start= s). =3B =3B For example=2C in a scenario with some packet loss wher= e re-transmissions are occurring=2C TCP-based transport (e.g. XEP-0301 runn= ing over BOSH) would exhibit head-of-line blocking and it might not be poss= ible to accurately mimic the inter-character timing of the sender. =3B =
= --_ca9db786-1fe2-44fe-9011-98682a64543b_-- From markybox@gmail.com Tue Dec 4 16:02:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C6B21F8A66 for ; Tue, 4 Dec 2012 16:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 o418JVk7wLxb for ; Tue, 4 Dec 2012 16:02:32 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id E641F21F8A34 for ; Tue, 4 Dec 2012 16:02:31 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so1179236wib.13 for ; Tue, 04 Dec 2012 16:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=K1ZrxqWofR7Lc16qtuJ5r2m8JV3e+1kNSCbMu3j+BnQ=; b=srjUnt0GMS2FDl36aN73e69tbjaM8PO+PMqDckACfjMUjbMX2JTz8wSq7P3kKTZM8N VF20nnL84LDw3OPJ0FsbqgyBXTqLUZtFOXnAnc1yD40KHjsXYCx6KFAP6Syy0A5UmP9A Ww6ZPOiS08vJIfqAGv3K+f6injO+GJrjTY4FOK3SSizxY0zVcUbvgdc8jT0sFkXoW9wa flVW8s0jQ9yy7berRKUFeU+PVYKQiSFmMClwZF6iuf5Qz8EPuohrg7DX2cdYqy0b/pXH HSM6iQA+9uHThiITfHPBGsfbT3j3C+uYv4oTYf/8iH1o7D+UWGfE0SRxUDlvFx2mT3Dk AloQ== Received: by 10.216.52.74 with SMTP id d52mr6209222wec.73.1354665748492; Tue, 04 Dec 2012 16:02:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.18.142 with HTTP; Tue, 4 Dec 2012 16:02:08 -0800 (PST) In-Reply-To: References: <50B87606.5030802@ericsson.com> <50BB22EB.1030803@ericsson.com> <50BCFCFE.3080104@nostrum.com> <000001cdd196$796cde90$6c469bb0$@us> <50BE06C9.6050605@alvestrand.no> <50BE2A5E.6040904@jesup.org> <50BE322F.6070206@matthew.at> <50BE3E44.5000000@omnitor.se> <50BE46A0.8050608@matthew.at> <50BE550B.9020801@omnitor.se> From: Mark Rejhon Date: Tue, 4 Dec 2012 19:02:08 -0500 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Engineering approach to RTT communication (Re: Consensus call on Text Communication) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Dec 2012 00:02:33 -0000 On Tue, Dec 4, 2012 at 6:39 PM, Bernard Aboba wrote: > For example, in a scenario with some packet loss > where re-transmissions are occurring, TCP-based transport (e.g. XEP-0301 > running over BOSH) would exhibit head-of-line blocking and it might not be > possible to accurately mimic the inter-character timing of the sender. Depends on implementations & on length of stalls. You can still accurately mimic the inter-character timing of the sender, even with a random BOSH poll (every 0.5 to 1.5 second) with inaccurate timings. XEP-0301 real-time text is simply a buffered series of text transforms (e.g. appends, inserts, deletes, and optional pauses), so the buffer provides some immunity to stalls. In my XEP-0301 implementations, the buffer is 1 second, providing immunity to ping stalls less than that. A TCP/IP stall of 3 seconds just simply causes a 2 second pause, then playback resumes, with stalls under 1 second often not being visible to the end user. Obviously, this is for rich XEP-0301 implementations, supporting the full standard. Implementors can still output in blocks, or word-at-a-time, time-smoothed text, or other implementor-preferred methods of text output. For other readers not familiar, see: http://www.realjabber.org/anim/real_time_text_demo.html Mark Rejhon Author of XEP-0301 From markybox@gmail.com Tue Dec 4 16:24:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7332521F8BB0 for ; Tue, 4 Dec 2012 16:24:47 -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 3GDari29BXuf for ; Tue, 4 Dec 2012 16:24:46 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7831321F841F for ; Tue, 4 Dec 2012 16:24:46 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so1981752wgb.13 for ; Tue, 04 Dec 2012 16:24:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=F4uQ/LHl/RJkpd/zJ34x2dsKX9bxsbWnDCTZVFpbTq8=; b=BgHuDdTyqMu8MtPo/9ARSEON69zcQpnA0RQAYbqcTJ4YpYq0V7da+xZEn/MAFgHYAD d3FvSfW8UkXpAW/GmARpB/W17pQIbpRrL9LbaYQDYoiG+c1abQEVOtYJ4pH9yEmTFGdR WNVeAmPWDd74EGmQUg2ozGhVMlnUJXveldwidVM2O80n04J0jVk09zxC9R1wVA3QCQ9W OZHV/uoEG/mFedBNxiqorpYXj3qiiAxzPtBl3LDHmaLs/jWa5cFmjkOfsgBnGPUPicxm SXps/NaFi8oXf4HgzAcUK+fdmp+CLu8Xp8tnbf8mOrCSVb22gq3xbanzPpcqKt/Voc23 +x7w== Received: by 10.216.203.36 with SMTP id e36mr1173416weo.60.1354667084395; Tue, 04 Dec 2012 16:24:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.18.142 with HTTP; Tue, 4 Dec 2012 16:24:23 -0800 (PST) In-Reply-To: <50BE899A.4020604@matthew.at> References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> <50BE7738.8090403@omnitor.se> <50BE899A.4020604@matthew.at> From: Mark Rejhon Date: Tue, 4 Dec 2012 19:24:23 -0500 Message-ID: To: Matthew Kaufman , rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Dec 2012 00:24:47 -0000 > Then we need answers to my other questions. How do we rate-limit that data > channel, how do you prevent malicious script from tampering (or do you not > care), etc? It's my assumption that data channels are designed to handle rates higher than a few bytes a second. If data-channels are used generically for other media (e.g. photo transfer, file transfer, network video game, etc) it's quite easy to assume that the bandwidth of data channels would be in some significant number of kilobytes per second. For bandwidth rate, both T.140/RFC4103 and XEP-0301 can run at rates at under 1 kilobytes a second (8 kilobits a second), including all protocol overhead, in the worst-case typing scenarios. Only situations such as copy-and-pastes would cause sudden surges, but if the channel is not rate-limited, the copy and pastes will just carry through. (This is preferred). For transaction rate, XEP-0301 is specified to buffer key presses (with or without interval) at a 0.3 to 1.0 second transmit interval, but this is not enforced. (RFC4103/T.140 specifies similiar numbers). XEP-0301 can function usefully at 2 second transmit intervals (though both I and Gunnar recommends against this), or at immediate character-at-a-time transmit. (Not recommended either, since it spikes bandwidth, because it potentially means 30 packets a second when holding a key press down at a typematic of 30 chars/sec). I do not think it is the responsibility of this taskgroup to decide absolute bandwidth and transaction limits for RTT; it should be afforded the same neutrality as a generic data channel. However, reasonable universal protections are fine (e.g. rate limiting, length-per-transaction limits similiar to standard instant messages, etc.) Copy and pastes are contentious, only because of its implications for privacy accidents, and for bandwidth, but are also useful because people use copy & pastes during regular messaging. The problems for RTT is similiar to the problems for standard text messaging -- e.g. excessively long frequent copy & pastes is exactly the same kind of problem for both RTT and for standard instant messaging. Thus, I'd therefore look at existing messaging precedents for security considerations for RTT; with only minor differences (e.g. due to the real-timeness of RTT) without encumbering RTT excessively. The same message-length considerations can be transferred to RTT (at least for message-based RTT), and transaction rate can be limit to meet the lowest recommended number found in existing RTT specs (e.g. rate limit to one packet every 300ms, plus a bit of safety headroom for surges caused by TCP stalls and other effects). I personally prefer my implementations to have no rate limit, though I understand the need to block DoS issues caused by theoretical malicious incoming RTT, if they are not solved by other means in a non-inconvenient manner... Mark Rejhon Author of XEP-0301 From richard@shockey.us Tue Dec 4 18:36:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F5A21F85ED for ; Tue, 4 Dec 2012 18:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.142 X-Spam-Level: X-Spam-Status: No, score=-102.142 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dr5eq1a32tMH for ; Tue, 4 Dec 2012 18:36:34 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id E117421F85DF for ; Tue, 4 Dec 2012 18:36:29 -0800 (PST) Received: (qmail 17447 invoked by uid 0); 5 Dec 2012 02:36:08 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 5 Dec 2012 02:36:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=4fpEE0gRD7V2UZuknBkWJd+M6Lahnzlmn6DwurORehc=; b=Fjxu1PcVa5m/dWo+H7HhP8zXeV4v3oS1elHKOO5EW614Q4o0XJJglXWS7ubMpMPuCjLmm3ALaAW4u3SVTUgIa1nY2FCd2CQsAQ+YlDC+FJdfU1xqVlT1hivjgR+sfrPj; Received: from [71.191.243.130] (port=55233 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Tg4qG-0000T8-6C for rtcweb@ietf.org; Tue, 04 Dec 2012 19:36:08 -0700 From: "Richard Shockey" To: References: In-Reply-To: Date: Tue, 4 Dec 2012 21:36:08 -0500 Message-ID: <02e401cdd291$48bf4d40$da3de7c0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3Sa7E1OpA6p8xYTt+G0g4Juft44gAJL24A Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: Re: [rtcweb] Experiments with Chrome and Firefox X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Dec 2012 02:36:35 -0000 WOW .. this implies a great deal. I think Brother Burger needs to reevaluate his bet. I'm thinking I should get in on some of this action. So how many years until consensus, if ever? -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Tuesday, December 04, 2012 5:07 PM To: Charles-Pierre Astolfi Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Experiments with Chrome and Firefox On 4 December 2012 08:07, Charles-Pierre Astolfi wrote: > Is there a simple webapp that shows webrtc communication between > firefox and chrome? Unless something has changed dramatically in the last few weeks, this is not currently possible. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From tterriberry@mozilla.com Tue Dec 4 18:47:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DBA21F8BF4 for ; Tue, 4 Dec 2012 18:47:33 -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 eky4jdjAgpNZ for ; Tue, 4 Dec 2012 18:47:33 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2457521F8BED for ; Tue, 4 Dec 2012 18:47:33 -0800 (PST) Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id DF60CF210B for ; Tue, 4 Dec 2012 18:47:31 -0800 (PST) Message-ID: <50BEB5BE.6020508@mozilla.com> Date: Tue, 04 Dec 2012 18:47:26 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <02e401cdd291$48bf4d40$da3de7c0$@us> In-Reply-To: <02e401cdd291$48bf4d40$da3de7c0$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Experiments with Chrome and Firefox X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Dec 2012 02:47:33 -0000 Richard Shockey wrote: > WOW .. this implies a great deal. I think Brother Burger needs to > reevaluate his bet. I'm thinking I should get in on some of this action. > So how many years until consensus, if ever? We're actually making pretty good progress on Firefox-Chrome interop, and have had at least partially-working demos (of custom builds with a few patches applied) already. See for a list of bugs on the Firefox side. I think Chrome has a similar (maybe even smaller) number. From basilgohar@librevideo.org Tue Dec 4 19:40:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036B921F8BFD for ; Tue, 4 Dec 2012 19:40:39 -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 ADVaRCfCKKuK for ; Tue, 4 Dec 2012 19:40:38 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 61D3721F8BFA for ; Tue, 4 Dec 2012 19:40:38 -0800 (PST) Received: from [192.168.2.100] (cpe-75-180-52-231.columbus.res.rr.com [75.180.52.231]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id EFF34659616 for ; Tue, 4 Dec 2012 22:40:36 -0500 (EST) Message-ID: <50BEC231.5050000@librevideo.org> Date: Tue, 04 Dec 2012 22:40:33 -0500 From: Basil Mohamed Gohar 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: <02e401cdd291$48bf4d40$da3de7c0$@us> <50BEB5BE.6020508@mozilla.com> In-Reply-To: <50BEB5BE.6020508@mozilla.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Experiments with Chrome and Firefox X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Dec 2012 03:40:39 -0000 On 12/04/2012 09:47 PM, Timothy B. Terriberry wrote: > Richard Shockey wrote: >> WOW .. this implies a great deal. I think Brother Burger needs to >> reevaluate his bet. I'm thinking I should get in on some of this >> action. >> So how many years until consensus, if ever? > > We're actually making pretty good progress on Firefox-Chrome interop, > and have had at least partially-working demos (of custom builds with a > few patches applied) already. > > See > > for a list of bugs on the Firefox side. I think Chrome has a similar > (maybe even smaller) number. That link didn't work for me, but this one appears to get the appropriate bugs and works for me: https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr;query_format=advanced;status_whiteboard=blocking-webrtc-interop -- Libre Video http://librevideo.org From harald@alvestrand.no Wed Dec 5 00:26:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8E521F8BFE for ; Wed, 5 Dec 2012 00:26:36 -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 gx50H1f1U+ut for ; Wed, 5 Dec 2012 00:26:35 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0F921F8BBB for ; Wed, 5 Dec 2012 00:26:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1F51339E1C0 for ; Wed, 5 Dec 2012 09:26:33 +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 TUENs9Gknry1 for ; Wed, 5 Dec 2012 09:26:32 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:bd0b:d19c:7aa0:fb74] (unknown [IPv6:2001:470:de0a:27:bd0b:d19c:7aa0:fb74]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 552E739E179 for ; Wed, 5 Dec 2012 09:26:32 +0100 (CET) Message-ID: <50BF0537.3050008@alvestrand.no> Date: Wed, 05 Dec 2012 09:26:31 +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: <50B87606.5030802@ericsson.com>, <50BB22EB.1030803@ericsson.com> , <50BCFCFE.3080104@nostrum.com>, <000001cdd196$796cde90$6c469bb0$@us> <50BE06C9.6050605@alvestrand.no> <50BE2A5E.6040904@jesup.org> <50BE322F.6070206@matthew.at> <50BE3E44.5000000@omnitor.se> <50BE46A0.8050608@matthew.at> In-Reply-To: <50BE46A0.8050608@matthew.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Engineering approach to RTT communication (Re: Consensus call on Text Communication) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Dec 2012 08:26:36 -0000 On 12/04/2012 07:53 PM, Matthew Kaufman wrote: > >>> - Will there be a consent dialog raised before the JavaScript can >>> send on this channel? >> The normal thing in a total conversation call is to activate all >> three media as soon as possible after call completion. A video >> channel can do much more harm than the RTT channel. > > Did you come in late to the RTCWEB work? For privacy there's a > requirement for camera and microphone access to raise a consent dialog > in the browser before the camera or microphone is activated. On the > other hand, there is no requirement to raise a consent dialog before > opening a data channel. What's the answer for this case? Raising a consent dialog before activating the keyboard seems kind of weird to me. Let's not go there; consent dialogs have so far been for activiating new devices, not for activating transmission channels. From randell-ietf@jesup.org Wed Dec 5 00:28:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685C421F87D1 for ; Wed, 5 Dec 2012 00:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 tpvcQ2zN-y2C for ; Wed, 5 Dec 2012 00:28:33 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9D95721F871A for ; Wed, 5 Dec 2012 00:28:33 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:2483 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TgALI-0005D7-Tk for rtcweb@ietf.org; Wed, 05 Dec 2012 02:28:33 -0600 Message-ID: <50BF0583.80206@jesup.org> Date: Wed, 05 Dec 2012 03:27:47 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> <50BE7738.8090403@omnitor.se> <50BE899A.4020604@matthew.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Dec 2012 08:28:34 -0000 On 12/4/2012 7:24 PM, Mark Rejhon wrote: >> Then we need answers to my other questions. How do we rate-limit that data >> channel, how do you prevent malicious script from tampering (or do you not >> care), etc? > It's my assumption that data channels are designed to handle rates > higher than a few bytes a second. If data-channels are used > generically for other media (e.g. photo transfer, file transfer, > network video game, etc) it's quite easy to assume that the bandwidth > of data channels would be in some significant number of kilobytes per > second. I've transferred 270+MB files from myself to myself (local loopback) through IP sitting in an IETF meeting, in a time measured in seconds. So DataChannels can be high bandwidth. It's also congestion controlled (currently using default SCTP congestion control, which is TCP-like). Eventually we hope to move it to a low-delay CC algorithm to coordinate with RMCAT. In the meantime, we've discussed bandwidth limitations on the DataChannel based on application wishes (such as percentages, a fixed amount, combining percentages with fixed upper/lower limits, etc). See discussions and drafts from recent IETFs. > For bandwidth rate, both T.140/RFC4103 and XEP-0301 can run at rates > at under 1 kilobytes a second (8 kilobits a second), including all > protocol overhead, in the worst-case typing scenarios. Only > situations such as copy-and-pastes would cause sudden surges, but if > the channel is not rate-limited, the copy and pastes will just carry > through. (This is preferred). This should be absolutely no problem. > I do not think it is the responsibility of this taskgroup to decide > absolute bandwidth and transaction limits for RTT; it should be > afforded the same neutrality as a generic data channel. However, > reasonable universal protections are fine (e.g. rate limiting, > length-per-transaction limits similiar to standard instant messages, > etc.) Copy and pastes are contentious, only because of its > implications for privacy accidents, and for bandwidth, but are also > useful because people use copy & pastes during regular messaging. > The problems for RTT is similiar to the problems for standard text > messaging -- e.g. excessively long frequent copy & pastes is exactly > the same kind of problem for both RTT and for standard instant > messaging. We should think about more than just RTT; RTT is just one form of text communication as we've discussed. There's a stairstep of forms from char-by-char RTT through XEP301 to SMS to AIM/Jabber/IRC to forums to email (to snailmail), and plenty of ways you can vary them (speed of SMS delivery, etc). All have their uses - and rtcweb is not limited to realtime communication. (You'd think so, but in fact it's really not.) There are possible store-and-forward uses (both for audio/video and data), which could be leveraged in systems with poor connectivity or in distributed networks (think Arab Spring, etc). These might not be ideal efficient uses from a pure networking perspective - but they'll be a technology easily available to people without having to build all the related facilities (encryption, codecs, negotiation, audio/video capture, etc). These certainly aren't core usecases - but they're possibilities created by providing building blocks and not apps with a bow on them. > Thus, I'd therefore look at existing messaging precedents for security > considerations for RTT; with only minor differences (e.g. due to the > real-timeness of RTT) without encumbering RTT excessively. The same > message-length considerations can be transferred to RTT (at least for > message-based RTT), and transaction rate can be limit to meet the > lowest recommended number found in existing RTT specs (e.g. rate limit > to one packet every 300ms, plus a bit of safety headroom for surges > caused by TCP stalls and other effects). I personally prefer my > implementations to have no rate limit, though I understand the need to > block DoS issues caused by theoretical malicious incoming RTT, if they > are not solved by other means in a non-inconvenient manner... Pretty much agreed, with the proviso that no reasonable solution I can think of avoids the JS app being involved in the capture and display of text. Perhaps the closest I could think of could be having the browser sign each character with a sequence number before handing it to the app (perhaps a chaining cipher if it's using a reliable channel, else a block cipher). Then the receiver can verify it's signed by the same cert used for the media (not available directly to the app). Display is trickier if you don't get magic certifying-RTT-text-display-boxes in the DOM. NOTE: As mentioned, a bunch of this belongs in the W3C, and I think most of the rest should be a separate document (here or in another WG) or a new WG. -- Randell Jesup randell-ietf@jesup.org From BeckW@telekom.de Wed Dec 5 00:40:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFF221F89A9 for ; Wed, 5 Dec 2012 00:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5EP9Opz-Qau for ; Wed, 5 Dec 2012 00:40:21 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id EC91B21F87FF for ; Wed, 5 Dec 2012 00:40:19 -0800 (PST) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 05 Dec 2012 09:40:17 +0100 Received: from HE111644.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.13]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 5 Dec 2012 09:40:17 +0100 From: To: Date: Wed, 5 Dec 2012 09:40:16 +0100 Thread-Topic: [rtcweb] Text communication in RTCWEB sessions Thread-Index: Ac3SeJYTqeEbAoBdSGi5+S9jPrRioQARyB+w Message-ID: References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> <50BE7738.8090403@omnitor.se> <50BE899A.4020604@matthew.at> In-Reply-To: <50BE899A.4020604@matthew.at> 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 Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Dec 2012 08:40:24 -0000 That's the gist of it: - with audio/video, the RTP stream sources (camera, microphone) are fully u= nder browser control. - With RTT, there is currently no browser-controlled source for text entere= d by the user. This would have to be a new HTML element. A consent dialog f= or this element looks like overkill, though. The user must type in it to ma= ke it send. That's different from camera/microphone which send without user= activity. RTT over the data channel seems like a simpler option to me. TCP is real-ti= me enough for text. I frequently use ssh to log into far away servers, and = the occasional delayed character is not that annoying. And with ssh, the de= lay and chance of retransmission is twice that of Real Time Text.. Is there= really a use case which requires tight synchronization between RTT and A/V= streams? Rgeards Wolfgang Beck Deutsche Telekom Technik GmbH Fixed Mobile Engineering Deutschland Wolfgang Beck Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 581 2832 (Tel.) www.telekom.de Erleben, was verbindet. Deutsche Telekom Technik GmbH Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe= is, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft Bonn USt-IdNr. DE 814645262 From gunnar.hellstrom@omnitor.se Wed Dec 5 01:39:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8741421F8C14 for ; Wed, 5 Dec 2012 01:39:47 -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=[AWL=0.015, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxesSDQNTuxZ for ; Wed, 5 Dec 2012 01:39:46 -0800 (PST) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id BCB0721F8C0B for ; Wed, 5 Dec 2012 01:39:43 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Wed, 5 Dec 2012 10:39:35 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id 317B13A04E for ; Wed, 5 Dec 2012 10:39:35 +0100 (CET) Message-ID: <50BF1655.80200@omnitor.se> Date: Wed, 05 Dec 2012 10:39:33 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> <50BE7738.8090403@omnitor.se> <50BE899A.4020604@matthew.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Dec 2012 09:39:47 -0000 On 2012-12-05 09:40, BeckW@telekom.de wrote: > RTT over the data channel seems like a simpler option to me. TCP is real-time enough for text. I frequently use ssh to log into far away servers, and the occasional delayed character is not that annoying. And with ssh, the delay and chance of retransmission is twice that of Real Time Text.. Is there really a use case which requires tight synchronization between RTT and A/V streams? I think you are right in your assessment. The requirement is not for tight synchronization between RTT and A/V. The user expectation is for conversational flow. If you type a question, and expect a response start flowing in text, you expect the other party to start responding quickly. If a response is not beginning quiclkly enough, or there are long pauses, the waiting user starts wondering if the question was not understood, or needed extra info or so, and might start sending additional info or other questions, leading to confusion and conversational collissions. For this conversational application, I assess that occasional extra delay of up to 4 or even 5 seconds, not more than once per minute are acceptable. ( I have no research for acceptance of exactly this situation with mid-response delay. ) Combined with video, there is of course a little bit of extra wondering by the receiving user, seeing the typing user, but for some seconds not seeing any resulting text. Still, within 5 seconds and not so often, it likely just causes a bit of annoyance. Gunnar From Markus.Isomaki@nokia.com Wed Dec 5 04:51:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D6D21F84F8 for ; Wed, 5 Dec 2012 04:51:31 -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 26k1co6nWpF1 for ; Wed, 5 Dec 2012 04:51:30 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8D86121F84F5 for ; Wed, 5 Dec 2012 04:51:29 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qB5CpMGI024575; Wed, 5 Dec 2012 14:51:23 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Dec 2012 14:51:22 +0200 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.131]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.02.0318.003; Wed, 5 Dec 2012 12:51:21 +0000 From: To: , Thread-Topic: [rtcweb] Text communication in RTCWEB sessions Thread-Index: AQHN0sx+p0coLe6JH0ylTs6e2knCJJgKIJFA Date: Wed, 5 Dec 2012 12:51:21 +0000 Message-ID: References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> <50BE7738.8090403@omnitor.se> <50BE899A.4020604@matthew.at> <50BF1655.80200@omnitor.se> In-Reply-To: <50BF1655.80200@omnitor.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.81.131] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Dec 2012 12:51:22.0182 (UTC) FILETIME=[3A594660:01CDD2E7] X-Nokia-AV: Clean Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Dec 2012 12:51:31 -0000 Gunnar Hellstr=F6m wrote: > >On 2012-12-05 09:40, BeckW@telekom.de wrote: >> RTT over the data channel seems like a simpler option to me. TCP is real= - >time enough for text. I frequently use ssh to log into far away servers, a= nd the >occasional delayed character is not that annoying. And with ssh, the delay= and >chance of retransmission is twice that of Real Time Text.. Is there really= a use >case which requires tight synchronization between RTT and A/V streams? >I think you are right in your assessment. >The requirement is not for tight synchronization between RTT and A/V. > >The user expectation is for conversational flow. > >If you type a question, and expect a response start flowing in text, you e= xpect >the other party to start responding quickly. If a response is not beginnin= g >quiclkly enough, or there are long pauses, the waiting user starts wonderi= ng if >the question was not understood, or needed extra info or so, and might sta= rt >sending additional info or other questions, leading to confusion and >conversational collissions. > >For this conversational application, I assess that occasional extra delay = of up to >4 or even 5 seconds, not more than once per minute are acceptable. ( I hav= e >no research for acceptance of exactly this situation with mid-response del= ay. ) > >Combined with video, there is of course a little bit of extra wondering by= the >receiving user, seeing the typing user, but for some seconds not seeing an= y >resulting text. Still, within 5 seconds and not so often, it likely just c= auses a bit >of annoyance. > So can we conclude that the RTCWeb data channel can provide good enough tra= nsport for Real Time Text service? If so, would there still be some other s= howstoppers why implementing an RTT-compliant service on top of RTCWeb brow= ser would not be possible? I don't say that having some *additional* suppor= t in the browser to make the RTT implementation *easier* would not be impor= tant, but that would be less critical, and could be solved by JS libraries.= =20 Markus=20 From gunnar.hellstrom@omnitor.se Wed Dec 5 05:29:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86DDE21F881D for ; Wed, 5 Dec 2012 05:29:16 -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=[AWL=0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bckz128CWXoZ for ; Wed, 5 Dec 2012 05:29:16 -0800 (PST) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 4846721F871A for ; Wed, 5 Dec 2012 05:29:14 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP; Wed, 5 Dec 2012 14:29:05 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id A0D2E3A163; Wed, 5 Dec 2012 14:29:05 +0100 (CET) Message-ID: <50BF4C23.7030108@omnitor.se> Date: Wed, 05 Dec 2012 14:29:07 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> <50BE7738.8090403@omnitor.se> <50BE899A.4020604@matthew.at> <50BF1655.80200@omnitor.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010904050602070503040902" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Dec 2012 13:29:16 -0000 This is a multi-part message in MIME format. --------------010904050602070503040902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2012-12-05 13:51, Markus.Isomaki@nokia.com wrote: > So can we conclude that the RTCWeb data channel can provide good enough transport for Real Time Text service? If so, would there still be some other showstoppers why implementing an RTT-compliant service on top of RTCWeb browser would not be possible? I don't say that having some*additional* support in the browser to make the RTT implementation*easier* would not be important, but that would be less critical, and could be solved by JS libraries. I think that solution is feasible. It seems that the following is needed: Standards for 1.-the Data channel label name. 2. -The characteristics of the Data Channel: semi-reliable, give up after maximum 5(?) seconds, indication on gap in reception, delivery in order. 3. -The format of text. ITU-T T.140. ( using UTF-8 ) ( or core of XEP-0301 in some way) 4. -Minimum transmission interval. ( 200 ms ?) 5. Translation in SIP/rtcweb gateway between RFC 4103 sdp and rtcweb/t.140 sdp One reason for the need of the standards is for proper interworking with SIP sessions. Libraries for Time sampling, transmission and local display of keyboard input as RTT data. Reception, and presentation of received text. Handling of single party and multi-party calls. Handling coordination in same call as audio and video. Not showstopper, but I wonder: Are there any thoughts of having anything similar to SIP media-tags and language-tags to show capabilities and preferences even before call negotiation? That could be if importance for routing of sessions to the best capable terminal matching the preferences of the caller or the opposite. Gunnar --------------010904050602070503040902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2012-12-05 13:51, Markus.Isomaki@nokia.com wrote:
So can we conclude that the RTCWeb data channel can provide good enough transport for Real Time Text service? If so, would there still be some other showstoppers why implementing an RTT-compliant service on top of RTCWeb browser would not be possible? I don't say that having some *additional* support in the browser to make the RTT implementation *easier* would not be important, but that would be less critical, and could be solved by JS libraries.
I think that solution is feasible.

It seems that the following is needed:

Standards for
1.-the Data channel label name.
2. -The characteristics of the Data Channel: semi-reliable, give up after maximum 5(?) seconds, indication on gap in reception, delivery in order.

3. -The format of text. ITU-T T.140. ( using UTF-8 )     ( or core of XEP-0301 in some way)  
4. -Minimum transmission interval. ( 200 ms ?)

5. Translation in SIP/rtcweb gateway between  RFC 4103 sdp and rtcweb/t.140 sdp


One reason for the need of the standards is for proper interworking with SIP sessions.
 
Libraries for
Time sampling, transmission and local display of keyboard input as RTT data.
Reception, and presentation of received text.
Handling of single party and multi-party calls.
Handling coordination in same call as audio and video.

Not showstopper, but I wonder: Are there any thoughts of having anything similar to SIP media-tags and language-tags to show capabilities and preferences even before call negotiation?  That could be if importance for routing of sessions to the best capable terminal matching the preferences of the caller or the opposite.

Gunnar


--------------010904050602070503040902-- From eburger@standardstrack.com Wed Dec 5 05:43:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DB121F89AD for ; Wed, 5 Dec 2012 05:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.799 X-Spam-Level: X-Spam-Status: No, score=-101.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 fl3HIf0kPd02 for ; Wed, 5 Dec 2012 05:43:47 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 7706521F8973 for ; Wed, 5 Dec 2012 05:43:47 -0800 (PST) Received: from dhcp63-140-165-138.hil-sjchshx.sjc.wayport.net ([63.140.165.138]:55370) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TgFGK-0000PS-6x for rtcweb@ietf.org; Wed, 05 Dec 2012 05:43:44 -0800 From: Eric Burger Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/signed; boundary=Apple-Mail-231-598187580; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 5 Dec 2012 05:43:45 -0800 In-Reply-To: <50BF4C23.7030108@omnitor.se> To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> <50BE7738.8090403@omnitor.se> <50BE899A.4020604@matthew.at> <50BF1655.80200@omnitor.se> <50BF4C23.7030108@omnitor.se> Message-Id: X-Mailer: Apple Mail (2.1085) 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: Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Dec 2012 13:43:48 -0000 --Apple-Mail-231-598187580 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I like #1-4 below. I do not like #5 as a hard requirement. If we may not = really deliver voice or video to the legacy network, I am not hung up on = not delivering RTT either. On Dec 5, 2012, at 5:29 AM, Gunnar Hellstr=F6m wrote: > On 2012-12-05 13:51, Markus.Isomaki@nokia.com wrote: >> So can we conclude that the RTCWeb data channel can provide good = enough transport for Real Time Text service? If so, would there still be = some other showstoppers why implementing an RTT-compliant service on top = of RTCWeb browser would not be possible? I don't say that having some = *additional* support in the browser to make the RTT implementation = *easier* >> would not be important, but that would be less critical, and could = be solved by JS libraries.=20 >>=20 > I think that solution is feasible. >=20 > It seems that the following is needed: >=20 > Standards for=20 > 1.-the Data channel label name. > 2. -The characteristics of the Data Channel: semi-reliable, give up = after maximum 5(?) seconds, indication on gap in reception, delivery in = order.=20 >=20 > 3. -The format of text. ITU-T T.140. ( using UTF-8 ) ( or core of = XEP-0301 in some way) =20 > 4. -Minimum transmission interval. ( 200 ms ?) >=20 > 5. Translation in SIP/rtcweb gateway between RFC 4103 sdp and = rtcweb/t.140 sdp >=20 >=20 > One reason for the need of the standards is for proper interworking = with SIP sessions.=20 > =20 > Libraries for > Time sampling, transmission and local display of keyboard input as RTT = data. > Reception, and presentation of received text. > Handling of single party and multi-party calls. > Handling coordination in same call as audio and video. >=20 > Not showstopper, but I wonder: Are there any thoughts of having = anything similar to SIP media-tags and language-tags to show = capabilities and preferences even before call negotiation? That could = be if importance for routing of sessions to the best capable terminal = matching the preferences of the caller or the opposite. >=20 > Gunnar >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-231-598187580 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMjA1MTM0MzQ2WjAjBgkqhkiG9w0BCQQxFgQU XwSVqIWOglGGvlhYCBgL5SsACg4wgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAuLE3+9tTJ2mbEmy3xY5ACtjywd/WtVG9JuqnH6p5nGqD95vSwBLC bhtCYBQYL4jtHKaNpJ8yEmgDoKhUVUiS/k/blpxBvTia/4zM5d8Z3ZCIjv2a0sSPuqHbfKiq1JUQ EclCRkrRkQmDnNsxRuWxFvOkTGQJmBV4r6XCtO1t/RN1jkbJbJo1tWDq3NLLdAmVSJKzBDo/SCNO P4W4hF1RTn2ziGhPbZtvjD01c12BVU1vfrkdmEusxDdSttAHnSWsA50NtTPHz0MDbCrfndWp9czG jW73qrxZLKmsgMVnbM/X/dloU15I1LxhUINGpGhzM0J+uUJ/Q/J7JX4hHYZJjgAAAAAAAA== --Apple-Mail-231-598187580-- From gunnar.hellstrom@omnitor.se Wed Dec 5 05:47:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2083321F8AF4 for ; Wed, 5 Dec 2012 05:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+FpvxKCEggq for ; Wed, 5 Dec 2012 05:47:22 -0800 (PST) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 205D221F89DC for ; Wed, 5 Dec 2012 05:47:21 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Wed, 5 Dec 2012 14:47:15 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-08-01.atm.binero.net (Postfix) with ESMTPA id 68EFE3A009 for ; Wed, 5 Dec 2012 14:47:15 +0100 (CET) Message-ID: <50BF5064.2090706@omnitor.se> Date: Wed, 05 Dec 2012 14:47:16 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> <50BE7738.8090403@omnitor.se> <50BE899A.4020604@matthew.at> <50BF1655.80200@omnitor.se> <50BF4C23.7030108@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Dec 2012 13:47:23 -0000 On 2012-12-05 14:43, Eric Burger wrote: > If we may not really deliver voice or video to the legacy network, I am not hung up on not delivering RTT either. What does this mean? I thought someone talked about not building silos anymore? Gunnar From harald@alvestrand.no Wed Dec 5 08:16:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26FC21F8CDF for ; Wed, 5 Dec 2012 08:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.439 X-Spam-Level: X-Spam-Status: No, score=-110.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 EbJJ6VVPvWqw for ; Wed, 5 Dec 2012 08:16:01 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 18CC521F8CDE for ; Wed, 5 Dec 2012 08:16:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DA4EB39E1C0 for ; Wed, 5 Dec 2012 17:15: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 ZVvS1cYKFOsa for ; Wed, 5 Dec 2012 17:15:58 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:a184:710a:187:1564] (unknown [IPv6:2001:470:de0a:27:a184:710a:187:1564]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E3A3F39E16A for ; Wed, 5 Dec 2012 17:15:57 +0100 (CET) Message-ID: <50BF733D.1070006@alvestrand.no> Date: Wed, 05 Dec 2012 17:15:57 +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: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> <50BE7738.8090403@omnitor.se> <50BE899A.4020604@matthew.at> <50BF1655.80200@omnitor.se> <50BF4C23.7030108@omnitor.se> <50BF5064.2090706@omnitor.se> In-Reply-To: <50BF5064.2090706@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Dec 2012 16:16:01 -0000 On 12/05/2012 02:47 PM, Gunnar Hellström wrote: > On 2012-12-05 14:43, Eric Burger wrote: >> If we may not really deliver voice or video to the legacy network, I >> am not hung up on not delivering RTT either. > What does this mean? > I thought someone talked about not building silos anymore? At the Protothon meetup in London, someone created an application that created an ambient sound by relaying sounds across peoples' laptops - you created a sound, and it came out of someone else's speaker, offering an unique, created-on-the-fly, multi-person musical instrument. That application (which was created by ~4 people in ~8 hours) will likely never be used to deliver any kind of content to the legacy network. Of course the legacy network needs its voice, and some newer parts of the legacy network need their video and RTT. We want to find good ways of feeding that to them. But that's not the only game in town. From Kevin.Dempsey@ACULAB.COM Thu Dec 6 01:24:07 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA05521F8575 for ; Thu, 6 Dec 2012 01:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.712 X-Spam-Level: * X-Spam-Status: No, score=1.712 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+iVQxhg0aFN for ; Thu, 6 Dec 2012 01:24:06 -0800 (PST) Received: from mx0.aculab.com (mx0.aculab.com [213.249.233.131]) by ietfa.amsl.com (Postfix) with SMTP id 8E00C21F8558 for ; Thu, 6 Dec 2012 01:24:04 -0800 (PST) Received: (qmail 5564 invoked from network); 6 Dec 2012 09:23:57 -0000 Received: from localhost (127.0.0.1) by mx0.aculab.com with SMTP; 6 Dec 2012 09:23:57 -0000 Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 05178-01 for ; Thu, 6 Dec 2012 09:23:53 +0000 (GMT) Received: (qmail 5532 invoked by uid 599); 6 Dec 2012 09:23:53 -0000 Received: from unknown (HELO saturn3.Aculab.com) (10.202.163.5) by mx0.aculab.com (qpsmtpd/0.28) with ESMTP; Thu, 06 Dec 2012 09:23:53 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDD392.65F24610" Date: Thu, 6 Dec 2012 09:17:54 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [rtcweb] Text communication in RTCWEB sessions Thread-Index: Ac3TkpL7JU7S56GgRPW3esHGqpZCsA== From: "Kevin Dempsey" To: X-Virus-Scanned: by iCritical at mx0.aculab.com X-Mailman-Approved-At: Thu, 06 Dec 2012 01:54:06 -0800 Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Dec 2012 09:36:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDD392.65F24610 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Using data channels would mean that the format of text becomes application specific,=20 so people using facewidget can talk with other facewidget users but, unlike audio,=20 gatewaying would be necessary to talk to Gibble+ users. =20 Also, adding data channel support to media gateways would require implementation of=20 SCTP, the data channel protocol and the various text encodings.=20 =20 =20 =20 The technical benefits of RFC4103 include: 1) RFC4103 is based on RTP and can be sent using secure RTP. 2) Text presentation can be paced using the RTP timestamp (runs at 1000Hz). 3) It can be included in a 'BUNDLE', so reducing the number of ports that need to be opened. 4) DTLS/SRTP to RTP gateways would treat the text stream the same as audio and video streams. =20 =20 It is also being pushed by various organizations as the real-time text medium of choice=20 for emergency service access in the USA and Europe. Please refer to the following: http://trace.wisc.edu/docs/2008-RTT-Proposal/Proposal-R1-Dec10-2008.pdf http://www.fcc.gov/document/fcc-adopts-next-generation-911-nprm http://www.reach112.eu/ressource/static/files/reach112_d3.2_final_specif ication_d3.2_v2.1-.pdf =20 =20 Some discussion has been about real-time verses message-based text communication. There=20 is nothing to prevent the user agent presenting whole messages to the underlying stream=20 rather than each character as it is typed. So provided a real-time text stream is available=20 an application layer could implement a message-based system over the top. =0D=0A =0D= ------_=_NextPart_001_01CDD392.65F24610 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Using data = channels would mean that the format of text becomes application = specific,

so people using facewidget = can talk with other facewidget users but, unlike audio, =

gatewaying would be necessary to = talk to Gibble+ users.

 

Also, adding = data channel support to media gateways would require implementation of =

SCTP, the data channel protocol and = the various text encodings.

 

 

 

The = technical benefits of RFC4103 include:

1) RFC4103 is based on RTP and can be sent using = secure RTP.

2) Text presentation can = be paced using the RTP timestamp (runs at 1000Hz).

3) It can be included in a 'BUNDLE', so reducing the = number of ports that need to be opened.

4) DTLS/SRTP to RTP gateways would treat the text = stream the same as audio and video streams.

 

 

It is also = being pushed by various organizations as the real-time text medium of = choice

for emergency service access = in the USA and Europe. Please refer to the following:

http://trace.wisc.edu/docs/2008-RTT-Proposal/Proposal-R= 1-Dec10-2008.pdf

http://www.fcc.gov/document/fcc-adopts-next-generation-= 911-nprm

http://www.reach112.eu/ressource/static/files/reach112_= d3.2_final_specification_d3.2_v2.1-.pdf

 

 

Some = discussion has been about real-time verses message-based text = communication. There

is nothing to = prevent the user agent presenting whole messages to the underlying = stream

rather than each character as = it is typed. So provided a real-time text stream is available =

an application layer could implement = a message-based system over the top.


= =0D=0A
Registered Address Lakeside, Br= amley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 13973= 86 (Wales)
=0D=0A
=0D=0A

P Please consider the environment and d= on't print this e-mail unless you really need to

<= /FONT>

= ------_=_NextPart_001_01CDD392.65F24610-- From randell-ietf@jesup.org Thu Dec 6 12:09:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE38821F896D for ; Thu, 6 Dec 2012 12:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 zGbVL+YsH9hY for ; Thu, 6 Dec 2012 12:09:09 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2159921F86A7 for ; Thu, 6 Dec 2012 12:09:08 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:61298 helo=[192.168.1.3]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Tghkq-000CWO-5c for rtcweb@ietf.org; Thu, 06 Dec 2012 14:09:08 -0600 Message-ID: <50C0FB66.6050102@jesup.org> Date: Thu, 06 Dec 2012 15:09:10 -0500 From: Randell Jesup 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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Dec 2012 20:09:10 -0000 On 12/6/2012 4:17 AM, Kevin Dempsey wrote: > > Using data channels would mean that the format of text becomes > application specific, > > so people using facewidget can talk with other facewidget users but, > unlike audio, > > gatewaying would be necessary to talk to Gibble+ users. > This was the purpose of the proposal I made at IETF Atlanta; we will add a 'protocol' text field similar to the one in WebSockets. It has little actual use there, but here it can serve the purpose you care about - identifying the protocol for a stream in a cross-application way. So facewidget and Gibble+ would happily be able to talk to each other. Gibble+ would offer a DataChannel in the SDP (m=application; see the SDP draft for SCTP) and would specify it wanted a DataChannel with protocol (say) of T140. facewidget would answer accepting it and you'd have a bidirectional T140-over-DataChannel connection both sides know how to use. > Also, adding data channel support to media gateways would require > implementation of > > SCTP, the data channel protocol and the various text encodings. > Correct. > The technical benefits of RFC4103 include: > > 1) RFC4103 is based on RTP and can be sent using secure RTP. > DataChannels run over SCTP-over-DTLS, and so is fully secure as well. > 2) Text presentation can be paced using the RTP timestamp (runs at > 1000Hz). > > 3) It can be included in a 'BUNDLE', so reducing the number of ports > that need to be opened. > The DataChannel SCTP connection will also be BUNDLEd; it's another m= line > 4) DTLS/SRTP to RTP gateways would treat the text stream the same as > audio and video streams. > > It is also being pushed by various organizations as the real-time text > medium of choice > > for emergency service access in the USA and Europe. Please refer to > the following: > > http://trace.wisc.edu/docs/2008-RTT-Proposal/Proposal-R1-Dec10-2008.pdf > > http://www.fcc.gov/document/fcc-adopts-next-generation-911-nprm > > http://www.reach112.eu/ressource/static/files/reach112_d3.2_final_specification_d3.2_v2.1-.pdf > Not disagreeing, but do see the earlier discussions; I don't think this is a blocking issue. -- Randell Jesup randell-ietf@jesup.org From fluffy@cisco.com Thu Dec 6 19:09:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A269A21F858E for ; Thu, 6 Dec 2012 19:09:18 -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 mSAvHTcON+Eq for ; Thu, 6 Dec 2012 19:09:17 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B8D5121F855C for ; Thu, 6 Dec 2012 19:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2899; q=dns/txt; s=iport; t=1354849757; x=1356059357; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ti3k9mV5TrsnjZwhnFXoQN8J43wdReBy5LadWy6qfVo=; b=L5fk7MB0sCI++UtfM0JcJqznqTPgPqaSP7pY87U3N65O+UXax6ao8+HI Lj1ongWgOtVRE+yM7RnOrXu4dYKVyFFkWqt2V4RCTVx26WJVVLggVPzI3 XnE7Wi5X0mVXnqss0dp/lJUuZ+56RUMIbutzY0jzLRWzc1932E0OgHltg Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACFdwVCtJV2c/2dsb2JhbABEvjQWc4IeAQEBAwEBAQFrCwULAgEIGAokJwslAgQOBQgTh28GDMJnBIw5g2JhA4gqiiaTeoJzgiI X-IronPort-AV: E=McAfee;i="5400,1158,6918"; a="150315238" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 07 Dec 2012 03:09:17 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qB739HUS015204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Dec 2012 03:09:17 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.109]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Thu, 6 Dec 2012 21:09:16 -0600 From: "Cullen Jennings (fluffy)" To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= Thread-Topic: [rtcweb] Text communication in RTCWEB sessions Thread-Index: AQHN1Cg9DFqXQ7EA9EG9p+LzPomCYw== Date: Fri, 7 Dec 2012 03:09:16 +0000 Message-ID: References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> <50BE7738.8090403@omnitor.se> <50BE899A.4020604@matthew.at> <50BF1655.80200@omnitor.se> <50BF4C23.7030108@omnitor.se> In-Reply-To: <50BF4C23.7030108@omnitor.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] 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] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Dec 2012 03:09:18 -0000 Gunnar,=20 I'd be very interested to see someone prototype up a gateway that, on one s= ide, downloaded some JS to a web browser that created a DataChannel connect= ion from the browser to the gateway and provide a UI for RTT. On the other = side of the gateway it could do SIP with T.140. My guess is that someone co= uld get this working and it would help see if things were missing from the = WebRTC API / RTCWeb protocols to be able to do this. I suspect that items 1= ,2,3, and 4 are in the control of the gateway so may not need to be standar= dized. As to #5, I would hope the SDP in WebRTC is compatible with SIP off= er / answer so I would hope nothing complicated was need to be specified fo= r #5. As to language tags, the browser can use the Accept-Languages header = in the HTTP.=20 Cullen On Dec 5, 2012, at 6:29 AM, Gunnar Hellstr=F6m wrote: > On 2012-12-05 13:51, Markus.Isomaki@nokia.com wrote: >> So can we conclude that the RTCWeb data channel can provide good enough = transport for Real Time Text service? If so, would there still be some othe= r showstoppers why implementing an RTT-compliant service on top of RTCWeb b= rowser would not be possible? I don't say that having some *additional* sup= port in the browser to make the RTT implementation *easier* >> would not be important, but that would be less critical, and could be s= olved by JS libraries.=20 >>=20 > I think that solution is feasible. >=20 > It seems that the following is needed: >=20 > Standards for=20 > 1.-the Data channel label name. > 2. -The characteristics of the Data Channel: semi-reliable, give up after= maximum 5(?) seconds, indication on gap in reception, delivery in order.=20 >=20 > 3. -The format of text. ITU-T T.140. ( using UTF-8 ) ( or core of XEP= -0301 in some way) =20 > 4. -Minimum transmission interval. ( 200 ms ?) >=20 > 5. Translation in SIP/rtcweb gateway between RFC 4103 sdp and rtcweb/t.1= 40 sdp >=20 >=20 > One reason for the need of the standards is for proper interworking with = SIP sessions.=20 > =20 > Libraries for > Time sampling, transmission and local display of keyboard input as RTT da= ta. > Reception, and presentation of received text. > Handling of single party and multi-party calls. > Handling coordination in same call as audio and video. >=20 > Not showstopper, but I wonder: Are there any thoughts of having anything = similar to SIP media-tags and language-tags to show capabilities and prefer= ences even before call negotiation? That could be if importance for routin= g of sessions to the best capable terminal matching the preferences of the = caller or the opposite. >=20 > Gunnar >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From gunnar.hellstrom@omnitor.se Thu Dec 6 22:34:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A86821F88D1 for ; Thu, 6 Dec 2012 22:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eM5reBIpS80g for ; Thu, 6 Dec 2012 22:34:34 -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 D3C4221F88E3 for ; Thu, 6 Dec 2012 22:34:31 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Fri, 7 Dec 2012 07:34:23 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-06-01.atm.binero.net (Postfix) with ESMTPA id 1592F3A187; Fri, 7 Dec 2012 07:34:23 +0100 (CET) Message-ID: <50C18DF0.9010004@omnitor.se> Date: Fri, 07 Dec 2012 07:34:24 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= 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: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> <50BE7738.8090403@omnitor.se> <50BE899A.4020604@matthew.at> <50BF1655.80200@omnitor.se> <50BF4C23.7030108@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Cullen Jennings \(fluffy\)" Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Dec 2012 06:34:34 -0000 On 2012-12-07 04:09, Cullen Jennings (fluffy) wrote: > Gunnar, > > I'd be very interested to see someone prototype up a gateway that, on one side, downloaded some JS to a web browser that created a DataChannel connection from the browser to the gateway and provide a UI for RTT. On the other side of the gateway it could do SIP with T.140. My guess is that someone could get this working and it would help see if things were missing from the WebRTC API / RTCWeb protocols to be able to do this. I suspect that items 1,2,3, and 4 are in the control of the gateway so may not need to be standardized. As to #5, I would hope the SDP in WebRTC is compatible with SIP offer / answer so I would hope nothing complicated was need to be specified for #5. As to language tags, the browser can use the Accept-Languages header in the HTTP. > > Cullen Cullen, Yes, I think that is a good and realistic challenge, and an activity that I would like to participate in. You are also right that for the gateway application it can likely be done without standardization, when the gateway implementation is also managing the web page used for the UI. The need for standardization comes in for the following cases: a. When you from the same UI want to have a SIP call at one moment, and a WebRTC call to another user of another browser and web server at another moment. b. When you want to separate the management and development of the gateway from the web pages and web servers. c. When you want to encourage development of the smartest web page for RTT communication that can fit into any server environment and have communication with other web pages used in that or other environments. Thanks for the hint on Language-tags. Is there anything similar for media-tags. Declaring and detecting "text" media capability or requirement can be a way to select the proper terminal among a set being reachable through the same address. This is not urgent at the moment, just good to know if such mechanisms are already in place. A prototype is likely perfectly doable, and can by simple agreement also include any of cases a,b,c. Maybe Adam's promised development is already half-ready with the UI part to incorporate in this effort. ;-) Gunnar From Markus.Isomaki@nokia.com Fri Dec 7 03:08:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AB521F8925 for ; Fri, 7 Dec 2012 03:08:14 -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 GuzDfL2dyvNk for ; Fri, 7 Dec 2012 03:08:13 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8E88121F8906 for ; Fri, 7 Dec 2012 03:08:13 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qB7B89NO006794; Fri, 7 Dec 2012 13:08:10 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Dec 2012 13:08:08 +0200 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.185]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0318.003; Fri, 7 Dec 2012 11:08:08 +0000 From: To: , Thread-Topic: [rtcweb] Text communication in RTCWEB sessions - benefits of specific standardization Thread-Index: Ac3UZ/D0g0Zj47+ISG+/jK2w3cJtqw== Date: Fri, 7 Dec 2012 11:08:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.81.91] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Dec 2012 11:08:08.0768 (UTC) FILETIME=[239CCC00:01CDD46B] X-Nokia-AV: Clean Cc: fluffy@cisco.com Subject: Re: [rtcweb] Text communication in RTCWEB sessions - benefits of specific standardization X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Dec 2012 11:08:14 -0000 Hi Gunnar, Cullen,=20 It would indeed be very good to get a crisp understanding about the concret= e benefits of the _additional_ RTT related standardization. Gunnar has a fe= w points below which seem to be on the right level. Perhaps a very short dr= aft that summarizes the benefits and the new requirements stemming from the= m would be a good way to progress this. A couple of comments below based on my understanding.=20 Gunnar Hellstr=F6m wrote: > >[...] for the gateway application it can likely be done without >standardization, when the gateway implementation is also managing the web >page used for the UI. Yes, as long as everything happens within one "server" or "domain", a propr= ietary protocol over the data channel should work fine. And as long as the = gateway to any external system (SIP, XMPP, ...) is fully under the control = of that "domain", the gateway could do the mapping without further standard= ization.=20 > >The need for standardization comes in for the following cases: >a. When you from the same UI want to have a SIP call at one moment, and a >WebRTC call to another user of another browser and web server at another >moment. > I guess this is still doable (withoug additional standards) as long as you = fully control the gateway to SIP? I mean, just define your prorietary data = channel RTT protocol and use it directly between browsers or from the brows= er to the SIP gateway. =20 >b. When you want to separate the management and development of the >gateway from the web pages and web servers. > This is definitely a valid point. If there was a "WebRTC RTT protocol", peo= ple could build generic gateways for it.=20 >c. When you want to encourage development of the smartest web page for >RTT communication that can fit into any server environment and have >communication with other web pages used in that or other environments. > =20 Not sure if that is what is meant here, but the main benefit of any standar= d "media" protocol/format in WebRTC - be it on top of RTP or data channel -= is that in principle you can run it end-to-end (browser-to-browser) inter-= domain. If two domains used differnet proprietary "RTT" protocols on top of= the data channel, they would need to gateway between them. However, if the= y use the same protocol, they only gateway "signaling" but that data channe= l (or RTP) could run end-to-end. Markus=20 From gunnar.hellstrom@omnitor.se Fri Dec 7 06:01:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0F321F8531 for ; Fri, 7 Dec 2012 06:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSay2TItFTLu for ; Fri, 7 Dec 2012 06:01:41 -0800 (PST) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id B767921F8997 for ; Fri, 7 Dec 2012 06:01:31 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP; Fri, 7 Dec 2012 15:01:24 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id 419483A1CA; Fri, 7 Dec 2012 15:01:24 +0100 (CET) Message-ID: <50C1F6B6.7030403@omnitor.se> Date: Fri, 07 Dec 2012 15:01:26 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: fluffy@cisco.com, rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions - benefits of specific standardization X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Dec 2012 14:01:43 -0000 On 2012-12-07 12:08, Markus.Isomaki@nokia.com wrote: > Hi Gunnar, Cullen, > > It would indeed be very good to get a crisp understanding about the concrete benefits of the _additional_ RTT related standardization. Gunnar has a few points below which seem to be on the right level. Perhaps a very short draft that summarizes the benefits and the new requirements stemming from them would be a good way to progress this. > > A couple of comments below based on my understanding. Markus, Yes, it seems that a draft would be needed now to get everything collected. Some simple pictures seem to be needed so that the use cases are clear. e.g. I meant case a) to be inter-domain for the rtcweb call. (a. When you from the same UI want to have a SIP call at one moment, and a WebRTC call to another user of another browser and web server at another moment.) etc. Gunnar > Gunnar Hellström wrote: >> [...] for the gateway application it can likely be done without >> standardization, when the gateway implementation is also managing the web >> page used for the UI. > Yes, as long as everything happens within one "server" or "domain", a proprietary protocol over the data channel should work fine. And as long as the gateway to any external system (SIP, XMPP, ...) is fully under the control of that "domain", the gateway could do the mapping without further standardization. > >> The need for standardization comes in for the following cases: >> a. When you from the same UI want to have a SIP call at one moment, and a >> WebRTC call to another user of another browser and web server at another >> moment. >> > I guess this is still doable (withoug additional standards) as long as you fully control the gateway to SIP? I mean, just define your prorietary data channel RTT protocol and use it directly between browsers or from the browser to the SIP gateway. > >> b. When you want to separate the management and development of the >> gateway from the web pages and web servers. >> > This is definitely a valid point. If there was a "WebRTC RTT protocol", people could build generic gateways for it. > >> c. When you want to encourage development of the smartest web page for >> RTT communication that can fit into any server environment and have >> communication with other web pages used in that or other environments. >> > > Not sure if that is what is meant here, but the main benefit of any standard "media" protocol/format in WebRTC - be it on top of RTP or data channel - is that in principle you can run it end-to-end (browser-to-browser) inter-domain. If two domains used differnet proprietary "RTT" protocols on top of the data channel, they would need to gateway between them. However, if they use the same protocol, they only gateway "signaling" but that data channel (or RTP) could run end-to-end. > > Markus From adam@nostrum.com Fri Dec 7 06:26:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3769A21F8984 for ; Fri, 7 Dec 2012 06:26:06 -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=[AWL=0.000, 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 4YLJr3fOveYy for ; Fri, 7 Dec 2012 06:26:05 -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 2843E21F8532 for ; Fri, 7 Dec 2012 06:26:04 -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 qB7EQ2wx051739 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 7 Dec 2012 08:26:02 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50C1FC7A.2090507@nostrum.com> Date: Fri, 07 Dec 2012 08:26:02 -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: Markus.Isomaki@nokia.com 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: fluffy@cisco.com, rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions - benefits of specific standardization X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Dec 2012 14:26:06 -0000 On 12/7/12 05:08, Markus.Isomaki@nokia.com wrote: > [T]he main benefit of any standard "media" protocol/format in WebRTC - be it on top of RTP or data channel - is that in principle you can run it end-to-end (browser-to-browser) inter-domain. If two domains used differnet proprietary "RTT" protocols on top of the data channel, they would need to gateway between them. However, if they use the same protocol, they only gateway "signaling" but that data channel (or RTP) could run end-to-end. That's exactly what Randell has been proposing: defining how to send RTT over the data channel in a consistent fashion so that it can travel interdomain. This would also facilitate the "generic gateway" usecase you talk about. /a From martin.thomson@gmail.com Fri Dec 7 09:45:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B828821F898B for ; Fri, 7 Dec 2012 09:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.708 X-Spam-Level: X-Spam-Status: No, score=-4.708 tagged_above=-999 required=5 tests=[AWL=-1.409, BAYES_00=-2.599, 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 ZDJsujsrrbUl for ; Fri, 7 Dec 2012 09:45:20 -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 EE5DC21F8983 for ; Fri, 7 Dec 2012 09:45:19 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so676926lbk.31 for ; Fri, 07 Dec 2012 09:45:19 -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:content-transfer-encoding; bh=ZWXozhLBhNxIjTt9YNGSu2FLWj/hqL5xacd9RWK4gqw=; b=ezXi2zsy974UAdf4Xg88fPrE62/z65lQzfN6FBRX1dScdwum7S4rRT+JoW15yqj+zq EiWf6xU4hnOQKdvNTPaBlz6BqtwTnsiaXhJP+FGH2M6mgV3GWUhEHW2+kmuX9msZFsz7 EsUA/mBEAasSULrskgBgWVkeRts4RTHY3Q3bWRJ5GZKRxoj5vdH8LyRuXsgmjUbipUc4 6HRLcxkjVQSeI8vrpiGQs7gAFoUsmJOWTSaCNRqDMYth9w4x+vGPairL4fx5lMakwPxV bf8UwJ1fmHjCVtUp+0XPem4t9GxD/G9ULPI74TfbmzxEnYR2mUF6xWPJlRsL1G4IaH/6 fZgg== MIME-Version: 1.0 Received: by 10.112.46.199 with SMTP id x7mr2816396lbm.109.1354902318965; Fri, 07 Dec 2012 09:45:18 -0800 (PST) Received: by 10.112.98.200 with HTTP; Fri, 7 Dec 2012 09:45:18 -0800 (PST) In-Reply-To: <50C18DF0.9010004@omnitor.se> References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> <50BE7738.8090403@omnitor.se> <50BE899A.4020604@matthew.at> <50BF1655.80200@omnitor.se> <50BF4C23.7030108@omnitor.se> <50C18DF0.9010004@omnitor.se> Date: Fri, 7 Dec 2012 09:45:18 -0800 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Dec 2012 17:45:20 -0000 On 6 December 2012 22:34, Gunnar Hellstr=C3=B6m wrote: > Thanks for the hint on Language-tags. Sadly, Accept-Language is a feature that is almost universally ignored. I'm sad to say it, but people trust geo-ip services far more than they trust this particular header. You only need to travel to learn this sad fact. > Is there anything similar for > media-tags. Declaring and detecting "text" media capability or requiremen= t > can be a way to select the proper terminal among a set being reachable > through the same address. Detecting "text" capability would not be necessary in Cullen's proposed scenario. The capability would be provided by the application. From gunnar.hellstrom@omnitor.se Fri Dec 7 12:46:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787B821F89B3 for ; Fri, 7 Dec 2012 12:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4Y23FUn30zc for ; Fri, 7 Dec 2012 12:46:05 -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 28D0721F8980 for ; Fri, 7 Dec 2012 12:46:04 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Fri, 7 Dec 2012 21:45:57 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-09-01.atm.binero.net (Postfix) with ESMTPA id D92C93A11C; Fri, 7 Dec 2012 21:45:56 +0100 (CET) Message-ID: <50C25586.5040408@omnitor.se> Date: Fri, 07 Dec 2012 21:45:58 +0100 From: =?UTF-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Martin Thomson References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> <50BE7738.8090403@omnitor.se> <50BE899A.4020604@matthew.at> <50BF1655.80200@omnitor.se> <50BF4C23.7030108@omnitor.se> <50C18DF0.9010004@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Dec 2012 20:46:06 -0000 On 2012-12-07 18:45, Martin Thomson wrote: > > Is there anything similar for > media-tags. Declaring and detecting "text" media capability or requirement > can be a way to select the proper terminal among a set being reachable > through the same address. > Detecting "text" capability would not be necessary in Cullen's > proposed scenario. The capability would be provided by the > application. Yes, understood. I was thinking about more advanced routing functions etc. Exploring such things can wait, and I know that they are very seldom used. We need to sort out the basic functionality first. Gunnar From fluffy@iii.ca Fri Dec 7 12:57:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AE021F8701 for ; Fri, 7 Dec 2012 12:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNQqIPl3v18Y for ; Fri, 7 Dec 2012 12:57:25 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBDF21F86E2 for ; Fri, 7 Dec 2012 12:57:25 -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 B522C22E257; Fri, 7 Dec 2012 15:57:18 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Cullen Jennings Date: Fri, 7 Dec 2012 13:57:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50C18DF0.9010004@omnitor.se> To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= X-Mailer: Apple Mail (2.1499) Cc: "rtcweb@ietf.org" Subject: [rtcweb] Fwd: Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Dec 2012 20:57:26 -0000 Begin forwarded message: > On 2012-12-07 04:09, Cullen Jennings (fluffy) wrote: >> Gunnar, >>=20 >> I'd be very interested to see someone prototype up a gateway that, on = one side, downloaded some JS to a web browser that created a DataChannel = connection from the browser to the gateway and provide a UI for RTT. On = the other side of the gateway it could do SIP with T.140. My guess is = that someone could get this working and it would help see if things were = missing from the WebRTC API / RTCWeb protocols to be able to do this. I = suspect that items 1,2,3, and 4 are in the control of the gateway so may = not need to be standardized. As to #5, I would hope the SDP in WebRTC = is compatible with SIP offer / answer so I would hope nothing = complicated was need to be specified for #5. As to language tags, the = browser can use the Accept-Languages header in the HTTP. >>=20 >> Cullen > Cullen, > Yes, I think that is a good and realistic challenge, and an activity = that I would like to participate in. > You are also right that for the gateway application it can likely be = done without standardization, when the gateway implementation is also = managing the web page used for the UI. >=20 > The need for standardization comes in for the following cases: > a. When you from the same UI want to have a SIP call at one moment, = and a WebRTC call to another user of another browser and web server at = another moment. >=20 > b. When you want to separate the management and development of the = gateway from the web pages and web servers. >=20 > c. When you want to encourage development of the smartest web page for = RTT communication that can fit into any server environment and have = communication with other web pages used in that or other environments. I think much of this could be covered in a internet draft that said how = to write a gateway from WebRTC RTT over Data Channel to SIP / T.140. It = would be good to have and ID that showed how to do that. That draft = could cover things like how frequently to send data and formatting and = such. It could also covering gatewaying to RTT over XMPP. ( I won't even = mention MSRP :-) From ekr@rtfm.com Sat Dec 8 15:21:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5F121F84B6 for ; Sat, 8 Dec 2012 15:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.73 X-Spam-Level: X-Spam-Status: No, score=-102.73 tagged_above=-999 required=5 tests=[AWL=0.246, 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 AU-RLXbUXI4j for ; Sat, 8 Dec 2012 15:21:48 -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 BABBB21F843D for ; Sat, 8 Dec 2012 15:21:46 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so1603155obc.31 for ; Sat, 08 Dec 2012 15:21:46 -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=s/zS9vfKbLrKUylonva5+6ZiPEpEmYR9fOqNFwL57J8=; b=Gg7fkG0X3LVuNHHslR6pFwEuV3wi3Br9F0O7g+vLKgQZYxrGBalMW/nv4g5JNIWn62 zkygfgLGBtGSGCZxErh/lOgczvJj7p6Ud1pWIyWlNthateaGJPoW4m2buk0YI7/Pr5dd 3ok8P6b+r5g6a8bazkVLeynybTe36bL2BfQO9mkbKRcCZry1I/bf7N3M0J+ggmjUiKnJ TKtpkIN+RVKpepbV7tUIGwu1oa9dRwbLW57azq7Dremz/d2D27QdPOpigkdEnCooPRCr P7jdihI0Ebv5hC5Zk52S5o0CaoYr3nEah+AFljSmUKHnHMfki4oHk3a+05ILjkZ7OxkL Vfbg== Received: by 10.182.52.100 with SMTP id s4mr5232473obo.70.1355008906144; Sat, 08 Dec 2012 15:21:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.59.45 with HTTP; Sat, 8 Dec 2012 15:21:06 -0800 (PST) X-Originating-IP: [74.95.2.174] In-Reply-To: References: From: Eric Rescorla Date: Sat, 8 Dec 2012 15:21:06 -0800 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=14dae939996984aaee04d05f98b6 X-Gm-Message-State: ALoCoQkfJ+fN3nDZOivRQl2qQy06Qtrgr5wUkYfjk4teJfEqLh2h9WwNiuoK7MjlBLgQBMtTWEuV Cc: rtcweb@ietf.org, mmusic WG , public-webrtc@w3.org Subject: Re: [rtcweb] [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Dec 2012 23:21:58 -0000 --14dae939996984aaee04d05f98b6 Content-Type: text/plain; charset=ISO-8859-1 +rtcweb On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) wrote: > > I was looking over everything that needs to be completed to finish a fist > cut of the WebRTC related work. There are a handful of big SDP problems > that are currently blocking some of the WebRTC work and I'd like to figure > out how to make some progress on them. > > Let me loosely characterize them as > > 1) If we have several video streams, how do theses map up to 1 or more m > lines. > > 2) if we are doing port multiplexing, what does the SDP look like (the > bundle problem) > > 3) How do we map the RTCWeb track and stream label concepts to identifiers > in SDP > > 3) SDP for application running over SCTP/DTLS > I don't want to speak for all the various chairs but I am under the > impression that most of chairs of related groups in W3C and IETF believe > these are issues that need to be resolved primarily in the MMUSIC WG and > that they impact both WebRTC and CLUE as well as the general long term use > of SDP in SIP and other protocols. > > I'd like to get some discussion going on how we can make some progress on > these. I don't think we are going to solve these in 20 minutes of > discussion at an IETF meeting so I think we probably need some interim > (virtual or face to face) to sort this out. > > Thoughts? > Wow, I'm totally confused here. I had assumed that the SDP-related issues were going to be the main topics at the WebRTC/RTCWEB interim in January. Is that not the case? IMO the lack of clarity around how to encode various media configurations into SDP is the major thing blocking progress here. In particular, Firefox has opted not to implement multiplexing of media streams over the same transport flow (whether of the bundle or multiple m-line variety) until the SDP for it is well-defined. The same thing applies to the question of how to map multiple m-lines to incoming MediaStreams/Tracks. We really need to cover these issues in the interim. -Ekr --14dae939996984aaee04d05f98b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +rtcweb

On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings = (fluffy) <fluffy@cisco.com> wrote:

I was looking over everything that needs to be completed to finish a fist c= ut of the WebRTC related work. There are a handful of big SDP problems that= are currently blocking some of the WebRTC work and I'd like to figure = out how to make some progress on them.

Let me loosely characterize them as

1) If we have several video streams, how do theses map up to 1 or more m li= nes.

2) if we are doing port multiplexing, what does the SDP look like (the bund= le problem)

3) How do we map the RTCWeb track and stream label concepts to identifiers = in SDP

3) SDP for application running over SCTP/DTLS

I don't want to speak for all the various chairs but I am under the imp= ression that most of chairs of related groups in W3C and IETF believe these= are issues that need to be resolved primarily in the MMUSIC WG and that th= ey impact both WebRTC and CLUE as well as the general long term use of SDP = in SIP and other protocols.

I'd like to get some discussion going on how we can make some progress = on these. I don't think we are going to solve these in 20 minutes of di= scussion at an IETF meeting so I think we probably need some interim (virtu= al or face to face) to sort this out.

Thoughts?

Wow, I&= #39;m totally confused here.

I had assumed that the SDP-related issues were going= to be the main
topics at the WebRTC/RTCWEB interim in January. = Is that not the case?

IMO the lack of clarity around how to encode various media=
configurations into SDP is the major thing block= ing progress here. In
particular, Firefox h= as opted not to implement multiplexing of media
streams over the same transport flow (whether of the bundle or
multiple m-line variety) until the SDP for it is well-d= efined. The
same thing applies to the quest= ion of how to map multiple m-lines to
incoming MediaStreams/Tracks.

We really need to cover = these issues in the interim.

-Ekr


--14dae939996984aaee04d05f98b6-- From martin.thomson@gmail.com Sat Dec 8 15:27:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CEB21F8540; Sat, 8 Dec 2012 15:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.653 X-Spam-Level: X-Spam-Status: No, score=-4.653 tagged_above=-999 required=5 tests=[AWL=-1.054, 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 JYHHFeLV+zGv; Sat, 8 Dec 2012 15:27:52 -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 6318521F8531; Sat, 8 Dec 2012 15:27:51 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so1342777lbk.31 for ; Sat, 08 Dec 2012 15:27:50 -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=m94x4+3KTzJd0a3ODWF4qJxGafW2jHUf7NYIXDUSDf4=; b=TLvDXB0hVgtQegNseZW56IXEXL0Gg5wPIAhH82J2+ayjJrNX2GT711PZuZ1dSjt5AL 6+KBtaKctOOAjUDswoA/9NavTM1hld54RutsDCs9uqQh1VRyo/5YUCSijhmGA6DbAz9C CUzBp6ctDRoyNymLOKsuYs4Pu0/LfnzWAcRUrnY3+0meZRSIA7/YKJdtidHrGaXOdIAj q0qHEDL5BopjZqSG1vPI27Q9OLvm+B3h+tZpNign+SSdg0knd0RxRKW1soszhLoMyiYQ J12xfEIaWoXNe/6FuYZidBUnFeM/i7iaPOlmk6bA2Ks5N/GN97MeLRloqBdJNx6CQvB9 doPw== MIME-Version: 1.0 Received: by 10.112.43.134 with SMTP id w6mr3648814lbl.21.1355009270327; Sat, 08 Dec 2012 15:27:50 -0800 (PST) Received: by 10.112.98.200 with HTTP; Sat, 8 Dec 2012 15:27:50 -0800 (PST) In-Reply-To: References: Date: Sat, 8 Dec 2012 15:27:50 -0800 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , mmusic WG , "public-webrtc@w3.org" Subject: Re: [rtcweb] [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Dec 2012 23:27:52 -0000 On 8 December 2012 15:21, Eric Rescorla wrote: > We really need to cover these issues in the interim. +1. I would have said *resolve* rather than cover, but I'm learning not to be too optimistic in these matters. Still, an outcome of one form or other would be nice. From fluffy@cisco.com Sat Dec 8 16:19:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BF321F8AEA; Sat, 8 Dec 2012 16:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.569 X-Spam-Level: X-Spam-Status: No, score=-110.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 vNrqKDp+gij5; Sat, 8 Dec 2012 16:19:48 -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 2CCC921F8ADF; Sat, 8 Dec 2012 16:19:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2402; q=dns/txt; s=iport; t=1355012388; x=1356221988; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Nc0Laq5KqESAbVg4cXK4ac8TweDr2vrfHs8pN5/NDdM=; b=ehCulsR7xXhp5FqUFV/2CiC71VFsDpCvMqLADjqg3MG+lhC8UBRVBZvJ 48XQX5XToA/TxjS2y9JQEFBP+R1iGEPFAApUGu6X/lVUFx/wBpXrVcW7H 3Dws0RKGsPxsnJZ1EAo2OTQP63ugQytFB0xb/Pl+jO9Sp+a1rLR2l8CjK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAN7Yw1CtJV2c/2dsb2JhbABEvmIWc4IeAQEBAwF5EAIBCA4KCiQyJQIEDgUIiAMGvyyMP4NiYQOIKp4kgnOCIg X-IronPort-AV: E=McAfee;i="5400,1158,6920"; a="150877202" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 09 Dec 2012 00:19:46 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qB90JkUA014590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Dec 2012 00:19:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.91]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Sat, 8 Dec 2012 18:19:46 -0600 From: "Cullen Jennings (fluffy)" To: Eric Rescorla Thread-Topic: [MMUSIC] SDP work needed for WebRTC stuff Thread-Index: AQHN1ZrLc7vRdGyb+kCXOHgISQGSp5gP/yeA Date: Sun, 9 Dec 2012 00:19:46 +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.167] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , mmusic WG , "" Subject: Re: [rtcweb] [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Dec 2012 00:19:49 -0000 On Dec 8, 2012, at 4:21 PM, Eric Rescorla wrote: > +rtcweb >=20 > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) wrote: >=20 > I was looking over everything that needs to be completed to finish a fist= cut of the WebRTC related work. There are a handful of big SDP problems th= at are currently blocking some of the WebRTC work and I'd like to figure ou= t how to make some progress on them. >=20 > Let me loosely characterize them as >=20 > 1) If we have several video streams, how do theses map up to 1 or more m = lines. >=20 > 2) if we are doing port multiplexing, what does the SDP look like (the bu= ndle problem) >=20 > 3) How do we map the RTCWeb track and stream label concepts to identifier= s in SDP >=20 > 3) SDP for application running over SCTP/DTLS >=20 > I don't want to speak for all the various chairs but I am under the impre= ssion that most of chairs of related groups in W3C and IETF believe these a= re issues that need to be resolved primarily in the MMUSIC WG and that they= impact both WebRTC and CLUE as well as the general long term use of SDP in= SIP and other protocols. >=20 > I'd like to get some discussion going on how we can make some progress on= these. I don't think we are going to solve these in 20 minutes of discussi= on at an IETF meeting so I think we probably need some interim (virtual or = face to face) to sort this out. >=20 > Thoughts? >=20 > Wow, I'm totally confused here. >=20 > I had assumed that the SDP-related issues were going to be the main > topics at the WebRTC/RTCWEB interim in January. Is that not the case? So far the interim was only talking about being a WebRTC & RTCWeb so this S= DP stuff would be out of scope. Perhaps it would be better to have some of = the time for mmusic topics?=20 >=20 > IMO the lack of clarity around how to encode various media > configurations into SDP is the major thing blocking progress here. In > particular, Firefox has opted not to implement multiplexing of media > streams over the same transport flow (whether of the bundle or > multiple m-line variety) until the SDP for it is well-defined. The > same thing applies to the question of how to map multiple m-lines to > incoming MediaStreams/Tracks. >=20 > We really need to cover these issues in the interim. >=20 > -Ekr >=20 >=20 From ron.even.tlv@gmail.com Sat Dec 8 23:10:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D62921F8BE5; Sat, 8 Dec 2012 23:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyIn7-BdKjVF; Sat, 8 Dec 2012 23:10:45 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id ACC8C21F8BE1; Sat, 8 Dec 2012 23:10:45 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so1819805oag.31 for ; Sat, 08 Dec 2012 23:10:45 -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=qxohVwu0zYob980fFRcZsiOy+igW1a22KNJmXSYXTDc=; b=QVYtXI1ofAXfYHaiwi4GCd9rjJUgWfqbW+fBaPHDIlpCeXmphD5tuyM4tiG4BKo1d3 0d5aRLLtyq3htWy1E2kCneEBsLcffrKznlAhDKuFYe0j+NT27jAxZ9FvYJ1vOZVvU9tM mEvkNK59NkmK22eIdRWJ8vZtNyfSeSvfWnwMXumTj8aj40OsYIXttZvRD5LjfMkJT8cA 39s/65jrATno2sFKjy1M9vgkxKLFVNBYt5O91y21VV9QPzF93bKO+Qw/Mg1SYWhCVmHW ICzZ85PcUD3bGSe1IwuV96OaFC2tueJSz4/DmrCiofDu4fBW+c9l3qU6j8pfYe4641ZE r8TQ== MIME-Version: 1.0 Received: by 10.182.95.133 with SMTP id dk5mr5908866obb.14.1355037045308; Sat, 08 Dec 2012 23:10:45 -0800 (PST) Received: by 10.76.171.103 with HTTP; Sat, 8 Dec 2012 23:10:45 -0800 (PST) In-Reply-To: References: Date: Sun, 9 Dec 2012 09:10:45 +0200 Message-ID: From: Ron Even To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=14dae93b62a2be3d2d04d0662536 Cc: "" , mmusic WG , "" Subject: Re: [rtcweb] [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Dec 2012 07:10:46 -0000 --14dae93b62a2be3d2d04d0662536 Content-Type: text/plain; charset=ISO-8859-1 Hi Cullen, I agree that we need to put more effort into this work and am willing to be part of it. You mentioned CLUE and we have the mapping of RTP streams to CLUE media captures as a topic, discussed in CLUE. We started some work during the Atlanta meeting and it is supposed to be discussed on the RAI mailing list since it involves multiple RAI WGs but this is just the formality Roni Even On Sunday, December 9, 2012, Cullen Jennings (fluffy) wrote: > > On Dec 8, 2012, at 4:21 PM, Eric Rescorla > > wrote: > > > +rtcweb > > > > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) < > fluffy@cisco.com > wrote: > > > > I was looking over everything that needs to be completed to finish a > fist cut of the WebRTC related work. There are a handful of big SDP > problems that are currently blocking some of the WebRTC work and I'd like > to figure out how to make some progress on them. > > > > Let me loosely characterize them as > > > > 1) If we have several video streams, how do theses map up to 1 or more m > lines. > > > > 2) if we are doing port multiplexing, what does the SDP look like (the > bundle problem) > > > > 3) How do we map the RTCWeb track and stream label concepts to > identifiers in SDP > > > > 3) SDP for application running over SCTP/DTLS > > > > I don't want to speak for all the various chairs but I am under the > impression that most of chairs of related groups in W3C and IETF believe > these are issues that need to be resolved primarily in the MMUSIC WG and > that they impact both WebRTC and CLUE as well as the general long term use > of SDP in SIP and other protocols. > > > > I'd like to get some discussion going on how we can make some progress > on these. I don't think we are going to solve these in 20 minutes of > discussion at an IETF meeting so I think we probably need some interim > (virtual or face to face) to sort this out. > > > > Thoughts? > > > > Wow, I'm totally confused here. > > > > I had assumed that the SDP-related issues were going to be the main > > topics at the WebRTC/RTCWEB interim in January. Is that not the case? > > So far the interim was only talking about being a WebRTC & RTCWeb so this > SDP stuff would be out of scope. Perhaps it would be better to have some of > the time for mmusic topics? > > > > > > IMO the lack of clarity around how to encode various media > > configurations into SDP is the major thing blocking progress here. In > > particular, Firefox has opted not to implement multiplexing of media > > streams over the same transport flow (whether of the bundle or > > multiple m-line variety) until the SDP for it is well-defined. The > > same thing applies to the question of how to map multiple m-lines to > > incoming MediaStreams/Tracks. > > > > We really need to cover these issues in the interim. > > > > -Ekr > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --14dae93b62a2be3d2d04d0662536 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Cullen,
I agree that we need to put more effort into this work and a= m willing to be part of it.
You mentioned CLUE and we have the ma= pping of RTP streams to CLUE media captures as a topic, discussed in CLUE.<= span>
=A0We started some work during the Atlanta meeting and it is supposed = to be discussed on the RAI mailing list since it involves multiple RAI WGs = but this is just the formality
Roni Even

On Sunday, Decemb= er 9, 2012, Cullen Jennings (fluffy) wrote:

On Dec 8, 2012, at 4:21 PM, Eric Rescorla <ekr@rtfm.com&= gt; wrote:

> +rtcweb
>
> On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>
> I was looking over everything that needs to be completed to finish a f= ist cut of the WebRTC related work. There are a handful of big SDP problems= that are currently blocking some of the WebRTC work and I'd like to fi= gure out how to make some progress on them.
>
> Let me loosely characterize them as
>
> 1) If we have several video streams, how do theses map up to 1 or more= m lines.
>
> 2) if we are doing port multiplexing, what does the SDP look like (the= bundle problem)
>
> 3) How do we map the RTCWeb track and stream label concepts to identif= iers in SDP
>
> 3) SDP for application running over SCTP/DTLS
>
> I don't want to speak for all the various chairs but I am under th= e impression that most of chairs of related groups in W3C and IETF believe = these are issues that need to be resolved primarily in the MMUSIC WG and th= at they impact both WebRTC and CLUE as well as the general long term use of= SDP in SIP and other protocols.
>
> I'd like to get some discussion going on how we can make some prog= ress on these. I don't think we are going to solve these in 20 minutes = of discussion at an IETF meeting so I think we probably need some interim (= virtual or face to face) to sort this out.
>
> Thoughts?
>
> Wow, I'm totally confused here.
>
> I had assumed that the SDP-related issues were going to be the main > topics at the WebRTC/RTCWEB interim in January. Is that not the case?<= br>
So far the interim was only talking about being a WebRTC & RTCWeb so th= is SDP stuff would be out of scope. Perhaps it would be better to have some= of the time for mmusic topics?


>
> IMO the lack of clarity around how to encode various media
> configurations into SDP is the major thing blocking progress here. In<= br> > particular, Firefox has opted not to implement multiplexing of media > streams over the same transport flow (whether of the bundle or
> multiple m-line variety) until the SDP for it is well-defined. The
> same thing applies to the question of how to map multiple m-lines to > incoming MediaStreams/Tracks.
>
> We really need to cover these issues in the interim.
>
> -Ekr
>
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic
--14dae93b62a2be3d2d04d0662536-- From dom@w3.org Mon Dec 10 00:35:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FFB21F87A6 for ; Mon, 10 Dec 2012 00:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.74 X-Spam-Level: X-Spam-Status: No, score=-8.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 ccoW64Mi4b5d for ; Mon, 10 Dec 2012 00:35:27 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 75E5421F8754 for ; Mon, 10 Dec 2012 00:35:26 -0800 (PST) Received: from oll83-2-88-120-37-14.fbx.proxad.net ([88.120.37.14] helo=[192.168.0.9]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Thypf-0004YR-01; Mon, 10 Dec 2012 03:35:23 -0500 Message-ID: <1355128515.13667.3.camel@cumulustier> From: Dominique Hazael-Massieux To: Stefan Hakansson LK Date: Mon, 10 Dec 2012 09:35:15 +0100 In-Reply-To: <50BDA3D3.2090707@ericsson.com> References: <50BCFDB3.4010205@nostrum.com> <50BDA3D3.2090707@ericsson.com> Organization: W3C Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.0-0ubuntu3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Dec 2012 08:35:28 -0000 Le mardi 04 décembre 2012 à 08:18 +0100, Stefan Hakansson LK a écrit : > AFAIK, that is correct. You don't make any IPR commitments as observer > (and, after all, you're just observing); that is something that is done > if and when joining the WG. Indeed, simply observing a W3C WG meeting doesn't induce any IPR commitment. Dom From keith.drage@alcatel-lucent.com Mon Dec 10 05:16:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6B821F8D23; Mon, 10 Dec 2012 05:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.116 X-Spam-Level: X-Spam-Status: No, score=-110.116 tagged_above=-999 required=5 tests=[AWL=0.133, 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 9L-mWsUbBy37; Mon, 10 Dec 2012 05:16:42 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id CCDCE21F8E92; Mon, 10 Dec 2012 05:16:41 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBADCWWx013741 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 10 Dec 2012 14:16:34 +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; Mon, 10 Dec 2012 14:16:27 +0100 From: "DRAGE, Keith (Keith)" To: "Cullen Jennings (fluffy)" , Eric Rescorla Date: Mon, 10 Dec 2012 14:16:27 +0100 Thread-Topic: [MMUSIC] SDP work needed for WebRTC stuff Thread-Index: AQHN1ZrLc7vRdGyb+kCXOHgISQGSp5gP/yeAgAIFimA= Message-ID: References: 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.80 Cc: "" , mmusic WG , "" Subject: Re: [rtcweb] [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Dec 2012 13:16:42 -0000 This is not just MMUSIC, there are bits of AVTCORE and AVTEXT responsibilit= y in there as well. And I don't see how you can suddenly extend the interim of RTCWEB to the sc= ope of other working groups, without even having a discussion with all the = relevant chairs. I'd further note that Jonathan Lennox has an action (with the support of qu= ite a number of other people) to produce an internet draft on trying to sor= t out the terminology concents that exist within RTP at the moment. This wo= uld be the basis for progressing a number of these issues. That would proba= bly have to be an RAI wide draft. There has been some progress on this - maybe Jonathan can report on where t= his now is. I know he was waiting on volunteers for some of the sections an= d on input from others where volunteers already existed. Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Cullen Jennings (fluffy) > Sent: 09 December 2012 00:20 > To: Eric Rescorla > Cc: ; mmusic WG; > Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff >=20 >=20 > On Dec 8, 2012, at 4:21 PM, Eric Rescorla wrote: >=20 > > +rtcweb > > > > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) > wrote: > > > > I was looking over everything that needs to be completed to finish a > fist cut of the WebRTC related work. There are a handful of big SDP > problems that are currently blocking some of the WebRTC work and I'd like > to figure out how to make some progress on them. > > > > Let me loosely characterize them as > > > > 1) If we have several video streams, how do theses map up to 1 or more = m > lines. > > > > 2) if we are doing port multiplexing, what does the SDP look like (the > bundle problem) > > > > 3) How do we map the RTCWeb track and stream label concepts to > identifiers in SDP > > > > 3) SDP for application running over SCTP/DTLS > > > > I don't want to speak for all the various chairs but I am under the > impression that most of chairs of related groups in W3C and IETF believe > these are issues that need to be resolved primarily in the MMUSIC WG and > that they impact both WebRTC and CLUE as well as the general long term us= e > of SDP in SIP and other protocols. > > > > I'd like to get some discussion going on how we can make some progress > on these. I don't think we are going to solve these in 20 minutes of > discussion at an IETF meeting so I think we probably need some interim > (virtual or face to face) to sort this out. > > > > Thoughts? > > > > Wow, I'm totally confused here. > > > > I had assumed that the SDP-related issues were going to be the main > > topics at the WebRTC/RTCWEB interim in January. Is that not the case? >=20 > So far the interim was only talking about being a WebRTC & RTCWeb so this > SDP stuff would be out of scope. Perhaps it would be better to have some > of the time for mmusic topics? >=20 >=20 > > > > IMO the lack of clarity around how to encode various media > > configurations into SDP is the major thing blocking progress here. In > > particular, Firefox has opted not to implement multiplexing of media > > streams over the same transport flow (whether of the bundle or > > multiple m-line variety) until the SDP for it is well-defined. The > > same thing applies to the question of how to map multiple m-lines to > > incoming MediaStreams/Tracks. > > > > We really need to cover these issues in the interim. > > > > -Ekr > > > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From andrew.hutton@siemens-enterprise.com Mon Dec 10 07:32:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755E621F8503 for ; Mon, 10 Dec 2012 07:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fY7N3+AmzHM1 for ; Mon, 10 Dec 2012 07:32:09 -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 5F9CB21F84FA for ; Mon, 10 Dec 2012 07:32:09 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 36CCA23F069D; Mon, 10 Dec 2012 16:32:08 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.13]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Mon, 10 Dec 2012 16:32:08 +0100 From: "Hutton, Andrew" To: Christer Holmberg , Andrew Allen , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC Thread-Index: AQHN0Yyg7J5CAj+0BkmvdUV+2PsC45gHbC4AgAAFtwCAAA1uAIAAu5kAgAn4VAA= Date: Mon, 10 Dec 2012 15:32:05 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0138A052@MCHP04MSX.global-ad.net> References: <50BCFDB3.4010205@nostrum.com> <7594FB04B1934943A5C02806D1A2204B04DD7F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B04DD7F@ESESSMB209.ericsson.se> 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] Upcoming Interim meeting, co-located with WEBRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Dec 2012 15:32:10 -0000 Hi, There was also a previous message to the list indicating that the interim w= ould focus on the issue of support for additional key management methods (E= .g. SDES). See http://www.ietf.org/mail-archive/web/rtcweb/current/msg05369= .html.=20 Some clarification on the agenda is needed. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: 04 December 2012 08:15 > To: Andrew Allen; rtcweb@ietf.org > Subject: Re: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC >=20 > Hi Andrew, >=20 > It was earlier indicated that the main focus will be on JSEP and SDP. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Andrew Allen > Sent: 3. joulukuuta 2012 23:03 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Upcoming Interim meeting, co-located with WEBRTC >=20 >=20 > I think for interim meetings it would be very helpful to have the > agenda out as far in advance as possible in order to help justify the > expense of travelling for what looks like maybe a day and a half > meeting for at least some from the IETF side. >=20 > It was made clear in Atlanta that the video codec MTI issue will not be > discussed but what is planned to be? >=20 > RTCweb has many active drafts encompassing a broad range of topics so > it would be very useful to know before committing to travel if the > issues you have interest in are likely to be discussed otherwise it may > end up as 3 days of thumb twiddling at considerable expense for some > and potentially jeopardize the likelihood of them obtaining travel > authorization for future meetings. >=20 > Andrew >=20 > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of Ted Hardie > > Sent: Monday, December 03, 2012 2:15 PM > > To: Stephan Wenger > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] Upcoming Interim meeting, co-located with > WEBRTC > > > > On Mon, Dec 3, 2012 at 11:54 AM, Stephan Wenger > wrote: > > > I'm not Mary, but I observe that W3C "Invited Experts" are as the > > > very minimum subject to the disclosure part of W3Cs patent policy > > > (section > > 6.10 > > > of http://www.w3.org/Consortium/Patent-Policy-20040205/). > > > > I think there is a difference between "invited expert" and "observer" > > in the W3C rules, but I will leave it the W3C chairs to elaborate. > > Harald, Stefan, have I got that right? > > > > Ted > > _______________________________________________ > > 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 andrew.hutton@siemens-enterprise.com Mon Dec 10 08:34:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951EC21F8523 for ; Mon, 10 Dec 2012 08:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 PQ6TZieeCDAv for ; Mon, 10 Dec 2012 08:34:39 -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 A81C621F84FC for ; Mon, 10 Dec 2012 08:34:39 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 139E423F0509; Mon, 10 Dec 2012 17:34:39 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.13]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Mon, 10 Dec 2012 17:34:38 +0100 From: "Hutton, Andrew" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Review of draft-ietf-rtcweb-jsep-02 Thread-Index: AQHNyWeSfxD4hMONF0S4kk+jH1+LwZgSTojw Date: Mon, 10 Dec 2012 16:34:35 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0138A208@MCHP04MSX.global-ad.net> References: <50AF5398.1040309@alvestrand.no> In-Reply-To: <50AF5398.1040309@alvestrand.no> 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] Review of draft-ietf-rtcweb-jsep-02 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Dec 2012 16:34:40 -0000 On 23 November 2012 10:45 Harald Alvestrand Wrote > I think we're close to where we need to be on this doc. But still some > work to be done. > Nits will be sent to the authors - I thought I'd raise some bigger > issues here. >=20 > First is the positioning of this draft. >=20 > I believe that the draft should reference the W3C API document and say > "that one is the authoritative reference for what the API looks like; > this document shows how the calls from that API are actually affecting > the media configuration and media bits on the wire". > This is important enough that it needs to be clear from the abstract > and > from the intro. >=20 I agree that it should state the W3C API Spec is the authoritative referenc= e but does that mean that the W3C API has to clearly define the SDP Usage a= nd that questions about SDP usage should be directed at the W3C mailing lis= t, I assume not.=20 I previously sent some comments on jsep-02 which were kindly placed in the = tracker (See http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/3#) some of w= hich refer to how the API generates/uses SDP. I am not sure now how these w= ill be addressed. For example take comment 11 which relates to what SDP is generated by calli= ng createOffer in an established dialog. Is this something that will be eve= ntually described in the W3C API or will the W3C API also reference an IETF= document which details the SDP usage (i.e. JSEP)? Regards Andy From ted.ietf@gmail.com Mon Dec 10 09:36:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C4621F857C; Mon, 10 Dec 2012 09:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.170, 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 fjH-XKqeZ24N; Mon, 10 Dec 2012 09:36:28 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 89E9F21F856D; Mon, 10 Dec 2012 09:36:28 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so3018030vcb.31 for ; Mon, 10 Dec 2012 09:36:28 -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=Foi2RanzwiqbE5WYY2GLyDI0tPPDtH5H9TNrQoRLccY=; b=yqa4qZAWc6Ad7bSYFMVqrgX0Cr3KqcNk6smYVtKsXxK7umlUIP8a5qtuia5lfQbKfT 3UOOozUW1mGE5LXmwx96DOllwdB6zhsFYl8ROMztRDUrLCyaXJG/GTdLdUMOBXzL/fO+ CA815yCQ9jFazdK+S5OV31Euyzkb5QeDGV+qFcbiYkfFuBhlr/X6O772zWuAAlttamfW Epxn6xaRCC5BkThdH1RmXtOtyU4WTF+4EZYYYAc0n+H6aGeR46D3rU+f9pVHiKjqcKSN 4a3u3WbYmngdOSkSxH+PzKW00smtb6uABGc2uu06iQNZwmTmEW36Q+g5JUfPB5pjuRcL +CNg== MIME-Version: 1.0 Received: by 10.52.36.167 with SMTP id r7mr8190625vdj.108.1355160987960; Mon, 10 Dec 2012 09:36:27 -0800 (PST) Received: by 10.58.164.35 with HTTP; Mon, 10 Dec 2012 09:36:27 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Dec 2012 09:36:27 -0800 Message-ID: From: Ted Hardie To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=20cf30780ca44d069a04d08301c7 Cc: "Cullen Jennings \(fluffy\)" , "" , mmusic WG , "" Subject: Re: [rtcweb] [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Dec 2012 17:36:30 -0000 --20cf30780ca44d069a04d08301c7 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 10, 2012 at 5:16 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > This is not just MMUSIC, there are bits of AVTCORE and AVTEXT > responsibility in there as well. > > And I don't see how you can suddenly extend the interim of RTCWEB to the > scope of other working groups, without even having a discussion with all > the relevant chairs. > > That's not how I read the overall sentiment--people are simply saying that they need this work done and are willing to put in the effort to get it done. It would, in fact, be ideal if some of the MMUSIC questions were resolve *before* an RTCWEB/WEBRTC interim, as we can then work through what is decided. Put another way, I take it as encouragement to MMUSIC folks that they would find a January virtual interim very well received/attended. Ted > I'd further note that Jonathan Lennox has an action (with the support of > quite a number of other people) to produce an internet draft on trying to > sort out the terminology concents that exist within RTP at the moment. This > would be the basis for progressing a number of these issues. That would > probably have to be an RAI wide draft. > > There has been some progress on this - maybe Jonathan can report on where > this now is. I know he was waiting on volunteers for some of the sections > and on input from others where volunteers already existed. > > Keith > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > > Of Cullen Jennings (fluffy) > > Sent: 09 December 2012 00:20 > > To: Eric Rescorla > > Cc: ; mmusic WG; > > Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff > > > > > > On Dec 8, 2012, at 4:21 PM, Eric Rescorla wrote: > > > > > +rtcweb > > > > > > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) > > wrote: > > > > > > I was looking over everything that needs to be completed to finish a > > fist cut of the WebRTC related work. There are a handful of big SDP > > problems that are currently blocking some of the WebRTC work and I'd like > > to figure out how to make some progress on them. > > > > > > Let me loosely characterize them as > > > > > > 1) If we have several video streams, how do theses map up to 1 or more > m > > lines. > > > > > > 2) if we are doing port multiplexing, what does the SDP look like (the > > bundle problem) > > > > > > 3) How do we map the RTCWeb track and stream label concepts to > > identifiers in SDP > > > > > > 3) SDP for application running over SCTP/DTLS > > > > > > I don't want to speak for all the various chairs but I am under the > > impression that most of chairs of related groups in W3C and IETF believe > > these are issues that need to be resolved primarily in the MMUSIC WG and > > that they impact both WebRTC and CLUE as well as the general long term > use > > of SDP in SIP and other protocols. > > > > > > I'd like to get some discussion going on how we can make some progress > > on these. I don't think we are going to solve these in 20 minutes of > > discussion at an IETF meeting so I think we probably need some interim > > (virtual or face to face) to sort this out. > > > > > > Thoughts? > > > > > > Wow, I'm totally confused here. > > > > > > I had assumed that the SDP-related issues were going to be the main > > > topics at the WebRTC/RTCWEB interim in January. Is that not the case? > > > > So far the interim was only talking about being a WebRTC & RTCWeb so this > > SDP stuff would be out of scope. Perhaps it would be better to have some > > of the time for mmusic topics? > > > > > > > > > > IMO the lack of clarity around how to encode various media > > > configurations into SDP is the major thing blocking progress here. In > > > particular, Firefox has opted not to implement multiplexing of media > > > streams over the same transport flow (whether of the bundle or > > > multiple m-line variety) until the SDP for it is well-defined. The > > > same thing applies to the question of how to map multiple m-lines to > > > incoming MediaStreams/Tracks. > > > > > > We really need to cover these issues in the interim. > > > > > > -Ekr > > > > > > > > > > _______________________________________________ > > 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 > --20cf30780ca44d069a04d08301c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Dec 10, 2012 at 5:16 AM, DRAGE, Keith (Keith) <= ;keith.= drage@alcatel-lucent.com> wrote:
This is not just MMUSIC, there are bits of AVTCORE and AVTEXT responsibilit= y in there as well.

And I don't see how you can suddenly extend the interim of RTCWEB to th= e scope of other working groups, without even having a discussion with all = the relevant chairs.


That's not how I read the overall sentiment--= people are simply saying that they need this work done and are willing to p= ut in the effort to get it done.=A0 It would, in fact, be ideal if some of = the MMUSIC questions were resolve *before* an RTCWEB/WEBRTC interim, as we = can then work through what is decided.

Put another way, I take it as encouragement to MMUSIC folks that they w= ould find a January virtual interim very well received/attended.

Ted=

=A0
I'd further note that Jonathan Lennox has an action (with the support o= f quite a number of other people) to produce an internet draft on trying to= sort out the terminology concents that exist within RTP at the moment. Thi= s would be the basis for progressing a number of these issues. That would p= robably have to be an RAI wide draft.

There has been some progress on this - maybe Jonathan can report on where t= his now is. I know he was waiting on volunteers for some of the sections an= d on input from others where volunteers already existed.

Keith

> -----Original Message-----
> From: mmusic-bounces@ietf.o= rg [mailto:mmusic-bounces@ie= tf.org] On Behalf
> Of Cullen Jennings (fluffy)
> Sent: 09 December 2012 00:20
> To: Eric Rescorla
> Cc: <rtcweb@ietf.org>; mm= usic WG; <public-webrtc@w3.org>
> Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff
>
>
> On Dec 8, 2012, at 4:21 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> > +rtcweb
> >
> > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy)
> <fluffy@cisco.com> wrote= :
> >
> > I was looking over everything that needs to be completed to finis= h a
> fist cut of the WebRTC related work. There are a handful of big SDP > problems that are currently blocking some of the WebRTC work and I'= ;d like
> to figure out how to make some progress on them.
> >
> > Let me loosely characterize them as
> >
> > 1) If we have several video streams, how do theses map up to 1 or= more m
> lines.
> >
> > 2) if we are doing port multiplexing, what does the SDP look like= (the
> bundle problem)
> >
> > 3) How do we map the RTCWeb track and stream label concepts to > identifiers in SDP
> >
> > 3) SDP for application running over SCTP/DTLS
> >
> > I don't want to speak for all the various chairs but I am und= er the
> impression that most of chairs of related groups in W3C and IETF belie= ve
> these are issues that need to be resolved primarily in the MMUSIC WG a= nd
> that they impact both WebRTC and CLUE as well as the general long term= use
> of SDP in SIP and other protocols.
> >
> > I'd like to get some discussion going on how we can make some= progress
> on these. I don't think we are going to solve these in 20 minutes = of
> discussion at an IETF meeting so I think we probably need some interim=
> (virtual or face to face) to sort this out.
> >
> > Thoughts?
> >
> > Wow, I'm totally confused here.
> >
> > I had assumed that the SDP-related issues were going to be the ma= in
> > topics at the WebRTC/RTCWEB interim in January. Is that not the c= ase?
>
> So far the interim was only talking about being a WebRTC & RTCWeb = so this
> SDP stuff would be out of scope. Perhaps it would be better to have so= me
> of the time for mmusic topics?
>
>
> >
> > IMO the lack of clarity around how to encode various media
> > configurations into SDP is the major thing blocking progress here= . In
> > particular, Firefox has opted not to implement multiplexing of me= dia
> > streams over the same transport flow (whether of the bundle or > > multiple m-line variety) until the SDP for it is well-defined. Th= e
> > same thing applies to the question of how to map multiple m-lines= to
> > incoming MediaStreams/Tracks.
> >
> > We really need to cover these issues in the interim.
> >
> > -Ekr
> >
> >
>
> _______________________________________________
> 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

--20cf30780ca44d069a04d08301c7-- From harald@alvestrand.no Mon Dec 10 10:17:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D1F21F8519 for ; Mon, 10 Dec 2012 10:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.458 X-Spam-Level: X-Spam-Status: No, score=-110.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 FQV5TZrkWN6N for ; Mon, 10 Dec 2012 10:17:23 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 454C121F84F6 for ; Mon, 10 Dec 2012 10:17:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0416039E13F; Mon, 10 Dec 2012 19:17:22 +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 b4nEyag7oTgV; Mon, 10 Dec 2012 19:17:20 +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 F269A39E01E; Mon, 10 Dec 2012 19:17:15 +0100 (CET) Message-ID: <50C62728.8070607@alvestrand.no> Date: Mon, 10 Dec 2012 19:17:12 +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: "Hutton, Andrew" References: <50AF5398.1040309@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF0138A208@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0138A208@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-02 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Dec 2012 18:17:24 -0000 On 12/10/2012 05:34 PM, Hutton, Andrew wrote: > On 23 November 2012 10:45 Harald Alvestrand Wrote > >> I think we're close to where we need to be on this doc. But still some >> work to be done. >> Nits will be sent to the authors - I thought I'd raise some bigger >> issues here. >> >> First is the positioning of this draft. >> >> I believe that the draft should reference the W3C API document and say >> "that one is the authoritative reference for what the API looks like; >> this document shows how the calls from that API are actually affecting >> the media configuration and media bits on the wire". >> This is important enough that it needs to be clear from the abstract >> and >> from the intro. >> > I agree that it should state the W3C API Spec is the authoritative reference but does that mean that the W3C API has to clearly define the SDP Usage and that questions about SDP usage should be directed at the W3C mailing list, I assume not. > > I previously sent some comments on jsep-02 which were kindly placed in the tracker (See http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/3#) some of which refer to how the API generates/uses SDP. I am not sure now how these will be addressed. > > For example take comment 11 which relates to what SDP is generated by calling createOffer in an established dialog. Is this something that will be eventually described in the W3C API or will the W3C API also reference an IETF document which details the SDP usage (i.e. JSEP)? I believe the JSEP draft needs to position itself as authoritative for what SDP gets generated and parsed, how ICE is started, stopped and changed, and how RTP is configured. The W3C API spec is authoritative for what the Javascript API calls mean. Making sure they stay consistent .... well, that's why they have overlapping editor sets. > > Regards > Andy > From fluffy@iii.ca Mon Dec 10 11:29:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC8B21F84B9; Mon, 10 Dec 2012 11:29:02 -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 VUTWoriF6D3h; Mon, 10 Dec 2012 11:29:01 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id B7BAF21F84B5; Mon, 10 Dec 2012 11:29:01 -0800 (PST) Received: from dhcp-171-68-20-206.cisco.com (unknown [171.68.20.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B5F5522E253; Mon, 10 Dec 2012 14:28:54 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Cullen Jennings In-Reply-To: Date: Mon, 10 Dec 2012 11:31:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <410943E1-0F5F-4A7E-B7C1-4E418E6C4E48@iii.ca> References: To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1499) Cc: "Cullen Jennings \(fluffy\)" , "" , mmusic WG , "" Subject: Re: [rtcweb] [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Dec 2012 19:29:02 -0000 On Dec 10, 2012, at 5:16 , "DRAGE, Keith (Keith)" = wrote: > This is not just MMUSIC, there are bits of AVTCORE and AVTEXT = responsibility in there as well. can you add a bit on what is needed in these WG just so I can keep track = of it all >=20 > And I don't see how you can suddenly extend the interim of RTCWEB to = the scope of other working groups, without even having a discussion with = all the relevant chairs. I did not mean to do any such thing - obviously the MMUSIC WG would need = to decide what to how it was going to do the work. All I was trying to = say is there are some things that I think needs to be done in MMUSIC and = I view it as out of scope for rtcweb. This clearly came as a surprise to = some people who thought that was the main thing the interim meeting was = going to be about. As an individual contributor for to the MMUSIC wg, I = think that mmusic needs to figure out a substantial block of face to = face time to sort out these SDP issues. I look forward to proposals on = how to do that.=20 From ekr@rtfm.com Mon Dec 10 17:19:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF3E21F8717 for ; Mon, 10 Dec 2012 17:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.836 X-Spam-Level: X-Spam-Status: No, score=-102.836 tagged_above=-999 required=5 tests=[AWL=0.140, 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 sfSbZnOmRhNT for ; Mon, 10 Dec 2012 17:18:58 -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 B4D3921F86DA for ; Mon, 10 Dec 2012 17:18:58 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so3300952obc.31 for ; Mon, 10 Dec 2012 17:18:58 -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=Jz93l6XxDHlhAAovN4Rf7KRozbwkq6pgqhkhezfmZGc=; b=Z5GniIE78Nl899/I6J/clApmD+zsF/jjMu+ePHPRAmdr4Car1TE8OKD/+KoHu84BL7 ZUXg0JbN26KbMlvLXzg0G8IPkbQ0lo0r8btifU8zEIFAdIA+yPrnbSvsWyBrspDHbxyl rS6EKSGJGdb6nF4ilPWkEvrcfImL3aPmNdW652J0eXqc9ipZAmVgGklph/QV8kGTtJ1f I8AJubvs25CZ5HwakLHCMiNx8/GK45flt7M7y7VXyUxWUKtI8TMR6afblngpdCNG0+F/ DbZ5Xen6wNz0otd3lTK14gttOVplsXXx9tMe2LYwWavzYMpGMBix3DOTYUIDZkhJBC4V aUbQ== Received: by 10.182.164.103 with SMTP id yp7mr8383725obb.74.1355188738242; Mon, 10 Dec 2012 17:18:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.59.45 with HTTP; Mon, 10 Dec 2012 17:18:17 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Mon, 10 Dec 2012 17:18:17 -0800 Message-ID: To: Ted Hardie Content-Type: multipart/alternative; boundary=e89a8f64355658ba5404d0897766 X-Gm-Message-State: ALoCoQl7zSg34Lvb0SrarKUnIL6rtY3fA5C8Y8wDa1lAvDoP6TLJDY7vkXD9bCoclN1W+oaE6v9t Cc: "Cullen Jennings \(fluffy\)" , "" , mmusic WG , "" Subject: Re: [rtcweb] [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Dec 2012 01:19:00 -0000 --e89a8f64355658ba5404d0897766 Content-Type: text/plain; charset=ISO-8859-1 I feel like the priorities here are kind of confused. It seems to me that the purpose of having a physical interim is to resolve issues that are hard to resolve on the list or teleconferences. As I mentioned earlier, the SDP issues are the most important to resolve now and have also proven to be among the most intractable. How does it make sense to try to resolve those at a "virtual" interim while having people fly to a "physical" interim for three days? I would strongly encourage the chairs to figure out how to have at least one of the days of this interim devoted solely to resolving the SDP issues (really, my preference would be to take these issues one at a time and do nothing else until they are resolved!). I'm not expert enough at the RAI WG mechanics to know what's required, so perhaps this requires making this also an MMUSIC interim or a mini-RAI interim, but if so that's what we should do, even if it means we need to reschedule or move it. Best, -Ekr On Mon, Dec 10, 2012 at 9:36 AM, Ted Hardie wrote: > On Mon, Dec 10, 2012 at 5:16 AM, DRAGE, Keith (Keith) < > keith.drage@alcatel-lucent.com> wrote: > >> This is not just MMUSIC, there are bits of AVTCORE and AVTEXT >> responsibility in there as well. >> >> And I don't see how you can suddenly extend the interim of RTCWEB to the >> scope of other working groups, without even having a discussion with all >> the relevant chairs. >> >> > That's not how I read the overall sentiment--people are simply saying that > they need this work done and are willing to put in the effort to get it > done. It would, in fact, be ideal if some of the MMUSIC questions were > resolve *before* an RTCWEB/WEBRTC interim, as we can then work through what > is decided. > > Put another way, I take it as encouragement to MMUSIC folks that they > would find a January virtual interim very well received/attended. > > Ted > > > >> I'd further note that Jonathan Lennox has an action (with the support of >> quite a number of other people) to produce an internet draft on trying to >> sort out the terminology concents that exist within RTP at the moment. This >> would be the basis for progressing a number of these issues. That would >> probably have to be an RAI wide draft. >> >> There has been some progress on this - maybe Jonathan can report on where >> this now is. I know he was waiting on volunteers for some of the sections >> and on input from others where volunteers already existed. >> >> Keith >> >> > -----Original Message----- >> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf >> > Of Cullen Jennings (fluffy) >> > Sent: 09 December 2012 00:20 >> > To: Eric Rescorla >> > Cc: ; mmusic WG; >> > Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff >> > >> > >> > On Dec 8, 2012, at 4:21 PM, Eric Rescorla wrote: >> > >> > > +rtcweb >> > > >> > > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) >> > wrote: >> > > >> > > I was looking over everything that needs to be completed to finish a >> > fist cut of the WebRTC related work. There are a handful of big SDP >> > problems that are currently blocking some of the WebRTC work and I'd >> like >> > to figure out how to make some progress on them. >> > > >> > > Let me loosely characterize them as >> > > >> > > 1) If we have several video streams, how do theses map up to 1 or >> more m >> > lines. >> > > >> > > 2) if we are doing port multiplexing, what does the SDP look like (the >> > bundle problem) >> > > >> > > 3) How do we map the RTCWeb track and stream label concepts to >> > identifiers in SDP >> > > >> > > 3) SDP for application running over SCTP/DTLS >> > > >> > > I don't want to speak for all the various chairs but I am under the >> > impression that most of chairs of related groups in W3C and IETF believe >> > these are issues that need to be resolved primarily in the MMUSIC WG and >> > that they impact both WebRTC and CLUE as well as the general long term >> use >> > of SDP in SIP and other protocols. >> > > >> > > I'd like to get some discussion going on how we can make some progress >> > on these. I don't think we are going to solve these in 20 minutes of >> > discussion at an IETF meeting so I think we probably need some interim >> > (virtual or face to face) to sort this out. >> > > >> > > Thoughts? >> > > >> > > Wow, I'm totally confused here. >> > > >> > > I had assumed that the SDP-related issues were going to be the main >> > > topics at the WebRTC/RTCWEB interim in January. Is that not the case? >> > >> > So far the interim was only talking about being a WebRTC & RTCWeb so >> this >> > SDP stuff would be out of scope. Perhaps it would be better to have some >> > of the time for mmusic topics? >> > >> > >> > > >> > > IMO the lack of clarity around how to encode various media >> > > configurations into SDP is the major thing blocking progress here. In >> > > particular, Firefox has opted not to implement multiplexing of media >> > > streams over the same transport flow (whether of the bundle or >> > > multiple m-line variety) until the SDP for it is well-defined. The >> > > same thing applies to the question of how to map multiple m-lines to >> > > incoming MediaStreams/Tracks. >> > > >> > > We really need to cover these issues in the interim. >> > > >> > > -Ekr >> > > >> > > >> > >> > _______________________________________________ >> > 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 >> > > --e89a8f64355658ba5404d0897766 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I feel like the priorities here are kind of confused.

It= seems to me that the purpose of having a physical interim is to resolve
issues that are hard to resolve on the list or teleconferences. As = I mentioned
earlier, the SDP issues are the most important to resolve now and have=
also proven to be among the most intractable. How does it make s= ense
to try to resolve those at a "virtual" interim whi= le having people fly
to a "physical" interim for three days?

=
I would strongly encourage the chairs to figure out how to have at lea= st
one of the days of this interim devoted solely to resolving th= e SDP=A0
issues (really, my preference would be to take these issues one at
a time and do nothing else until they are resolved!). I'm not ex= pert
enough at the RAI WG mechanics to know what's required, = so perhaps
this requires making this also an MMUSIC interim or a mini-RAI interim= ,
but if so that's what we should do, even if it means we nee= d to reschedule
or move it.

Best,
-Ekr

On Mon, Dec 1= 0, 2012 at 9:36 AM, Ted Hardie <ted.ietf@gmail.com> wrote:<= br>
On Mon, Dec 10, 2012 at 5:16 AM, DRAGE, Keith (Keith) <k= eith.drage@alcatel-lucent.com> wrote:
This is not just MMUSIC, there are bits of AVTCORE and AVTEXT responsibilit= y in there as well.

And I don't see how you can suddenly extend the interim of RTCWEB to th= e scope of other working groups, without even having a discussion with all = the relevant chairs.


That's not how I read the overall senti= ment--people are simply saying that they need this work done and are willin= g to put in the effort to get it done.=A0 It would, in fact, be ideal if so= me of the MMUSIC questions were resolve *before* an RTCWEB/WEBRTC interim, = as we can then work through what is decided.

Put another way, I take it as encouragement to MMUSIC folks that they w= ould find a January virtual interim very well received/attended.

Ted

=A0
I'd further note that Jonathan Lennox has an action (with the support o= f quite a number of other people) to produce an internet draft on trying to= sort out the terminology concents that exist within RTP at the moment. Thi= s would be the basis for progressing a number of these issues. That would p= robably have to be an RAI wide draft.

There has been some progress on this - maybe Jonathan can report on where t= his now is. I know he was waiting on volunteers for some of the sections an= d on input from others where volunteers already existed.

Keith

> -----Original Message-----
> From: mmu= sic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Cullen Jennings (fluffy)
> Sent: 09 December 2012 00:20
> To: Eric Rescorla
> Cc: <rtcweb@ie= tf.org>; mmusic WG; <public-webrtc@w3.org>
> Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff
>
>
> On Dec 8, 2012, at 4:21 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> > +rtcweb
> >
> > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy)
> <fluffy@cisco= .com> wrote:
> >
> > I was looking over everything that needs to be completed to finis= h a
> fist cut of the WebRTC related work. There are a handful of big SDP > problems that are currently blocking some of the WebRTC work and I'= ;d like
> to figure out how to make some progress on them.
> >
> > Let me loosely characterize them as
> >
> > 1) If we have several video streams, how do theses map up to 1 or= more m
> lines.
> >
> > 2) if we are doing port multiplexing, what does the SDP look like= (the
> bundle problem)
> >
> > 3) How do we map the RTCWeb track and stream label concepts to > identifiers in SDP
> >
> > 3) SDP for application running over SCTP/DTLS
> >
> > I don't want to speak for all the various chairs but I am und= er the
> impression that most of chairs of related groups in W3C and IETF belie= ve
> these are issues that need to be resolved primarily in the MMUSIC WG a= nd
> that they impact both WebRTC and CLUE as well as the general long term= use
> of SDP in SIP and other protocols.
> >
> > I'd like to get some discussion going on how we can make some= progress
> on these. I don't think we are going to solve these in 20 minutes = of
> discussion at an IETF meeting so I think we probably need some interim=
> (virtual or face to face) to sort this out.
> >
> > Thoughts?
> >
> > Wow, I'm totally confused here.
> >
> > I had assumed that the SDP-related issues were going to be the ma= in
> > topics at the WebRTC/RTCWEB interim in January. Is that not the c= ase?
>
> So far the interim was only talking about being a WebRTC & RTCWeb = so this
> SDP stuff would be out of scope. Perhaps it would be better to have so= me
> of the time for mmusic topics?
>
>
> >
> > IMO the lack of clarity around how to encode various media
> > configurations into SDP is the major thing blocking progress here= . In
> > particular, Firefox has opted not to implement multiplexing of me= dia
> > streams over the same transport flow (whether of the bundle or > > multiple m-line variety) until the SDP for it is well-defined. Th= e
> > same thing applies to the question of how to map multiple m-lines= to
> > incoming MediaStreams/Tracks.
> >
> > We really need to cover these issues in the interim.
> >
> > -Ekr
> >
> >
>
> _______________________________________________
> 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


--e89a8f64355658ba5404d0897766-- From martin.thomson@gmail.com Mon Dec 10 17:29:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDE121F8713; Mon, 10 Dec 2012 17:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.745 X-Spam-Level: X-Spam-Status: No, score=-4.745 tagged_above=-999 required=5 tests=[AWL=-1.147, 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 g4Bm2kmR5eXb; Mon, 10 Dec 2012 17:29:28 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DEEEF21F871D; Mon, 10 Dec 2012 17:29:27 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2721943lah.31 for ; Mon, 10 Dec 2012 17:29:26 -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=sJMdp6+ksJ7rH4SC7PlUk2PwFObJNNWZkptMdZoT9ls=; b=nA0/S/Hc7f1owTI6hR/MKWUr11McHpqEWICK4cGYS8MtzAwX2WbJmpMvbW5yZiiKm2 kt9V8yZtwjEIMJchfXlQowoPn7oeTuvVOdBgxL6VCqwmI6alwPABYVN7R+Ioo58RFwPM PTf+EVAlXdkhtAJmkGXvMheXoSJNmCnLFe62LAP98NvVWyDRTjwjqrQM4o+F54I3Ye27 fxnqoceR6+5GIJIb4xgbnxONuMPuQzzzJ9cA5M2K81FhG5ujw4OXOpYfbavXHIdvNsgR dw7mDJaBrKT/YqMBgSc3k3EGuQ8Bqr7tEjgqOfapssVpl/Fe25FYLt75Tg8OpL+DXnrX 6mlQ== MIME-Version: 1.0 Received: by 10.152.106.212 with SMTP id gw20mr15662525lab.8.1355189366774; Mon, 10 Dec 2012 17:29:26 -0800 (PST) Received: by 10.112.98.200 with HTTP; Mon, 10 Dec 2012 17:29:26 -0800 (PST) Received: by 10.112.98.200 with HTTP; Mon, 10 Dec 2012 17:29:26 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Dec 2012 17:29:26 -0800 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: multipart/alternative; boundary=f46d0420a695cf5d7e04d0899c81 Cc: "Cullen Jennings \(fluffy\)" , mmusic@ietf.org, "<, rtcweb@ietf.org>, " , "<, public-webrtc@w3.org>, " Subject: Re: [rtcweb] [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Dec 2012 01:29:29 -0000 --f46d0420a695cf5d7e04d0899c81 Content-Type: text/plain; charset=UTF-8 If there is a way to make this happen, that would be good. If not, then I think the only realistic option available to rtcweb would be to drop bundle, etc... That wouldn't be popular. On Dec 10, 2012 5:19 PM, "Eric Rescorla" wrote: > I feel like the priorities here are kind of confused. > > It seems to me that the purpose of having a physical interim is to resolve > issues that are hard to resolve on the list or teleconferences. As I > mentioned > earlier, the SDP issues are the most important to resolve now and have > also proven to be among the most intractable. How does it make sense > to try to resolve those at a "virtual" interim while having people fly > to a "physical" interim for three days? > > I would strongly encourage the chairs to figure out how to have at least > one of the days of this interim devoted solely to resolving the SDP > issues (really, my preference would be to take these issues one at > a time and do nothing else until they are resolved!). I'm not expert > enough at the RAI WG mechanics to know what's required, so perhaps > this requires making this also an MMUSIC interim or a mini-RAI interim, > but if so that's what we should do, even if it means we need to reschedule > or move it. > > Best, > -Ekr > > On Mon, Dec 10, 2012 at 9:36 AM, Ted Hardie wrote: > >> On Mon, Dec 10, 2012 at 5:16 AM, DRAGE, Keith (Keith) < >> keith.drage@alcatel-lucent.com> wrote: >> >>> This is not just MMUSIC, there are bits of AVTCORE and AVTEXT >>> responsibility in there as well. >>> >>> And I don't see how you can suddenly extend the interim of RTCWEB to the >>> scope of other working groups, without even having a discussion with all >>> the relevant chairs. >>> >>> >> That's not how I read the overall sentiment--people are simply saying >> that they need this work done and are willing to put in the effort to get >> it done. It would, in fact, be ideal if some of the MMUSIC questions were >> resolve *before* an RTCWEB/WEBRTC interim, as we can then work through what >> is decided. >> >> Put another way, I take it as encouragement to MMUSIC folks that they >> would find a January virtual interim very well received/attended. >> >> Ted >> >> >> >>> I'd further note that Jonathan Lennox has an action (with the support of >>> quite a number of other people) to produce an internet draft on trying to >>> sort out the terminology concents that exist within RTP at the moment. This >>> would be the basis for progressing a number of these issues. That would >>> probably have to be an RAI wide draft. >>> >>> There has been some progress on this - maybe Jonathan can report on >>> where this now is. I know he was waiting on volunteers for some of the >>> sections and on input from others where volunteers already existed. >>> >>> Keith >>> >>> > -----Original Message----- >>> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf >>> > Of Cullen Jennings (fluffy) >>> > Sent: 09 December 2012 00:20 >>> > To: Eric Rescorla >>> > Cc: ; mmusic WG; >>> > Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff >>> > >>> > >>> > On Dec 8, 2012, at 4:21 PM, Eric Rescorla wrote: >>> > >>> > > +rtcweb >>> > > >>> > > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) >>> > wrote: >>> > > >>> > > I was looking over everything that needs to be completed to finish a >>> > fist cut of the WebRTC related work. There are a handful of big SDP >>> > problems that are currently blocking some of the WebRTC work and I'd >>> like >>> > to figure out how to make some progress on them. >>> > > >>> > > Let me loosely characterize them as >>> > > >>> > > 1) If we have several video streams, how do theses map up to 1 or >>> more m >>> > lines. >>> > > >>> > > 2) if we are doing port multiplexing, what does the SDP look like >>> (the >>> > bundle problem) >>> > > >>> > > 3) How do we map the RTCWeb track and stream label concepts to >>> > identifiers in SDP >>> > > >>> > > 3) SDP for application running over SCTP/DTLS >>> > > >>> > > I don't want to speak for all the various chairs but I am under the >>> > impression that most of chairs of related groups in W3C and IETF >>> believe >>> > these are issues that need to be resolved primarily in the MMUSIC WG >>> and >>> > that they impact both WebRTC and CLUE as well as the general long term >>> use >>> > of SDP in SIP and other protocols. >>> > > >>> > > I'd like to get some discussion going on how we can make some >>> progress >>> > on these. I don't think we are going to solve these in 20 minutes of >>> > discussion at an IETF meeting so I think we probably need some interim >>> > (virtual or face to face) to sort this out. >>> > > >>> > > Thoughts? >>> > > >>> > > Wow, I'm totally confused here. >>> > > >>> > > I had assumed that the SDP-related issues were going to be the main >>> > > topics at the WebRTC/RTCWEB interim in January. Is that not the case? >>> > >>> > So far the interim was only talking about being a WebRTC & RTCWeb so >>> this >>> > SDP stuff would be out of scope. Perhaps it would be better to have >>> some >>> > of the time for mmusic topics? >>> > >>> > >>> > > >>> > > IMO the lack of clarity around how to encode various media >>> > > configurations into SDP is the major thing blocking progress here. In >>> > > particular, Firefox has opted not to implement multiplexing of media >>> > > streams over the same transport flow (whether of the bundle or >>> > > multiple m-line variety) until the SDP for it is well-defined. The >>> > > same thing applies to the question of how to map multiple m-lines to >>> > > incoming MediaStreams/Tracks. >>> > > >>> > > We really need to cover these issues in the interim. >>> > > >>> > > -Ekr >>> > > >>> > > >>> > >>> > _______________________________________________ >>> > 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 >>> >> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --f46d0420a695cf5d7e04d0899c81 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

If there is a way to make this happen, that would be good.=C2=A0 If not,= then I think the only realistic option available to rtcweb would be to dro= p bundle, etc... That wouldn't be popular.

On Dec 10, 2012 5:19 PM, "Eric Rescorla&quo= t; <ekr@rtfm.com> wrote:
I feel like the priorities here are kind of confused.

It= seems to me that the purpose of having a physical interim is to resolve
issues that are hard to resolve on the list or teleconferences. As = I mentioned
earlier, the SDP issues are the most important to resolve now and have=
also proven to be among the most intractable. How does it make s= ense
to try to resolve those at a "virtual" interim whi= le having people fly
to a "physical" interim for three days?

=
I would strongly encourage the chairs to figure out how to have at lea= st
one of the days of this interim devoted solely to resolving th= e SDP=C2=A0
issues (really, my preference would be to take these issues one at
a time and do nothing else until they are resolved!). I'm not ex= pert
enough at the RAI WG mechanics to know what's required, = so perhaps
this requires making this also an MMUSIC interim or a mini-RAI interim= ,
but if so that's what we should do, even if it means we nee= d to reschedule
or move it.

Best,
-Ekr

On Mon, Dec 1= 0, 2012 at 9:36 AM, Ted Hardie <ted.ietf@gmail.com> wrote:<= br>
On Mon, Dec 10, 2012 at 5:16 AM, DRAGE, Keith (Keith) <k= eith.drage@alcatel-lucent.com> wrote:
This is not just MMUSIC, there are bits of AVTCORE and AVTEXT responsibilit= y in there as well.

And I don't see how you can suddenly extend the interim of RTCWEB to th= e scope of other working groups, without even having a discussion with all = the relevant chairs.


That's not how I read the overall senti= ment--people are simply saying that they need this work done and are willin= g to put in the effort to get it done.=C2=A0 It would, in fact, be ideal if= some of the MMUSIC questions were resolve *before* an RTCWEB/WEBRTC interi= m, as we can then work through what is decided.

Put another way, I take it as encouragement to MMUSIC folks that they w= ould find a January virtual interim very well received/attended.

Ted

=C2=A0
I'd further note that Jonathan Lennox has an action (with the support o= f quite a number of other people) to produce an internet draft on trying to= sort out the terminology concents that exist within RTP at the moment. Thi= s would be the basis for progressing a number of these issues. That would p= robably have to be an RAI wide draft.

There has been some progress on this - maybe Jonathan can report on where t= his now is. I know he was waiting on volunteers for some of the sections an= d on input from others where volunteers already existed.

Keith

> -----Original Message-----
> From: mmu= sic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Cullen Jennings (fluffy)
> Sent: 09 December 2012 00:20
> To: Eric Rescorla
> Cc: <rtcweb@ie= tf.org>; mmusic WG; <public-webrtc@w3.org>
> Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff
>
>
> On Dec 8, 2012, at 4:21 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> > +rtcweb
> >
> > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy)
> <fluffy@cisco= .com> wrote:
> >
> > I was looking over everything that needs to be completed to finis= h a
> fist cut of the WebRTC related work. There are a handful of big SDP > problems that are currently blocking some of the WebRTC work and I'= ;d like
> to figure out how to make some progress on them.
> >
> > Let me loosely characterize them as
> >
> > 1) If we have several video streams, how do theses map up to 1 or= more m
> lines.
> >
> > 2) if we are doing port multiplexing, what does the SDP look like= (the
> bundle problem)
> >
> > 3) How do we map the RTCWeb track and stream label concepts to > identifiers in SDP
> >
> > 3) SDP for application running over SCTP/DTLS
> >
> > I don't want to speak for all the various chairs but I am und= er the
> impression that most of chairs of related groups in W3C and IETF belie= ve
> these are issues that need to be resolved primarily in the MMUSIC WG a= nd
> that they impact both WebRTC and CLUE as well as the general long term= use
> of SDP in SIP and other protocols.
> >
> > I'd like to get some discussion going on how we can make some= progress
> on these. I don't think we are going to solve these in 20 minutes = of
> discussion at an IETF meeting so I think we probably need some interim=
> (virtual or face to face) to sort this out.
> >
> > Thoughts?
> >
> > Wow, I'm totally confused here.
> >
> > I had assumed that the SDP-related issues were going to be the ma= in
> > topics at the WebRTC/RTCWEB interim in January. Is that not the c= ase?
>
> So far the interim was only talking about being a WebRTC & RTCWeb = so this
> SDP stuff would be out of scope. Perhaps it would be better to have so= me
> of the time for mmusic topics?
>
>
> >
> > IMO the lack of clarity around how to encode various media
> > configurations into SDP is the major thing blocking progress here= . In
> > particular, Firefox has opted not to implement multiplexing of me= dia
> > streams over the same transport flow (whether of the bundle or > > multiple m-line variety) until the SDP for it is well-defined. Th= e
> > same thing applies to the question of how to map multiple m-lines= to
> > incoming MediaStreams/Tracks.
> >
> > We really need to cover these issues in the interim.
> >
> > -Ekr
> >
> >
>
> _______________________________________________
> 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



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

--f46d0420a695cf5d7e04d0899c81-- From mdr@reavy.org Mon Dec 10 19:08:25 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F79721F8701; Mon, 10 Dec 2012 19:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.31 X-Spam-Level: X-Spam-Status: No, score=0.31 tagged_above=-999 required=5 tests=[AWL=2.909, 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 PblTV5QG6jV1; Mon, 10 Dec 2012 19:08:24 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id E09E121F872D; Mon, 10 Dec 2012 19:08:23 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:64145 helo=[192.168.1.18]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TiGCj-0009pO-3l; Mon, 10 Dec 2012 21:08:21 -0600 Message-ID: <50C6A3A5.3060009@reavy.org> Date: Mon, 10 Dec 2012 22:08:21 -0500 From: Maire Reavy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; 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="------------090000030303080504060307" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - reavy.org X-Source: X-Source-Args: X-Source-Dir: Cc: "Cullen Jennings \(fluffy\)" , "" , mmusic WG , "" Subject: Re: [rtcweb] [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Dec 2012 03:08:25 -0000 This is a multi-part message in MIME format. --------------090000030303080504060307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I agree with Ekr on all points. We have put off resolving the SDP issues as long as we can, and the lack of resolution has started to impact our WebRTC implementation (in Firefox) already. I feel we need to maximize our chances of resolving the SDP issues as soon as we can. To me that means meeting in person as soon as possible to hammer this stuff out. Please let's find a way to discuss this in person. I think it's a big mistake if we rely on a virtual meeting only. Thanks. -Maire On 12/10/2012 8:18 PM, Eric Rescorla wrote: > I feel like the priorities here are kind of confused. > > It seems to me that the purpose of having a physical interim is to resolve > issues that are hard to resolve on the list or teleconferences. As I > mentioned > earlier, the SDP issues are the most important to resolve now and have > also proven to be among the most intractable. How does it make sense > to try to resolve those at a "virtual" interim while having people fly > to a "physical" interim for three days? > > I would strongly encourage the chairs to figure out how to have at least > one of the days of this interim devoted solely to resolving the SDP > issues (really, my preference would be to take these issues one at > a time and do nothing else until they are resolved!). I'm not expert > enough at the RAI WG mechanics to know what's required, so perhaps > this requires making this also an MMUSIC interim or a mini-RAI interim, > but if so that's what we should do, even if it means we need to reschedule > or move it. > > Best, > -Ekr > > On Mon, Dec 10, 2012 at 9:36 AM, Ted Hardie > wrote: > > On Mon, Dec 10, 2012 at 5:16 AM, DRAGE, Keith (Keith) > > wrote: > > This is not just MMUSIC, there are bits of AVTCORE and AVTEXT > responsibility in there as well. > > And I don't see how you can suddenly extend the interim of > RTCWEB to the scope of other working groups, without even > having a discussion with all the relevant chairs. > > > That's not how I read the overall sentiment--people are simply > saying that they need this work done and are willing to put in the > effort to get it done. It would, in fact, be ideal if some of the > MMUSIC questions were resolve *before* an RTCWEB/WEBRTC interim, > as we can then work through what is decided. > > Put another way, I take it as encouragement to MMUSIC folks that > they would find a January virtual interim very well received/attended. > > Ted > > I'd further note that Jonathan Lennox has an action (with the > support of quite a number of other people) to produce an > internet draft on trying to sort out the terminology concents > that exist within RTP at the moment. This would be the basis > for progressing a number of these issues. That would probably > have to be an RAI wide draft. > > There has been some progress on this - maybe Jonathan can > report on where this now is. I know he was waiting on > volunteers for some of the sections and on input from others > where volunteers already existed. > > Keith > > > -----Original Message----- > > From: mmusic-bounces@ietf.org > > [mailto:mmusic-bounces@ietf.org > ] On Behalf > > Of Cullen Jennings (fluffy) > > Sent: 09 December 2012 00:20 > > To: Eric Rescorla > > Cc: >; mmusic WG; > > > > Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff > > > > > > On Dec 8, 2012, at 4:21 PM, Eric Rescorla > wrote: > > > > > +rtcweb > > > > > > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) > > > wrote: > > > > > > I was looking over everything that needs to be completed > to finish a > > fist cut of the WebRTC related work. There are a handful of > big SDP > > problems that are currently blocking some of the WebRTC work > and I'd like > > to figure out how to make some progress on them. > > > > > > Let me loosely characterize them as > > > > > > 1) If we have several video streams, how do theses map up > to 1 or more m > > lines. > > > > > > 2) if we are doing port multiplexing, what does the SDP > look like (the > > bundle problem) > > > > > > 3) How do we map the RTCWeb track and stream label concepts to > > identifiers in SDP > > > > > > 3) SDP for application running over SCTP/DTLS > > > > > > I don't want to speak for all the various chairs but I am > under the > > impression that most of chairs of related groups in W3C and > IETF believe > > these are issues that need to be resolved primarily in the > MMUSIC WG and > > that they impact both WebRTC and CLUE as well as the general > long term use > > of SDP in SIP and other protocols. > > > > > > I'd like to get some discussion going on how we can make > some progress > > on these. I don't think we are going to solve these in 20 > minutes of > > discussion at an IETF meeting so I think we probably need > some interim > > (virtual or face to face) to sort this out. > > > > > > Thoughts? > > > > > > Wow, I'm totally confused here. > > > > > > I had assumed that the SDP-related issues were going to be > the main > > > topics at the WebRTC/RTCWEB interim in January. Is that > not the case? > > > > So far the interim was only talking about being a WebRTC & > RTCWeb so this > > SDP stuff would be out of scope. Perhaps it would be better > to have some > > of the time for mmusic topics? > > > > > > > > > > IMO the lack of clarity around how to encode various media > > > configurations into SDP is the major thing blocking > progress here. In > > > particular, Firefox has opted not to implement > multiplexing of media > > > streams over the same transport flow (whether of the bundle or > > > multiple m-line variety) until the SDP for it is > well-defined. The > > > same thing applies to the question of how to map multiple > m-lines to > > > incoming MediaStreams/Tracks. > > > > > > We really need to cover these issues in the interim. > > > > > > -Ekr > > > > > > > > > > _______________________________________________ > > 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 > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------090000030303080504060307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I agree with Ekr on all points.  We have put off resolving the SDP issues as long as we can, and the lack of resolution has started to impact our WebRTC implementation (in Firefox) already.  I feel we need to maximize our chances of resolving the SDP issues as soon as we can. 

To me that means meeting in person as soon as possible to hammer this stuff out. 

Please let's find a way to discuss this in person.  I think it's a big mistake if we rely on a virtual meeting only.

Thanks.
-Maire


On 12/10/2012 8:18 PM, Eric Rescorla wrote:
I feel like the priorities here are kind of confused.

It seems to me that the purpose of having a physical interim is to resolve
issues that are hard to resolve on the list or teleconferences. As I mentioned
earlier, the SDP issues are the most important to resolve now and have
also proven to be among the most intractable. How does it make sense
to try to resolve those at a "virtual" interim while having people fly
to a "physical" interim for three days?

I would strongly encourage the chairs to figure out how to have at least
one of the days of this interim devoted solely to resolving the SDP 
issues (really, my preference would be to take these issues one at
a time and do nothing else until they are resolved!). I'm not expert
enough at the RAI WG mechanics to know what's required, so perhaps
this requires making this also an MMUSIC interim or a mini-RAI interim,
but if so that's what we should do, even if it means we need to reschedule
or move it.

Best,
-Ekr

On Mon, Dec 10, 2012 at 9:36 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Mon, Dec 10, 2012 at 5:16 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:
This is not just MMUSIC, there are bits of AVTCORE and AVTEXT responsibility in there as well.

And I don't see how you can suddenly extend the interim of RTCWEB to the scope of other working groups, without even having a discussion with all the relevant chairs.


That's not how I read the overall sentiment--people are simply saying that they need this work done and are willing to put in the effort to get it done.  It would, in fact, be ideal if some of the MMUSIC questions were resolve *before* an RTCWEB/WEBRTC interim, as we can then work through what is decided.

Put another way, I take it as encouragement to MMUSIC folks that they would find a January virtual interim very well received/attended.

Ted

 
I'd further note that Jonathan Lennox has an action (with the support of quite a number of other people) to produce an internet draft on trying to sort out the terminology concents that exist within RTP at the moment. This would be the basis for progressing a number of these issues. That would probably have to be an RAI wide draft.

There has been some progress on this - maybe Jonathan can report on where this now is. I know he was waiting on volunteers for some of the sections and on input from others where volunteers already existed.

Keith

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Cullen Jennings (fluffy)
> Sent: 09 December 2012 00:20
> To: Eric Rescorla
> Cc: <rtcweb@ietf.org>; mmusic WG; <public-webrtc@w3.org>
> Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff
>
>
> On Dec 8, 2012, at 4:21 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> > +rtcweb
> >
> > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy)
> <fluffy@cisco.com> wrote:
> >
> > I was looking over everything that needs to be completed to finish a
> fist cut of the WebRTC related work. There are a handful of big SDP
> problems that are currently blocking some of the WebRTC work and I'd like
> to figure out how to make some progress on them.
> >
> > Let me loosely characterize them as
> >
> > 1) If we have several video streams, how do theses map up to 1 or more m
> lines.
> >
> > 2) if we are doing port multiplexing, what does the SDP look like (the
> bundle problem)
> >
> > 3) How do we map the RTCWeb track and stream label concepts to
> identifiers in SDP
> >
> > 3) SDP for application running over SCTP/DTLS
> >
> > I don't want to speak for all the various chairs but I am under the
> impression that most of chairs of related groups in W3C and IETF believe
> these are issues that need to be resolved primarily in the MMUSIC WG and
> that they impact both WebRTC and CLUE as well as the general long term use
> of SDP in SIP and other protocols.
> >
> > I'd like to get some discussion going on how we can make some progress
> on these. I don't think we are going to solve these in 20 minutes of
> discussion at an IETF meeting so I think we probably need some interim
> (virtual or face to face) to sort this out.
> >
> > Thoughts?
> >
> > Wow, I'm totally confused here.
> >
> > I had assumed that the SDP-related issues were going to be the main
> > topics at the WebRTC/RTCWEB interim in January. Is that not the case?
>
> So far the interim was only talking about being a WebRTC & RTCWeb so this
> SDP stuff would be out of scope. Perhaps it would be better to have some
> of the time for mmusic topics?
>
>
> >
> > IMO the lack of clarity around how to encode various media
> > configurations into SDP is the major thing blocking progress here. In
> > particular, Firefox has opted not to implement multiplexing of media
> > streams over the same transport flow (whether of the bundle or
> > multiple m-line variety) until the SDP for it is well-defined. The
> > same thing applies to the question of how to map multiple m-lines to
> > incoming MediaStreams/Tracks.
> >
> > We really need to cover these issues in the interim.
> >
> > -Ekr
> >
> >
>
> _______________________________________________
> 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




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

--------------090000030303080504060307-- From bernard_aboba@hotmail.com Mon Dec 10 21:01:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98AE21F855A; Mon, 10 Dec 2012 21:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.23 X-Spam-Level: X-Spam-Status: No, score=-102.23 tagged_above=-999 required=5 tests=[AWL=0.368, 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 sAeExKPajl3O; Mon, 10 Dec 2012 21:01:55 -0800 (PST) Received: from blu0-omc4-s21.blu0.hotmail.com (blu0-omc4-s21.blu0.hotmail.com [65.55.111.160]) by ietfa.amsl.com (Postfix) with ESMTP id 3B18521F84E8; Mon, 10 Dec 2012 21:01:55 -0800 (PST) Received: from BLU405-EAS266 ([65.55.111.135]) by blu0-omc4-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Dec 2012 21:01:54 -0800 X-Originating-IP: [24.16.96.166] X-EIP: [yjRvDdFj8sNRAlINp3pj8KtaEyT/BrCe] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Eric Rescorla'" References: <50C6A3A5.3060009@reavy.org> In-Reply-To: <50C6A3A5.3060009@reavy.org> Date: Mon, 10 Dec 2012 21:01:52 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C0_01CDD719.948598B0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQABAgME29FzdihW/3vtGuW7IuVOVACLVV02ABlmw/UAW7LKGAArmp1VAJrlbzCbnngYcA== Content-Language: en-us X-OriginalArrivalTime: 11 Dec 2012 05:01:54.0421 (UTC) FILETIME=[A3888A50:01CDD75C] Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org, 'mmusic WG' Subject: Re: [rtcweb] [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bernard_aboba@hotmail.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 05:01:56 -0000 ------=_NextPart_000_00C0_01CDD719.948598B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I do not think that a single meeting, virtual or actual, will suffice to get things back on track. We need a fundamental change of approach. The basic problem is that WebRTC work items have been dispersed between a number of WGs other than RTCWEB. Within these WGs, WebRTC is only a sideline. As a result, work items such as BUNDLE (which require non-trivial analysis and discussion) have found themselves a needle in a haystack of other items, getting a fraction of the attention that they need to move forward. While allocating some substantial time at an in-person RTCWEB/MMUSIC interim can help, for that time to be well spent will require substantial preparation. As an example, I could see a virtual AVTEXT interim being scheduled for mid-January at which Jonathan Lennox's hierarchy draft could be given substantial time and an MMUSIC virtual interim in the same time frame which could be devoted to one or two important topics (e.g. BUNDLE, SCTP). If that is done, then the issues requiring additional intensive work might be narrowed to the point where an in-person meeting in early February might be able to finish some of them off, with others handled another round of virtual interims two weeks later. Bernard "MARTINI was hell - but it only lasted a year" Aboba On 12/10/2012 8:18 PM, Eric Rescorla wrote: I'm not expert enough at the RAI WG mechanics to know what's required, so perhaps this requires making this also an MMUSIC interim or a mini-RAI interim, but if so that's what we should do, even if it means we need to reschedule or move it. ------=_NextPart_000_00C0_01CDD719.948598B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do not think that a = single meeting, virtual or actual, will suffice to get things back on = track.  We need a fundamental change of approach. =

 

The basic problem is = that WebRTC work items have been dispersed between a number of WGs other = than RTCWEB.  Within these WGs, WebRTC is only a sideline. =

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;     

As a result, work items = such as BUNDLE (which require non-trivial analysis and discussion) have = found themselves a needle in a haystack of other items, getting a = fraction of the attention that they need to move forward. =  

 

While allocating some = substantial time at an in-person RTCWEB/MMUSIC interim can help, for = that time to be well spent will require substantial preparation. =  As an example, I could see a virtual AVTEXT interim being = scheduled for mid-January at which Jonathan Lennox’s hierarchy = draft could be given substantial time and an MMUSIC virtual interim in = the same time frame which could be devoted to one or two important = topics (e.g. BUNDLE, SCTP).

 

If that is done, then = the issues requiring additional intensive work might be narrowed to the = point where an in-person meeting in early February might be able to = finish some of them off, with others handled another round of virtual = interims two weeks later.

 

Bernard “MARTINI = was hell – but it only lasted a year” = Aboba

 



On 12/10/2012 8:18 PM, Eric Rescorla = wrote:

I'm not expert = enough at the RAI WG mechanics to know what's required, so = perhaps

this requires making this also an MMUSIC interim or a = mini-RAI interim,

but if = so that's what we should do, even if it means we need to = reschedule

or move = it.

 

 

------=_NextPart_000_00C0_01CDD719.948598B0-- From stefan.lk.hakansson@ericsson.com Tue Dec 11 02:59:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A3021F87EE; Tue, 11 Dec 2012 02:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.137 X-Spam-Level: X-Spam-Status: No, score=-6.137 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7rbUjiL5x03; Tue, 11 Dec 2012 02:59:33 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC7A21F87E6; Tue, 11 Dec 2012 02:59:33 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-26-50c71213675d Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 5D.0C.04318.31217C05; Tue, 11 Dec 2012 11:59:32 +0100 (CET) Received: from [150.132.142.225] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Tue, 11 Dec 2012 11:59:31 +0100 Message-ID: <50C71211.4070603@ericsson.com> Date: Tue, 11 Dec 2012 11:59:29 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: bernard_aboba@hotmail.com References: <50C6A3A5.3060009@reavy.org> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+Jvja6I0PEAgzUzeC32L7nMbLHi9Tl2 i47JbBZTlz9msVj7r53dgdVjyu+NrB6Pe86weSxZ8pPJY/LjNuYAligum5TUnMyy1CJ9uwSu jEkP3jEX3OeqeLB1GnMD43GOLkZODgkBE4kJM/rZIGwxiQv31gPZXBxCAicZJf4deMwE4axl lHi19zUTSBWvgLbEvRv97CA2i4CqxJL5c1hAbDYBG4m13VPAakQFAiQWLznHDlEvKHFy5hOw GhEBWYnOi6tYQYYyC3QwShze84QZJCEsYC+xZO0Ldoht/5gl2r/uAOvgFLCV+LX7J1AHB1CH vcSDrWUgYWYBeYnmrbPBeoUEdCXevb7HOoFRcBaSfbMQOmYh6VjAyLyKkT03MTMnvdx8EyMw iA9u+W2wg3HTfbFDjNIcLErivHqq+/2FBNITS1KzU1MLUovii0pzUosPMTJxcEo1MNrGLjy0 bc2n/Rbuvp9CVsSt/22/w2K277rLzZlMcwLsdWL7bhtlhuQc9//koMW2ROhOcUkT04fm2Phz QcrdsX6ZLVoNWi7vnMoiOhuWMs2VPdX3/4MPi8fy4pbZ725c9NH5d0pbfrNUEMvud5Ncpu7S u84qm5LzemKZbLX4ny5no+I5TBxFSizFGYmGWsxFxYkADpZ6/DACAAA= Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org, 'mmusic WG' Subject: Re: [rtcweb] [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Dec 2012 10:59:34 -0000 On 12/11/2012 06:01 AM, Bernard Aboba wrote: > I do not think that a single meeting, virtual or actual, will suffice to > get things back on track. We need a fundamental change of approach. > > The basic problem is that WebRTC work items have been dispersed between > a number of WGs other than RTCWEB. Within these WGs, WebRTC is only a > sideline. > > As a result, work items such as BUNDLE (which require non-trivial > analysis and discussion) have found themselves a needle in a haystack of > other items, getting a fraction of the attention that they need to move > forward. I'd say that Bundle is something that comes on top of more fundamental things (such as the representation of multiple streams and transports in SDP) needing resolution. If I have to prioritize I would do the fundamentals first and worry about Bundle later. > > While allocating some substantial time at an in-person RTCWEB/MMUSIC > interim can help, for that time to be well spent will require > substantial preparation. As an example, I could see a virtual AVTEXT > interim being scheduled for mid-January at which Jonathan Lennox’s > hierarchy draft could be given substantial time and an MMUSIC virtual > interim in the same time frame which could be devoted to one or two > important topics (e.g. BUNDLE, SCTP). I think this is a great idea! Stefan From gunnar.hellstrom@omnitor.se Tue Dec 11 11:50:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CEE21F8625 for ; Tue, 11 Dec 2012 11:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkjhnxpdj1vq for ; Tue, 11 Dec 2012 11:50:44 -0800 (PST) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id B62BD21F86B6 for ; Tue, 11 Dec 2012 11:50:43 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP; Tue, 11 Dec 2012 20:50:35 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id 0234E3A121; Tue, 11 Dec 2012 20:50:35 +0100 (CET) Message-ID: <50C78E87.7020909@omnitor.se> Date: Tue, 11 Dec 2012 20:50:31 +0100 From: =?UTF-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Dale R. Worley" References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> <201212042040.qB4Kesnl2368891@shell01.TheWorld.com> <50BE7738.8090403@omnitor.se> <50BE899A.4020604@matthew.at> <50BF1655.80200@omnitor.se> <50BF4C23.7030108@omnitor.se> <50C18DF0.9010004@omnitor.se> <50C25586.5040408@omnitor.se> <201212111919.qBBJJe2q028000@freeze.ariadne.com> In-Reply-To: <201212111919.qBBJJe2q028000@freeze.ariadne.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Dec 2012 19:50:44 -0000 On 2012-12-11 20:19, Dale R. Worley wrote: >> From: Gunnar Hellström >> >> On 2012-12-07 18:45, Martin Thomson wrote: >>> Is there anything similar for >>> media-tags. Declaring and detecting "text" media capability or requirement >>> can be a way to select the proper terminal among a set being reachable >>> through the same address. >>> Detecting "text" capability would not be necessary in Cullen's >>> proposed scenario. The capability would be provided by the >>> application. >> Yes, understood. I was thinking about more advanced routing functions etc. >> Exploring such things can wait, and I know that they are very seldom used. > In SIP, a user agent can register with the "sip.text" capability > indicator (RFC 3840, 3841) to indicate that it supports text media: > > Contact: ;text > > An INVITE can specify that it should be routed to a UA that has > registered with such a capability: > > Accept-Contact: *;text > > Also, if the initial SDP includes an m= line that specifies text > media, call routing can prefer a Ua with text support. > > Dale Yes, it is these functions I am referring to. They are well defined on the SIP side, and look useful. But they are used to a large degree on the SIP Header level. So far I have only seen the SDP level clearly specified in rtcweb. My question was if there have been any thoughts about establishing anything similar to these SIP header parameters in rtcweb, so that the routing functions based on media and language capabilities can be established. Gunnar From matthew@matthew.at Tue Dec 11 15:26:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B20C21E8093 for ; Tue, 11 Dec 2012 15:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.033 X-Spam-Level: X-Spam-Status: No, score=-0.033 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdyFRLgrdoPp for ; Tue, 11 Dec 2012 15:26:44 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6CD21E808D for ; Tue, 11 Dec 2012 15:26:44 -0800 (PST) Received: from [10.194.215.222] (unknown [166.147.95.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id B87D0310001 for ; Tue, 11 Dec 2012 15:26:42 -0800 (PST) References: <50C7BECB.7050802@matthew.at> From: Matthew Kaufman Content-Type: multipart/alternative; boundary=Apple-Mail-3C3BC1A2-49C7-4BC1-8353-FBBEC866A44E X-Mailer: iPhone Mail (10A523) Message-Id: <9DA41D9D-39E0-46C7-A462-86FEBC1301AF@matthew.at> Date: Tue, 11 Dec 2012 15:25:42 -0800 To: "rtcweb@ietf.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: [rtcweb] Fwd: [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Dec 2012 23:26:45 -0000 --Apple-Mail-3C3BC1A2-49C7-4BC1-8353-FBBEC866A44E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Adding RTCWEB again, thanks to new Thunderbird feature that has apparently b= itten several of us now. Matthew Kaufman (Sent from my iPhone) Begin forwarded message: > From: Matthew Kaufman > Date: December 11, 2012, 3:16:27 PM PST > To: mmusic@ietf.org > Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff >=20 > On 12/8/2012 3:21 PM, Eric Rescorla wrote: >> +rtcweb >>=20 >> On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) wrote: >>>=20 >>> I was looking over everything that needs to be completed to finish a fis= t cut of the WebRTC related work. There are a handful of big SDP problems th= at are currently blocking some of the WebRTC work and I'd like to figure out= how to make some progress on them. >>>=20 >>> Let me loosely characterize them as >>>=20 >>> 1) If we have several video streams, how do theses map up to = 1 or more m lines. >>>=20 >>> 2) if we are doing port multiplexing, what does the SDP look like (the b= undle problem) >>>=20 >>> 3) How do we map the RTCWeb track and stream label concepts to identifie= rs in SDP >>>=20 >>> 3) SDP for application running over SCTP/DTLS >>=20 >>> I don't want to speak for all the various chairs but I am under the impr= ession that most of chairs of related groups in W3C and IETF believe these a= re issues that need to be resolved primarily in the MMUSIC WG and that they i= mpact both WebRTC and CLUE as well as the general long term use o= f SDP in SIP and other protocols. >>>=20 >>> I'd like to get some discussion going on how we can make some progress o= n these. I don't think we are going to solve these in 20 minutes of discussi= on at an IETF meeting so I think we probably need some interim (virtual or f= ace to face) to sort this out. >>>=20 >>> Thoughts? >>=20 >> Wow, I'm totally confused here. >>=20 >> I had assumed that the SDP-related issues were going to be the main >> topics at the WebRTC/RTCWEB interim in January. Is that not the case? >>=20 >> IMO the lack of clarity around how to encode various media >> configurations into SDP is the major thing blocking progress here. In >> particular, Firefox has opted not to implement multiplexing of media >> streams over the same transport flow (whether of the bundle or >> multiple m-line variety) until the SDP for it is well-defined. The >> same thing applies to the question of how to map multiple m-l= ines to >> incoming MediaStreams/Tracks. >>=20 >> We really need to cover these issues in the interim. >>=20 >> -Ekr >=20 > We only need to cover these issues soon if RTCWEB continues to insist that= SDP is a good idea for an API *and* that changes to SDP are necessary in or= der for RTCWEB to then be successful. >=20 > I would posit that if SDP as used in (and referenced from) RFC3264 was the= appropriate API surface for RTCWEB then NO ADDITIONAL WORK in mmusic would b= e required in order to ship RTCWEB 1.0. >=20 > Matthew Kaufman >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail-3C3BC1A2-49C7-4BC1-8353-FBBEC866A44E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Adding RTCWEB again, thanks to new Thunderbird feature that has apparently bitten several of us now.

Matthew Kaufman

(Sent from my iPhone)

Begin forwarded message:

From: Matthew Kaufman <matthew@matthew.at>
Date: December 11, 2012, 3:16:27 PM PST
To: mmusic@ietf.org
Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff

On 12/8/2012 3:21 PM, Eric Rescorla wrote:
+rtcweb

On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

I was looking over everything that needs to be completed to finish a fist cut of the WebRTC related work. There are a handful of big SDP problems that are currently blocking some of the WebRTC work and I'd like to figure out how to make some progress on them.

Let me loosely characterize them as

1) If we have several video streams, how do theses map up to 1 or more m lines.

2) if we are doing port multiplexing, what does the SDP look like (the bundle problem)

3) How do we map the RTCWeb track and stream label concepts to identifiers in SDP

3) SDP for application running over SCTP/DTLS

I don't want to speak for all the various chairs but I am under the impression that most of chairs of related groups in W3C and IETF believe these are issues that need to be resolved primarily in the MMUSIC WG and that they impact both WebRTC and CLUE as well as the general long term use of SDP in SIP and other protocols.

I'd like to get some discussion going on how we can make some progress on these. I don't think we are going to solve these in 20 minutes of discussion at an IETF meeting so I think we probably need some interim (virtual or face to face) to sort this out.

Thoughts?

Wow, I'm totally confused here.

I had assumed that the SDP-related issues were going to be the main
topics at the WebRTC/RTCWEB interim in January. Is that not the case?

IMO the lack of clarity around how to encode various media
configurations into SDP is the major thing blocking progress here. In
particular, Firefox has opted not to implement multiplexing of media
streams over the same transport flow (whether of the bundle or
multiple m-line variety) until the SDP for it is well-defined. The
same thing applies to the question of how to map multiple m-lines to
incoming MediaStreams/Tracks.

We really need to cover these issues in the interim.

-Ekr



We only need to cover these issues soon if RTCWEB continues to insist that SDP is a good idea for an API *and* that changes to SDP are necessary in order for RTCWEB to then be successful.

I would posit that if SDP as used in (and referenced from) RFC3264 was the appropriate API surface for RTCWEB then NO ADDITIONAL WORK in mmusic would be required in order to ship RTCWEB 1.0.

Matthew Kaufman

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
--Apple-Mail-3C3BC1A2-49C7-4BC1-8353-FBBEC866A44E-- From roman@telurix.com Tue Dec 11 16:02:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB1C21F8624 for ; Tue, 11 Dec 2012 16:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=0.370, 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 2xbH5BSuUCSQ for ; Tue, 11 Dec 2012 16:02:35 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4C53521F8645 for ; Tue, 11 Dec 2012 16:02:35 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so32868pbc.31 for ; Tue, 11 Dec 2012 16:02:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=AUN5McMI5dv8qXxMUGa+xi0OecwKjm21nCoe7y/81Nw=; b=Buhh9yZdbA9HblOBAMmaVoKwvxVa5UFhEVcWWfNlLmwmmKCIKJi5FHox8rZYMwQh+L d9lQVuemMcGtQ/JsZ/LHO5E989BebKGtDjEcsOhIUkZdzMjiQ+d31hGRKQ1KEmHhIFm+ oGpSJR7LrYk4rjBWpOe30FfOV4ASMBhKCFWWGKIOpTcZyBJVu0q2VXdMs2pqd5bl0O3z pA+LCmuK4u5evpi6WIOtTQpi2zC4aj+qaXIQx9B0lQ79SDMyR81KVM/kpQyT0YqAcijx 3KOF3bRdeFUjQ9cETV3UcOYD3y1uqMTAeZPQ5kcxFc9TSqDnHPb5/tYfyyj4XSNQgr2m ZuKA== Received: by 10.68.236.2 with SMTP id uq2mr38919706pbc.55.1355270555001; Tue, 11 Dec 2012 16:02:35 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id ug6sm14540365pbc.4.2012.12.11.16.02.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Dec 2012 16:02:34 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so32853pbc.31 for ; Tue, 11 Dec 2012 16:02:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.135.133 with SMTP id ps5mr52725915pbb.132.1355270553359; Tue, 11 Dec 2012 16:02:33 -0800 (PST) Received: by 10.68.42.8 with HTTP; Tue, 11 Dec 2012 16:02:33 -0800 (PST) In-Reply-To: <9DA41D9D-39E0-46C7-A462-86FEBC1301AF@matthew.at> References: <50C7BECB.7050802@matthew.at> <9DA41D9D-39E0-46C7-A462-86FEBC1301AF@matthew.at> Date: Tue, 11 Dec 2012 19:02:33 -0500 Message-ID: From: Roman Shpount To: Matthew Kaufman Content-Type: multipart/alternative; boundary=047d7b10c7d1e855d704d09c8371 X-Gm-Message-State: ALoCoQlBPSN5OJRpfYqV0wBdTRD+OTYl5IFCSQz3qf8GoeZF+JehJhKiB9II0JZaqdZRAVFdL7Ay Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Dec 2012 00:02:36 -0000 --047d7b10c7d1e855d704d09c8371 Content-Type: text/plain; charset=ISO-8859-1 +1. I would argue that if you want something you can inter-operate with you are better off with an API that clearly matches the capabilities of the system. Building an API which uses under-specified text blobs (in this case SDP) for interfaces usually ends up producing things that only offer check box interoperability. I grant you it is much easier to specify or implement, since it gives you a lot more implementation freedom, but your normally end up with something that only work with another instance of the same implementation. BTW, using SDP from RFC3264 is not an option. This specification does not define SDP. It defines a negotiation framework. SDP is defined in RFC 2327, which is of no value since all it does is defines the basic structure. You need RFC 3551 to describe how SDP is used for audio and video data. Then you need another RFC for ICE. Another for AVPF. And the list goes on (bundle, SCTP, specifying a port for RTCP, SRTP, DTLS-SRTP). Each of those RFCs will specify some aspects that we need but will bring a number of things that has no relevance. So, you would need to write another document that describes how the features that we need are implemented using all of those RFCs. I think we are better of just describing how we can control the features that we need via the dedicated API methods and let JavaScript application map it to the text blob, which can be SDP or can be just a JSON object. _____________ Roman Shpount On Tue, Dec 11, 2012 at 6:25 PM, Matthew Kaufman wrote: > Adding RTCWEB again, thanks to new Thunderbird feature that has apparently > bitten several of us now. > > Matthew Kaufman > > (Sent from my iPhone) > > Begin forwarded message: > > *From:* Matthew Kaufman > *Date:* December 11, 2012, 3:16:27 PM PST > *To:* mmusic@ietf.org > *Subject:* *Re: [MMUSIC] SDP work needed for WebRTC stuff* > > On 12/8/2012 3:21 PM, Eric Rescorla wrote: > > +rtcweb > > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) < > fluffy@cisco.com> wrote: > >> >> I was looking over everything that needs to be completed to finish a fist >> cut of the WebRTC related work. There are a handful of big SDP problems >> that are currently blocking some of the WebRTC work and I'd like to figure >> out how to make some progress on them. >> >> Let me loosely characterize them as >> >> 1) If we have several video streams, how do theses map up to 1 or more m >> lines. >> >> 2) if we are doing port multiplexing, what does the SDP look like (the >> bundle problem) >> >> 3) How do we map the RTCWeb track and stream label concepts to >> identifiers in SDP >> >> 3) SDP for application running over SCTP/DTLS >> > > I don't want to speak for all the various chairs but I am under the >> impression that most of chairs of related groups in W3C and IETF believe >> these are issues that need to be resolved primarily in the MMUSIC WG and >> that they impact both WebRTC and CLUE as well as the general long term use >> of SDP in SIP and other protocols. >> >> I'd like to get some discussion going on how we can make some progress on >> these. I don't think we are going to solve these in 20 minutes of >> discussion at an IETF meeting so I think we probably need some interim >> (virtual or face to face) to sort this out. >> >> Thoughts? >> > > Wow, I'm totally confused here. > > I had assumed that the SDP-related issues were going to be the main > topics at the WebRTC/RTCWEB interim in January. Is that not the case? > > IMO the lack of clarity around how to encode various media > configurations into SDP is the major thing blocking progress here. In > particular, Firefox has opted not to implement multiplexing of media > streams over the same transport flow (whether of the bundle or > multiple m-line variety) until the SDP for it is well-defined. The > same thing applies to the question of how to map multiple m-lines to > incoming MediaStreams/Tracks. > > We really need to cover these issues in the interim. > > -Ekr > > > > We only need to cover these issues soon if RTCWEB continues to insist that > SDP is a good idea for an API *and* that changes to SDP are necessary in > order for RTCWEB to then be successful. > > I would posit that if SDP as used in (and referenced from) RFC3264 was the > appropriate API surface for RTCWEB then NO ADDITIONAL WORK in mmusic would > be required in order to ship RTCWEB 1.0. > > Matthew Kaufman > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b10c7d1e855d704d09c8371 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1.

I would argue that if you want something you can=A0i= nter-operate=A0with you are better off with an API that clearly matches the= capabilities of the system. Building an API which uses=A0under-specified= =A0text blobs (in this case SDP) for interfaces usually ends up producing t= hings that only offer check box interoperability. I grant you it is much ea= sier to specify or implement, since it gives you a lot more implementation = freedom, but your normally end up with something that only work with anothe= r instance of the same implementation.

BTW, using SDP from RFC3264 is not an option. This spec= ification does not define SDP. It defines a=A0negotiation framework.=A0SDP = is defined in=A0RFC 2327, which is of no value since all it does is defines= the basic structure. You need RFC 3551 to describe how SDP is used for aud= io and video data. Then you need another RFC for ICE. Another for AVPF. And= the list goes on (bundle, SCTP,=A0specifying=A0a port for RTCP, SRTP, DTLS= -SRTP). Each of those RFCs will specify some aspects that we need but will = bring a number of things that has no relevance. So, you would need to write= another document that describes how the features that we need are implemen= ted using all of those RFCs. I think we are better of just describing how w= e can control the features that we need via the dedicated API methods and l= et JavaScript application map it to the text blob, which can be SDP or can = be just a JSON object.
_____________
Roman Shpount



On Tue, Dec 11, 2012 at 6:25 PM, Matthew= Kaufman <matthew@matthew.at> wrote:
Adding RTCWEB again, thanks to new Thunderbird= feature that has apparently bitten several of us now.

Matthe= w Kaufman

(Sent from my iPhone)

Begin forwarded= message:

From: Matthew Kaufman <<= a href=3D"mailto:matthew@matthew.at" target=3D"_blank">matthew@matthew.at>
Date: December 11, 2012, 3:16:27 PM PST
To: mmusic@ietf.org
Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff
=20 =20 =20 =20
On 12/8/2012 3:21 PM, Eric Rescorla wrote:
+rtcweb

On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) <fluffy= @cisco.com> wrote:

I was looking over everything that needs to be completed to finish a fist cut of the WebRTC related work. There are a handful of big SDP problems that are currently blocking some of the WebRTC work and I'd like to figure out how to make some progress on them.

Let me loosely characterize them as

1) If we have several video streams, how do theses map up to 1 or more m lines.

2) if we are doing port multiplexing, what does the SDP look like (the bundle problem)

3) How do we map the RTCWeb track and stream label concepts to identifiers in SDP

3) SDP for application running over SCTP/DTLS

I don't want to speak for all the various chairs but I am under the impression that most of chairs of related groups in W3C and IETF believe these are issues that need to be resolved primarily in the MMUSIC WG and that they impact both WebRTC and CLUE as well as the general long term use of SDP in SIP and other protocols.

I'd like to get some discussion going on how we can make some progress on these. I don't think we are going to solve these in 20 minutes of discussion at an IETF meeting so I think we probably need some interim (virtual or face to face) to sort this out.

Thoughts?

Wow, I'm totally confused here.

I had assumed that the SDP-related issues were going to be the main
topics at the WebRTC/RTCWEB interim in January. Is that not the case?

IMO the lack of clarity around how to encode various media
configurations into SDP is the major thing blocking progress here. In
particular, Firefox has opted not to implement multiplexing of media
streams over the same transport flow (whether of the bundle or
multiple m-line variety) until the SDP for it is well-defined. The
same thing applies to the question of how to map multiple m-lines to
incoming MediaStreams/Tracks.

We really need to cover these issues in the interim.

-Ekr



We only need to cover these issues soon if RTCWEB continues to insist that SDP is a good idea for an API *and* that changes to SDP are necessary in order for RTCWEB to then be successful.

I would posit that if SDP as used in (and referenced from) RFC3264 was the appropriate API surface for RTCWEB then NO ADDITIONAL WORK in mmusic would be required in order to ship RTCWEB 1.0.

Matthew Kaufman

=20
___________________= ____________________________
mmusic mailing list
= mmusic@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/mmusic

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


--047d7b10c7d1e855d704d09c8371-- From christer.holmberg@ericsson.com Tue Dec 11 21:46:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1C421F8617 for ; Tue, 11 Dec 2012 21:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zctG7tpD-Bs7 for ; Tue, 11 Dec 2012 21:46:20 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 68C0821F8846 for ; Tue, 11 Dec 2012 21:46:15 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-26-50c81a190b86 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F9.62.24873.91A18C05; Wed, 12 Dec 2012 06:46:02 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.001; Wed, 12 Dec 2012 06:46:01 +0100 From: Christer Holmberg To: Roman Shpount , Matthew Kaufman Thread-Topic: [rtcweb] Fwd: [MMUSIC] SDP work needed for WebRTC stuff Thread-Index: AQHN1/WQMjcsuyAsPU+RLeFGUyQNV5gUPh/3///5KoCAAG/RsA== Date: Wed, 12 Dec 2012 05:46:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0538CD@ESESSMB209.ericsson.se> References: <50C7BECB.7050802@matthew.at> <9DA41D9D-39E0-46C7-A462-86FEBC1301AF@matthew.at> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvja6U1IkAg9WSFm2zj7BYzLgwldli 7b92dgdmjyVLfjJ5nOr08rg1pSCAOYrLJiU1J7MstUjfLoErY8PtCywFp5QqPm46w9bAeES6 i5GTQ0LARGL19desELaYxIV769m6GLk4hAQOMUr8uvAYylnCKNEzfxFzFyMHB5uAhUT3P22Q BhEBb4mGtctYQGxmAXWJO4vPsYOUCAu4SPy4bQ5R4irxoe0rM4TtJLH69Xc2EJtFQFXi4oEP YHt5gcbMONMFNgZs1fUPSiA2p0CgRO/+dYwgNiPQbd9PrWGCWCUucevJfCaImwUkluw5zwxh i0q8fPyPFeQECQFFieX9chDlehI3pk5hg7C1JZYtfM0MsVZQ4uTMJywTGMVmIZk6C0nLLCQt s5C0LGBkWcXInpuYmZNebrSJERgtB7f8Vt3BeOecyCFGaQ4WJXFe6617/IUE0hNLUrNTUwtS i+KLSnNSiw8xMnFwSjUwrhWv5CycbNndw7xCXTMta6dW8oHP2j+cZ5iL6r/hEqnvFZ7f33Ll 5LnQXxEr132R2Voer7ls/oobNjJ7ly5+KKCtEl3QO+fa1cTOsHKnHLGNe+4V2z6vD8tz+Rmq d1ztxq4XdxZxn3h5dO66d23WLulPsy/+V/u1alY8g3iLn9keqYAfc274K7EUZyQaajEXFScC AG3IicZkAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Dec 2012 05:46:27 -0000 Hi Roman, >BTW, using SDP from RFC3264 is not an option. This specification does not = define SDP. It defines a=A0negotiation framework.=A0SDP is defined in=A0RFC= 2327, which is of no value=20 >since all it does is defines the basic structure. You need RFC 3551 to des= cribe how SDP is used for audio and video data. Then you need another RFC f= or ICE. Another for=20 >AVPF. And the list goes on (bundle, SCTP,=A0specifying=A0a port for RTCP, = SRTP, DTLS-SRTP). Each of those RFCs will specify some aspects that we need= but will bring a number=20 >of things that has no relevance. So, you would need to write another docum= ent that describes how the features that we need are implemented using all = of those RFCs. I assume that is what JSEP is trying to do. Of course, there is no need to re-write everything in JSEP. For example, I = still think the negotiation part shall be RFC3264. >I think we are better of just describing how we can control the features t= hat we need via the dedicated API methods and let JavaScript application ma= p it to the text blob, which can be SDP or can be just a JSON object. The proposal previously known as the Microsoft proposal, you mean? Regards, Christer On Tue, Dec 11, 2012 at 6:25 PM, Matthew Kaufman wrote= : Adding RTCWEB again, thanks to new Thunderbird feature that has apparently = bitten several of us now. Matthew Kaufman (Sent from my iPhone) Begin forwarded message: From: Matthew Kaufman Date: December 11, 2012, 3:16:27 PM PST To: mmusic@ietf.org Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff On 12/8/2012 3:21 PM, Eric Rescorla wrote: +rtcweb=20 On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) = wrote: I was looking over everything that needs to be completed to finish a fist c= ut of the WebRTC related work. There are a handful of big SDP problems that= are currently blocking some of the WebRTC work and I'd like to figure out = how to make some progress on them. Let me loosely characterize them as 1) If we have several video streams, how do theses map up to 1 or more m li= nes. 2) if we are doing port multiplexing, what does the SDP look like (the bund= le problem) 3) How do we map the RTCWeb track and stream label concepts to identifiers = in SDP 3) SDP for application running over SCTP/DTLS I don't want to speak for all the various chairs but I am under the impress= ion that most of chairs of related groups in W3C and IETF believe these are= issues that need to be resolved primarily in the MMUSIC WG and that they i= mpact both WebRTC and CLUE as well as the general long term use of SDP in S= IP and other protocols. I'd like to get some discussion going on how we can make some progress on t= hese. I don't think we are going to solve these in 20 minutes of discussion= at an IETF meeting so I think we probably need some interim (virtual or fa= ce to face) to sort this out. Thoughts? Wow, I'm totally confused here. I had assumed that the SDP-related issues were going to be the main topics at the WebRTC/RTCWEB interim in January. Is that not the case? IMO the lack of clarity around how to encode various media configurations into SDP is the major thing blocking progress here. In particular, Firefox has opted not to implement multiplexing of media streams over the same transport flow (whether of the bundle or multiple m-line variety) until the SDP for it is well-defined. The same thing applies to the question of how to map multiple m-lines to incoming MediaStreams/Tracks. We really need to cover these issues in the interim. -Ekr We only need to cover these issues soon if RTCWEB continues to insist that = SDP is a good idea for an API *and* that changes to SDP are necessary in or= der for RTCWEB to then be successful. I would posit that if SDP as used in (and referenced from) RFC3264 was the = appropriate API surface for RTCWEB then NO ADDITIONAL WORK in mmusic would = be required in order to ship RTCWEB 1.0. Matthew Kaufman _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Wed Dec 12 02:37:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964B221F84FD; Wed, 12 Dec 2012 02:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.204 X-Spam-Level: X-Spam-Status: No, score=-106.204 tagged_above=-999 required=5 tests=[AWL=0.045, 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 zQQ8QzGVCHzI; Wed, 12 Dec 2012 02:37:28 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4183C21F84FB; Wed, 12 Dec 2012 02:37:27 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-37-50c85e65c6a4 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A5.41.24873.56E58C05; Wed, 12 Dec 2012 11:37:26 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 12 Dec 2012 11:37:24 +0100 Message-ID: <50C85E64.3010801@ericsson.com> Date: Wed, 12 Dec 2012 11:37:24 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: bernard_aboba@hotmail.com References: <50C6A3A5.3060009@reavy.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+JvjW5a3IkAg52TOCz2L7nMbLHi9Tl2 i47JbBZTlz9msVj7r53dgdVjyu+NrB6Pe86weSxZ8pPJY/LjNuYAligum5TUnMyy1CJ9uwSu jIdfrrEUXFOsePb2NHsD4zapLkZODgkBE4lPHw4yQ9hiEhfurWfrYuTiEBI4yShx8MELFghn OaPEjTs3GEGqeAW0JW5O283UxcjBwSKgKjFvWS1ImE3AQuLmj0Y2EFtUwFdi1p5fTBDlghIn Zz5hAbFFBGQlOi+uYgWZySzQwShxeM8TsM3CAg4Sx9b+gdr8j1mi/esOsA5OAVuJX7t/skKc JymxaFonWJxZwEDiyKI5rBC2vETz1tlgg4SAjmto6mCdwCg0C8nyWUhaZiFpWcDIvIqRPTcx Mye93GgTIzC8D275rbqD8c45kUOM0hwsSuK81lv3+AsJpCeWpGanphakFsUXleakFh9iZOLg lGpg5Ct8WalgdrTH5eSGR0Z/Vu2doJ/oVGfX1m4merKgOl+3yCl5frL0B+6pOy2Ysy7d7zdy Zq35KbO799tx/r0VSXfP/QstqJPq+5p1sKPj8+o5YmyPp74oTT+TsOhpw5xDJd457Gf2BO/X 3f+haatJll+Zp40yR0xXm+pEodW3z59NFe1cGr1aiaU4I9FQi7moOBEA2oFXBD0CAAA= Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org, 'mmusic WG' Subject: Re: [rtcweb] [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Dec 2012 10:37:28 -0000 Hi, My Personal view on this topics. On 2012-12-11 06:01, Bernard Aboba wrote: > I do not think that a single meeting, virtual or actual, will suffice to > get things back on track. We need a fundamental change of approach. > Fully agreed. One of the issues, is that not a single individual of use across 5-6 WG have a complete picture of the issues we are stepping into with the fundamental issues that are in the center of this. This will require multiple individuals having knowledge on different aspects to fill in details and educate the others on the diverse issues. > > > The basic problem is that WebRTC work items have been dispersed between > a number of WGs other than RTCWEB. Within these WGs, WebRTC is only a > sideline. I am not certain that is the fundamental issue here. I think the very basic problem is that we are attempting for fork lift SDP into a clear specification supporting multi-stream RTP sessions and dealing with the diverse landscape of relationships that exists in multi-media applications between a large number of terminologies that include concepts such as: - Multi-party - Multiple media sources, i.e. camera microphones - Media Mixes or Compositions - Synchronization Contexts - End-point concepts, virtual, distributed, etc. - Diverse signalling models - Simulcast - Layered Encoding - Transport robustification, i.e RTP Retransmission, Duplications, FEC. - Different transports, aggregated over single unicast, multiple unicast flows, multicast - Different security mechanisms This coupled with that the people putting in requirements on this are working on different type of systems or applications, RTCWEB/WebRTC and CLUE just being two. We also have existing users of RTP that made different assumptions in extensions and signalling. It was very evident in RTCWEB and AVTEXT that we are lacking common terminology to even discuss the above and what it means in different contexts. Then we haven't even discussed what happens the minute you drag the word "Legacy" into any of the above debates for actual solutions. But now I am getting ahead of myself. I think the most important is to build a good description of the different functionalities and their relationships that we today believe are necessary to deal with currently and in the near future. > > > > > As a result, work items such as BUNDLE (which require non-trivial > analysis and discussion) have found themselves a needle in a haystack of > other items, getting a fraction of the attention that they need to move > forward. Yes, bundle is something that covers parts of the above and clearly related. I, however think more close to the core of the issues is the multiple stream issues and how we deal with relationships. However, I think failing to take the related topics into account and think that this will be quickly resolved will only result in generating even more mess. I also believe that in the end we are going to have to take some though decisions when it comes how to deal with existing definitions. Either replace them or basically deprecate some behaviors. > > While allocating some substantial time at an in-person RTCWEB/MMUSIC > interim can help, for that time to be well spent will require > substantial preparation. As an example, I could see a virtual AVTEXT > interim being scheduled for mid-January at which Jonathan Lennox’s > hierarchy draft could be given substantial time and an MMUSIC virtual > interim in the same time frame which could be devoted to one or two > important topics (e.g. BUNDLE, SCTP). > Fully agreed. This takes preparations and hard work. 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 andrew.hutton@siemens-enterprise.com Wed Dec 12 03:39:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A318221F89CA for ; Wed, 12 Dec 2012 03:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 MQBb+Rjo7DGb for ; Wed, 12 Dec 2012 03:39:56 -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 D036621F89C9 for ; Wed, 12 Dec 2012 03:39:55 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 60F2F1EB8C69; Wed, 12 Dec 2012 12:39:54 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.13]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Wed, 12 Dec 2012 12:39:54 +0100 From: "Hutton, Andrew" To: Christer Holmberg , Roman Shpount , Matthew Kaufman , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Fwd: [MMUSIC] SDP work needed for WebRTC stuff Thread-Index: AQHN1/WUMHpJZiO/lkihgItkrWN9/pgUPhRn///5NYCAAF/1AIAAbQzg Date: Wed, 12 Dec 2012 11:39:48 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0138F2F5@MCHP04MSX.global-ad.net> References: <50C7BECB.7050802@matthew.at> <9DA41D9D-39E0-46C7-A462-86FEBC1301AF@matthew.at> <7594FB04B1934943A5C02806D1A2204B0538CD@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0538CD@ESESSMB209.ericsson.se> 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] Fwd: [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Dec 2012 11:39:56 -0000 See below. > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: 12 December 2012 05:46 > To: Roman Shpount; Matthew Kaufman > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Fwd: [MMUSIC] SDP work needed for WebRTC stuff >=20 > Hi Roman, >=20 > >BTW, using SDP from RFC3264 is not an option. This specification does > not define SDP. It defines a=A0negotiation framework.=A0SDP is defined > in=A0RFC 2327, which is of no value > >since all it does is defines the basic structure. You need RFC 3551 to > describe how SDP is used for audio and video data. Then you need > another RFC for ICE. Another for > >AVPF. And the list goes on (bundle, SCTP,=A0specifying=A0a port for RTCP= , > SRTP, DTLS-SRTP). Each of those RFCs will specify some aspects that we > need but will bring a number > >of things that has no relevance. So, you would need to write another > document that describes how the features that we need are implemented > using all of those RFCs. >=20 > I assume that is what JSEP is trying to do. Agree that this is what JSEP is intended for and there is quite a bit of wo= rk to do to make JSEP in to a clear authoritative description of SDP usage = for RTCWEB.=20 Even without all the SDP enhancements needed (E.g. Bundle, SCTP/DTLS, Multi= ple audio/video streams) JSEP has to explain how the API uses SDP to meet t= he requirements and what the split of responsibilities is between the brows= er and the application. For example adding a new stream during an existing= session is not currently explained neither is how the sess-version in the = o-line is maintained etc. =20 Andy =20 From roman@telurix.com Wed Dec 12 14:31:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FE721F8A70 for ; Wed, 12 Dec 2012 14:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=0.277, 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 uH2yMQxQh6y6 for ; Wed, 12 Dec 2012 14:31:00 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE0721F8A6F for ; Wed, 12 Dec 2012 14:31:00 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so950151pad.31 for ; Wed, 12 Dec 2012 14:31:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=s4FhVKjdLctOIuclnM8UnEI/MPU91DZBzFXCZqfJrSA=; b=brf3o1iNrHMDBn3C/uKtC2C0kpidnP5rBG4hPSF0wwpBmhgJXpGIGx2vhD956tSv6/ vC/2Vx1TNcVsKOhyV+sRPIiGTtLY0046N9dKHt9SQoK8lo6bnluga9gplM6n+u9wRn61 hKZrzc9PZ9bYVCR2w2ScFCjjQs/O75PdsmwjM3IxFf0BBMZx3QMQ0An9gwAf+sKW+/ED h6xCZHFkPSyWynXPoBnRil7CGXYne/Rxx1Hvc3nzKUqmGsjgIzRlge7GfCd3k9cOx2DT MO+sCmNxDnu9M31PKVxXFXwedVahEgtB8tUiAoWUVBA/m1oi38K78vnu88jnuYE+usUh oaXA== Received: by 10.68.191.200 with SMTP id ha8mr6617723pbc.51.1355351460008; Wed, 12 Dec 2012 14:31:00 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by mx.google.com with ESMTPS id j1sm15489526pax.10.2012.12.12.14.30.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Dec 2012 14:30:59 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so950134pad.31 for ; Wed, 12 Dec 2012 14:30:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.211.42 with SMTP id mz10mr6699020pbc.100.1355351458756; Wed, 12 Dec 2012 14:30:58 -0800 (PST) Received: by 10.68.42.8 with HTTP; Wed, 12 Dec 2012 14:30:58 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0538CD@ESESSMB209.ericsson.se> References: <50C7BECB.7050802@matthew.at> <9DA41D9D-39E0-46C7-A462-86FEBC1301AF@matthew.at> <7594FB04B1934943A5C02806D1A2204B0538CD@ESESSMB209.ericsson.se> Date: Wed, 12 Dec 2012 17:30:58 -0500 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=e89a8ff1ca383eb67b04d0af5a03 X-Gm-Message-State: ALoCoQlzS2vEYPUbcJPcwtHLMQSamHkhblo0tU74qpeZNlRIGrGy3s0ZBj/vMrSKGJWtjQoWOzlU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Dec 2012 22:31:02 -0000 --e89a8ff1ca383eb67b04d0af5a03 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 12, 2012 at 12:46 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Of course, there is no need to re-write everything in JSEP. For example, I > still think the negotiation part shall be RFC3264. > I actually not 100% convinced that this should be the case (I know that consensus is against me). Main issues that I have against basing the API on RFC 3264 are: 1. This forces to negotiate transport parameters (ice candidates, encryption keys) every time encoding parameters are changed. I do not see a reason why we need to run ice state machine and re-negotiate encryption to add or remove a bundled video stream or change encoding. To do this efficiently we need to have a side channel and additional operations to RFC 3264 2. Dealing with parameters which are not negotiated via RFC 3264 is cumbersome. For instance, how would you specify the complexity for OPUS encoder? You would most likely need some other side channel. 3. Offer answer is not the only available scenario. One thing that was discussed that each game or conference participant generates an offer, keeps it active for the duration of the conference and sends it to the server, where it is cached. When new participant joins the conference, it gets cached offers for all the other participants from the server and generates answers to them. This removes an extra signaling hop but impossible with current API. > The proposal previously known as the Microsoft proposal, you mean? > Microsoft proposal was closer to what I want but not quite done either. Periodically I feel like we are all members of the wheel reinvention comity, we all know what the shape should be, but cannot agree on the color. The features we need are: 1. Ability to negotiate the transport parameters, ie generate the list of ICE candidates, select encryption type (SRTP or DTLS-SRTP), get the ICE candidates from remote side and run the ICE state machine (and if needed DTLS negotiation). Once this is done we end up with a transport channel. If we do this right we should be able to do forking: generate an offer and run an ICE state machine for multiple answers to set up multiple connections for the same offer. I would argue that all the required data parameters and the require API for this is pretty clear. 2. Setup a mapping from connection, packet type (SCTP, RTP, RTCP) and SSRC to a RTP or RTCP sinc, from there, based on payload to codec decoder and from there to media track. We should have an API which allows to change these assignments on the fly without re-negotiating communication channels. 3. Setup a mapping from media track to codec encoder to RTP/RTCP sinc and from there to a connection. Once again, we should have an API which allows to change these assignments on the fly without re-negotiation communication channels or processing of inbound packets. If we organize the API like this it would take a lot less time to standardize, will be a lot more flexible and will remove a lot of dependencies from other working groups. I would also argue that this will allow us to build something that has a much higher chance of interoperating with real deployments then something based on text blobs defined across four working groups for conflicting and unrelated purposes. P.S. I am aware that this is fairly late in the game and Chrome/Firefox will or are already released with something completely different. I would still argue that it is better to build something that is clean and usable later in the game, then keep on building kludges (like various hints in multiple places). _____________ Roman Shpount --e89a8ff1ca383eb67b04d0af5a03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 12, 2012 at 12:46 AM, Christer Holmberg = <christer.holmberg@ericsson.com> wrote:
Of course, there is no need= to re-write everything in JSEP. For example, I still think the negotiation= part shall be RFC3264.

I actually n= ot 100% convinced that this should be the case (I know that consensus is ag= ainst me). Main issues that I have against basing the API on RFC 3264 are:<= /div>

1. This forces to negotiate transport parameters (ice c= andidates, encryption keys) every time encoding parameters are changed. I d= o not see a reason why we need to run ice state machine and re-negotiate en= cryption to add or remove a bundled video stream or change encoding. To do = this efficiently we need to have a side channel and additional operations t= o RFC 3264

2. Dealing with parameters which are not negotiated via= RFC 3264 is cumbersome. For instance, how would you specify the complexity= for OPUS encoder? You would most likely need some other side channel.

3. Offer answer is not the only available scenario. One= thing that was discussed that each game or conference participant generate= s an offer, keeps it active for the duration of the conference and sends it= to the server, where it is cached. When new participant joins the conferen= ce, it gets cached offers for all the other participants from the server an= d generates answers to them. This removes an extra signaling hop but imposs= ible with current API.

=A0
The proposal previously known as the Microsoft proposal= , you mean?

Microsoft proposal was closer to wh= at I want but not quite done either.

Periodically I feel= like we are all members of the wheel reinvention comity, we all know what = the shape should be, but cannot agree on the color. The features we need ar= e:

1. Ability to negotiate the transport parameters, ie ge= nerate the list of ICE candidates, select encryption type (SRTP or DTLS-SRT= P), get the ICE candidates from remote side and run the ICE state machine (= and if needed DTLS negotiation). Once this is done we end up with a transpo= rt channel. If we do this right we should be able to do forking: generate a= n offer and run an ICE state machine for multiple answers to set up multipl= e connections for the same offer. I would argue that all the required data = parameters and the require API for this is pretty clear.

2. Setup a mapping from connection, packet type (SCTP, = RTP, RTCP) and =A0SSRC to a RTP or RTCP sinc, from there, based on payload = to codec decoder and from there to media track. We should have an API which= allows to change these assignments on the fly without re-negotiating commu= nication channels.

3. Setup a mapping from media track to codec encoder to= RTP/RTCP sinc and from there to a connection. Once again, we should have a= n API which allows to change these assignments on the fly without re-negoti= ation communication channels or processing of inbound packets.

If we organize the API like this it would take a lot le= ss time to=A0standardize, will be a lot more flexible and will remove a lot= of dependencies from other working groups. I would also argue that this wi= ll allow us to build something that has a much higher chance of interoperat= ing with real deployments then something based on text blobs defined across= four working groups for=A0conflicting=A0and unrelated purposes.

P.S. I am aware that this is fairly late in the game an= d Chrome/Firefox will or are already released with something completely dif= ferent. I would still argue that it is better to build something that is cl= ean and usable later in the game, then keep on building=A0kludges=A0(like v= arious hints in multiple places).
_____________
Roman Shpount

--e89a8ff1ca383eb67b04d0af5a03-- From harald@alvestrand.no Thu Dec 13 02:08:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3ABD21F8925 for ; Thu, 13 Dec 2012 02:08:42 -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 BFE3WLS74Vz5 for ; Thu, 13 Dec 2012 02:08:41 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4779821F8920 for ; Thu, 13 Dec 2012 02:08:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 97CEF39E1C6 for ; Thu, 13 Dec 2012 11:08:38 +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 atJgIjq5CRVP for ; Thu, 13 Dec 2012 11:08:31 +0100 (CET) Received: from [172.30.42.105] (c-f8f1e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.241.248]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9578A39E091 for ; Thu, 13 Dec 2012 11:08:30 +0100 (CET) Message-ID: <50C9A91E.10505@alvestrand.no> Date: Thu, 13 Dec 2012 11:08:30 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50C7BECB.7050802@matthew.at> <9DA41D9D-39E0-46C7-A462-86FEBC1301AF@matthew.at> <7594FB04B1934943A5C02806D1A2204B0538CD@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050008090106060403080802" Subject: Re: [rtcweb] Fwd: [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Dec 2012 10:08:43 -0000 This is a multi-part message in MIME format. --------------050008090106060403080802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/12/2012 11:30 PM, Roman Shpount wrote: > > On Wed, Dec 12, 2012 at 12:46 AM, Christer Holmberg > > wrote: > > Of course, there is no need to re-write everything in JSEP. For > example, I still think the negotiation part shall be RFC3264. > > > I actually not 100% convinced that this should be the case (I know > that consensus is against me). I'm not 100% convinced either, but I don't find your arguments compelling. > Main issues that I have against basing the API on RFC 3264 are: > > 1. This forces to negotiate transport parameters (ice candidates, > encryption keys) every time encoding parameters are changed. I do not > see a reason why we need to run ice state machine and re-negotiate > encryption to add or remove a bundled video stream or change encoding. > To do this efficiently we need to have a side channel and additional > operations to RFC 3264 I don't know that this is the case. If RFC 3264 renegotiation is done without changing the crypto and transport parameters from what's currently in force, I can't see why the ICE and crypto state machines should change. > > 2. Dealing with parameters which are not negotiated via RFC 3264 is > cumbersome. For instance, how would you specify the complexity for > OPUS encoder? You would most likely need some other side channel. Doesn't OPUS do that in-band? If complexity needs to be specified before starting an OPUS connection, that is needed when OPUS is used in SIP too - so we're reducing this to a problem that needs to be solved anyway. > > 3. Offer answer is not the only available scenario. One thing that was > discussed that each game or conference participant generates an offer, > keeps it active for the duration of the conference and sends it to the > server, where it is cached. When new participant joins the conference, > it gets cached offers for all the other participants from the server > and generates answers to them. This removes an extra signaling hop but > impossible with current API. I'm not sure it's impossible. I'd like to try to build it first and see where it fails. One issue with such a scenario (in any model) is that ICE candidates decay quickly, due to NAT timeouts and so on. You need to refresh them before use - and that's independent of offer/answer. --------------050008090106060403080802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/12/2012 11:30 PM, Roman Shpount wrote:

On Wed, Dec 12, 2012 at 12:46 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Of course, there is no need to re-write everything in JSEP. For example, I still think the negotiation part shall be RFC3264.

I actually not 100% convinced that this should be the case (I know that consensus is against me).

I'm not 100% convinced either, but I don't find your arguments compelling.

Main issues that I have against basing the API on RFC 3264 are:

1. This forces to negotiate transport parameters (ice candidates, encryption keys) every time encoding parameters are changed. I do not see a reason why we need to run ice state machine and re-negotiate encryption to add or remove a bundled video stream or change encoding. To do this efficiently we need to have a side channel and additional operations to RFC 3264
I don't know that this is the case. If RFC 3264 renegotiation is done without changing the crypto and transport parameters from what's currently in force, I can't see why the ICE and crypto state machines should change.

2. Dealing with parameters which are not negotiated via RFC 3264 is cumbersome. For instance, how would you specify the complexity for OPUS encoder? You would most likely need some other side channel.
Doesn't OPUS do that in-band?
If complexity needs to be specified before starting an OPUS connection, that is needed when OPUS is used in SIP too - so we're reducing this to a problem that needs to be solved anyway.

3. Offer answer is not the only available scenario. One thing that was discussed that each game or conference participant generates an offer, keeps it active for the duration of the conference and sends it to the server, where it is cached. When new participant joins the conference, it gets cached offers for all the other participants from the server and generates answers to them. This removes an extra signaling hop but impossible with current API.
I'm not sure it's impossible. I'd like to try to build it first and see where it fails.

One issue with such a scenario (in any model) is that ICE candidates decay quickly, due to NAT timeouts and so on. You need to refresh them before use - and that's independent of offer/answer.

--------------050008090106060403080802-- From christer.holmberg@ericsson.com Thu Dec 13 06:32:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC0821F86F9 for ; Thu, 13 Dec 2012 06:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzxvGkuEVlcD for ; Thu, 13 Dec 2012 06:32:57 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A44CD21F8949 for ; Thu, 13 Dec 2012 06:32:55 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-d5-50c9e7166381 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6D.8A.24873.617E9C05; Thu, 13 Dec 2012 15:32:54 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0318.001; Thu, 13 Dec 2012 15:32:53 +0100 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Fwd: [MMUSIC] SDP work needed for WebRTC stuff Thread-Index: AQHN1/WQMjcsuyAsPU+RLeFGUyQNV5gUPh/3///5KoCAAG/RsIABCO0AgADC5ACAAFdT0A== Date: Thu, 13 Dec 2012 14:32:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B054E15@ESESSMB209.ericsson.se> References: <50C7BECB.7050802@matthew.at> <9DA41D9D-39E0-46C7-A462-86FEBC1301AF@matthew.at> <7594FB04B1934943A5C02806D1A2204B0538CD@ESESSMB209.ericsson.se> <50C9A91E.10505@alvestrand.no> In-Reply-To: <50C9A91E.10505@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvja7Y85MBBqvvSlgc6+tis1j7r53d gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr41vWEreCtQMWkdRsZGxjX83YxcnJICJhI vDm1khXCFpO4cG89WxcjF4eQwCFGiTlH/7CDJIQEljBKnFhl38XIwcEmYCHR/U8bJCwiECzR +/w9I0hYWMBF4sdtc4iwq8SHtq/MEHaYxJxVnxlBbBYBVYnejx1gcV4Bb4nz2+YwQqw6xySx aMsLsFWcAtoS1z4cBLMZge75fmoNE4jNLCAucevJfCaIOwUkluw5zwxhi0q8fPyPFeQGCQFF ieX9chDlOhILdn9ig7C1JZYtfA21V1Di5MwnLBMYRWchmToLScssJC2zkLQsYGRZxciem5iZ k15utIkRGAcHt/xW3cF455zIIUZpDhYlcV7rrXv8hQTSE0tSs1NTC1KL4otKc1KLDzEycXBK NTCG33jKneJ1r1WEu/1jjg/Lh2tzW0yKn95Zeu2eqWfGne9cBkuivrasYa284t1wUU2ZJ5Ot xeYin/uXYHnuBRscrY9qJFctUhKpb1l1pjIvadYdo4Xmq77tuqLiJ923LXy7y8dd82/dmyX7 JWYab0Xhgb9FHr4Z7Om5Nz57zPz69acMs22NpLISS3FGoqEWc1FxIgDDEsT1UQIAAA== Subject: Re: [rtcweb] Fwd: [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Dec 2012 14:32:59 -0000 Hi, >>>Of course, there is no need to re-write everything in JSEP. For example,= I still think the negotiation part shall be RFC3264. >> >>I actually not 100% convinced that this should be the case (I know that c= onsensus is against me). > > I'm not 100% convinced either, but I don't find your arguments compelling= . > >> Main issues that I have against basing the API on RFC 3264 are: >> >> 1. This forces to negotiate transport parameters (ice candidates, encryp= tion keys) every time encoding parameters are changed. I do not see a reaso= n=20 >> why we need to run ice state machine and re-negotiate encryption to add = or remove a bundled video stream or change encoding. To do this efficiently= we need to have a side channel and additional operations to RFC 3264 > > I don't know that this is the case. If RFC 3264 renegotiation is done wit= hout changing the crypto and transport parameters from what's currently in = force, I can't see why the ICE and crypto state machines should change. I agree. The parameters do need to be present in any new SDP offer/answer, but if th= e values haven't changed it's just copies of the previous values. >> 3. Offer answer is not the only available scenario. One thing that was d= iscussed that each game or conference participant generates an offer, keeps= =20 >> it active for the duration of the conference and sends it to the server,= where it is cached. When new participant joins the conference, it gets cac= hed offers for all the other participants from the server and generates ans= wers to them.=20 >> This removes an extra signaling hop but impossible with current API. > I'm not sure it's impossible. I'd like to try to build it first and see w= here it fails. With SIP on the wire this "caching of offers" is probably not going to work= , but of course if you use offer/answer with some other protocol on the wir= e... In any case, I don't really see any harm in the server returning an answer = to the offer, and then sending a new offer to the participant when addition= al participant(s) join the conference. Regards, Christer From tterriberry@mozilla.com Thu Dec 13 06:52:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A688A21F8AFE for ; Thu, 13 Dec 2012 06:52:16 -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 Hr3c881Wz1Nc for ; Thu, 13 Dec 2012 06:52:16 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id ABB0221F8AA6 for ; Thu, 13 Dec 2012 06:52:13 -0800 (PST) Received: from [10.1.11.13] (173-164-135-225-SFBA.hfc.comcastbusiness.net [173.164.135.225]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 010BCF218C for ; Thu, 13 Dec 2012 06:52:09 -0800 (PST) Message-ID: <50C9EB99.7010805@mozilla.com> Date: Thu, 13 Dec 2012 06:52:09 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50C7BECB.7050802@matthew.at> <9DA41D9D-39E0-46C7-A462-86FEBC1301AF@matthew.at> <7594FB04B1934943A5C02806D1A2204B0538CD@ESESSMB209.ericsson.se> <50C9A91E.10505@alvestrand.no> In-Reply-To: <50C9A91E.10505@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Fwd: [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Dec 2012 14:52:23 -0000 Harald Alvestrand wrote: >> 2. Dealing with parameters which are not negotiated via RFC 3264 is >> cumbersome. For instance, how would you specify the complexity for >> OPUS encoder? You would most likely need some other side channel. > Doesn't OPUS do that in-band? I think his point was that this is a parameter which does not need to be negotiated at all: one side can decide it unilaterally and it has little effect on the other. This is what the constraints/settings API in the W3C is designed to tackle (and the W3C is where it should be tackled). You can call those APIs a "side channel", but I do not think they should be part of the same control surface for the same reasons that people regret having codec negotiation and transport setup intermingled in SDP. From roman@telurix.com Thu Dec 13 12:49:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A7121F8A53 for ; Thu, 13 Dec 2012 12:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.754 X-Spam-Level: X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[AWL=0.222, 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 i3urtMq27HXM for ; Thu, 13 Dec 2012 12:49:53 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 88F4D21F8842 for ; Thu, 13 Dec 2012 12:49:53 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so1737028pad.31 for ; Thu, 13 Dec 2012 12:49:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=PoqH5g8VvlY9jtW1vOe69THnJ+u7RRhf3l/4pla8awc=; b=jl5Ld//owe7thIKATplJ3p8S+NorMaMcobNTlQj7U94Uu86vhgBq+Nz8X3mvFzoE27 84LRXE8h4yIRtl7KS4AfrRc808iToNBUOZFf7VFL2FEdLLrZG5EfWoLkKAu10nkjuquC 7vUZbtfTd3vVFBunTYhPxjmsWAM4SSHOkJZzjMHqtyMQfTzLImtZ7CZ8gc5WnfR2j+nS Ck3bnTdDSBFQcLNMYfm685kG0FS4v6WR+/W8BwDx/eEXDZILC2g08tex5PPiEDKZKAZC snzkBEH31hHfHyHeyDx8hLZZz76o6l0tN48TANCtUdg8yVE3WwxgSntzIup8Y1UBPgT8 CVJg== Received: by 10.66.78.67 with SMTP id z3mr9521542paw.33.1355431793229; Thu, 13 Dec 2012 12:49:53 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by mx.google.com with ESMTPS id ot3sm1575957pbb.38.2012.12.13.12.49.51 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Dec 2012 12:49:52 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so1737014pad.31 for ; Thu, 13 Dec 2012 12:49:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.211.42 with SMTP id mz10mr9012447pbc.100.1355431791588; Thu, 13 Dec 2012 12:49:51 -0800 (PST) Received: by 10.68.42.8 with HTTP; Thu, 13 Dec 2012 12:49:51 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B054E15@ESESSMB209.ericsson.se> References: <50C7BECB.7050802@matthew.at> <9DA41D9D-39E0-46C7-A462-86FEBC1301AF@matthew.at> <7594FB04B1934943A5C02806D1A2204B0538CD@ESESSMB209.ericsson.se> <50C9A91E.10505@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B054E15@ESESSMB209.ericsson.se> Date: Thu, 13 Dec 2012 15:49:51 -0500 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=e89a8ff1ca3874758d04d0c20eed X-Gm-Message-State: ALoCoQkkjKYIVLZNLIJ9+2LTRXM7Gb95y7n2xF8KVZocVPTEq/u24ZM1AoW5+zdwita36cwxk6RM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Dec 2012 20:49:54 -0000 --e89a8ff1ca3874758d04d0c20eed Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 13, 2012 at 9:32 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: >> 1. This forces to negotiate transport parameters (ice candidates, > encryption keys) every time encoding parameters are changed. I do not see a > reason > >> why we need to run ice state machine and re-negotiate encryption to add > or remove a bundled video stream or change encoding. To do this efficiently > we need to have a side channel and additional operations to RFC 3264 > > > > I don't know that this is the case. If RFC 3264 renegotiation is done > without changing the crypto and transport parameters from what's currently > in force, I can't see why the ICE and crypto state machines should change. > > I agree. > > The parameters do need to be present in any new SDP offer/answer, but if > the values haven't changed it's just copies of the previous values. In case I need to add video, I would create a new offer, keep all the transport parameters from the previous offer, change the codec and media streams, set this as a local description. Now I send this to a remote party. First of all, there is no guarantee that remote party will give me the answer with the same transport parameters, so I should be prepared to renegotiate the transport. Second, I am not 100% I can just keep the transport parameters from the previous offer and set it to local description and just expect this to work. From my point of view it would be much cleaner if transport settings and codec settings were separate. It might not seem like a big deal, but these extra transport re-negotiations can lead to audible and visible glitches when new media streams are setup or turn down. > >> 3. Offer answer is not the only available scenario. One thing that was > discussed that each game or conference participant generates an offer, keeps > >> it active for the duration of the conference and sends it to the > server, where it is cached. When new participant joins the conference, it > gets cached offers for all the other participants from the server and > generates answers to them. > >> This removes an extra signaling hop but impossible with current API. > > I'm not sure it's impossible. I'd like to try to build it first and see > where it fails. > > With SIP on the wire this "caching of offers" is probably not going to > work, but of course if you use offer/answer with some other protocol on the > wire... > > In any case, I don't really see any harm in the server returning an answer > to the offer, and then sending a new offer to the participant when > additional participant(s) join the conference. > In this particular case SIP is not important. Not every application has interoperability requirements. Online game can very well only need to communicate with other instances of the same game and nothing else. In any case, would not it be nice to have transport parameters cached (advertised on some rendezvous server), and get each new party to open a data connection and then negotiate the rest of the codec parameters over this peer-to-peer connection. Yes, you can work around this by bouncing everything over the central server, but this can reduce number of round trips during the conference setup or make the round trips to be between the conference participants and not between participant to server to participant. _____________ Roman Shpount --e89a8ff1ca3874758d04d0c20eed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 13, 2012 at 9:32 AM, Christer Holmberg <= span dir=3D"ltr"><christer.holmberg@ericsson.com> wrote:

>> 1. This forces to negotiate transport parameters (ice cand= idates, encryption keys) every time encoding parameters are changed. I do n= ot see a reason
>> why we need to run ice state machine and re-negotiate encryption t= o add or remove a bundled video stream or change encoding. To do this effic= iently we need to have a side channel and additional operations to RFC 3264=
>
> I don't know that this is the case. If RFC 3264 renegotiation is d= one without changing the crypto and transport parameters from what's cu= rrently in force, I can't see why the ICE and crypto state machines sho= uld change.

I agree.

The parameters do need to be present in any new SDP offer/answer, but if th= e values haven't changed it's just copies of the previous values.

In case I need to add video, I would create = a new offer, keep all the transport parameters from the previous offer, cha= nge the codec and media streams, set this as a local description. Now I sen= d this to a remote party. First of all, there is no=A0guarantee=A0that remo= te party will give me the answer with the same transport parameters, so I s= hould be prepared to renegotiate the transport. Second, I am not 100% I can= just keep the transport parameters from the previous offer and set it to l= ocal description and just expect this to work. From my point of view it wou= ld be much cleaner if transport settings and codec settings were separate. = It might not seem like a big deal, but these extra transport re-negotiation= s can lead to=A0audible=A0and visible glitches when new media streams are s= etup or turn down.
=A0
>> 3. Offer answer is not the only available scenario. One thing that= was discussed that each game or conference participant generates an offer,= keeps
>> it active for the duration of the conference and sends it to the s= erver, where it is cached. When new participant joins the conference, it ge= ts cached offers for all the other participants from the server and generat= es answers to them.
>> This removes an extra signaling hop but impossible with current AP= I.
> I'm not sure it's impossible. I'd like to try to build it = first and see where it fails.

With SIP on the wire this "caching of offers" is probably n= ot going to work, but of course if you use offer/answer with some other pro= tocol on the wire...

In any case, I don't really see any harm in the server returning an ans= wer to the offer, and then sending a new offer to the participant when addi= tional participant(s) join the conference.

In this particular case SIP is not important. Not every application ha= s interoperability requirements. Online game can very well only need to com= municate with other instances of the same game and nothing else. In any cas= e, would not it be nice to have transport parameters cached (advertised on = some rendezvous server), and get each new party to open a data connection a= nd then negotiate the rest of the codec parameters over this peer-to-peer c= onnection. Yes, you can work around this by bouncing everything over the ce= ntral server, but this can reduce number of round trips during the conferen= ce setup or make the round trips to be between the conference participants = and not between participant to server to participant.
_____________
Roman Shpount

--e89a8ff1ca3874758d04d0c20eed-- From roman@telurix.com Thu Dec 13 12:53:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E71221F8B13 for ; Thu, 13 Dec 2012 12:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.791 X-Spam-Level: X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[AWL=0.185, 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 DMN0vxQ4q9dh for ; Thu, 13 Dec 2012 12:53:50 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id C23AA21F8B01 for ; Thu, 13 Dec 2012 12:53:50 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so1739162pad.31 for ; Thu, 13 Dec 2012 12:53:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=z596r58qtpoyNywk9gc3O+KDHip+N5R4Ex6wVh7AaZI=; b=iyAAL+fFs5iiWb6I8/F7a8ztZlYPZFuPxPX0aB0uOoQqxQzODFwrPcHtHYxKJnMc+o 2QFWt4ZomiAGYnHfZgK3c4tbIDPKOXQN+uCIMTx7Vn/T9q0od7jAvhJTUZRR4vMI/b05 b0GzEVxvrMMEvYfw1Q4Iz2/o93TFUFlwHGfqxpOnXkWQxWNUrkTniHZuzDHyKJUOsiRG djBALm93mmN3/+pqJbGeax7wqVy8xG4wWV897GFSpARWYLQMUc2aaH74ieFlV52MLUWJ /oaZ7sQOucl7h6OQN5ro/21c4oMwLtdjVS1k4aahyCOAnHQrxh6l4SxvXedQbGpG02cY OknQ== Received: by 10.68.230.200 with SMTP id ta8mr9047613pbc.13.1355432030471; Thu, 13 Dec 2012 12:53:50 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id nw9sm1579680pbb.42.2012.12.13.12.53.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Dec 2012 12:53:49 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so971942dae.31 for ; Thu, 13 Dec 2012 12:53:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.232.101 with SMTP id tn5mr7652619pbc.125.1355432029261; Thu, 13 Dec 2012 12:53:49 -0800 (PST) Received: by 10.68.42.8 with HTTP; Thu, 13 Dec 2012 12:53:49 -0800 (PST) In-Reply-To: <50C9EB99.7010805@mozilla.com> References: <50C7BECB.7050802@matthew.at> <9DA41D9D-39E0-46C7-A462-86FEBC1301AF@matthew.at> <7594FB04B1934943A5C02806D1A2204B0538CD@ESESSMB209.ericsson.se> <50C9A91E.10505@alvestrand.no> <50C9EB99.7010805@mozilla.com> Date: Thu, 13 Dec 2012 15:53:49 -0500 Message-ID: From: Roman Shpount To: "Timothy B. Terriberry" Content-Type: multipart/alternative; boundary=047d7b33d82e9f0fa404d0c21ce5 X-Gm-Message-State: ALoCoQmrNsIxgxQJU+r1G9ecfNXm4ctTZE3IycRbWJVsZrSTEuZBHTc7euUvKVkTqwKcV/sC1dD5 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Dec 2012 20:53:51 -0000 --047d7b33d82e9f0fa404d0c21ce5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 13, 2012 at 9:52 AM, Timothy B. Terriberry < tterriberry@mozilla.com> wrote: > Harald Alvestrand wrote: > >> 2. Dealing with parameters which are not negotiated via RFC 3264 is >>> cumbersome. For instance, how would you specify the complexity for >>> OPUS encoder? You would most likely need some other side channel. >>> >> Doesn't OPUS do that in-band? >> > > I think his point was that this is a parameter which does not need to be > negotiated at all: one side can decide it unilaterally and it has little > effect on the other. This is what the constraints/settings API in the W3C > is designed to tackle (and the W3C is where it should be tackled). You can > call those APIs a "side channel", but I do not think they should be part of > the same control surface for the same reasons that people regret having > codec negotiation and transport setup intermingled in SDP. > > Not that it is terribly important right now, but current Chromium and Firefox code, which is based on VoiceEngine does not allow setting any of the non-negotiated or negotiated codec specific parameters, such as encoder complexity, at all. In any case, application developer should be able to change these non-negotiated codec parameters, change codecs used to transmit, enable/disable comfort noise, etc at any time without going through offer/answer or adding or removing media tracks. _____________ Roman Shpount --047d7b33d82e9f0fa404d0c21ce5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 9:52 AM, Timothy B. Terriberry &l= t;tterriberry@= mozilla.com> wrote:
Harald Alvestrand wrote:
2. Dealing with parameters which are not negotiated via RFC 3264 is
cumbersome. For instance, how would you specify the complexity for
OPUS encoder? You would most likely need some other side channel.
Doesn't OPUS do that in-band?

I think his point was that this is a parameter which does not need to be ne= gotiated at all: one side can decide it unilaterally and it has little effe= ct on the other. This is what the constraints/settings API in the W3C is de= signed to tackle (and the W3C is where it should be tackled). You can call = those APIs a "side channel", but I do not think they should be pa= rt of the same control surface for the same reasons that people regret havi= ng codec negotiation and transport setup intermingled in SDP.


Not that= it is terribly important right now, but current Chromium and Firefox code,= which is based on VoiceEngine does not allow setting any of the non-negoti= ated or negotiated codec specific parameters, such as encoder complexity, a= t all.=A0

In any case, application developer should be able to ch= ange these non-negotiated codec parameters, change codecs used to transmit,= enable/disable comfort noise, etc at any time without going through offer/= answer or adding or removing media tracks.
_____________
Roman Shpount

=A0
--047d7b33d82e9f0fa404d0c21ce5-- From christer.holmberg@ericsson.com Fri Dec 14 01:59:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F64721F86C3 for ; Fri, 14 Dec 2012 01:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJYl14R64Rq3 for ; Fri, 14 Dec 2012 01:59:11 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8E321F8750 for ; Fri, 14 Dec 2012 01:59:11 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-a6-50caf86df469 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7B.0B.04318.D68FAC05; Fri, 14 Dec 2012 10:59:10 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0318.001; Fri, 14 Dec 2012 10:59:09 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [rtcweb] Fwd: [MMUSIC] SDP work needed for WebRTC stuff Thread-Index: AQHN1/WQMjcsuyAsPU+RLeFGUyQNV5gUPh/3///5KoCAAG/RsIABCO0AgADC5ACAAFdT0IAAW96AgADoBWA= Date: Fri, 14 Dec 2012 09:59:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B055680@ESESSMB209.ericsson.se> References: <50C7BECB.7050802@matthew.at> <9DA41D9D-39E0-46C7-A462-86FEBC1301AF@matthew.at> <7594FB04B1934943A5C02806D1A2204B0538CD@ESESSMB209.ericsson.se> <50C9A91E.10505@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B054E15@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+JvjW7ej1MBBkt/sVoc6+tis5hxYSqz xdp/7ewOzB5XJlxh9Viy5CeTx60pBQHMUVw2Kak5mWWpRfp2CVwZa86IFKyRrjjT+IOtgfGF aBcjJ4eEgInEr8nr2SFsMYkL99azdTFycQgJHGKU6G7ZCOUsYZRomXSYqYuRg4NNwEKi+582 SIOIgKrE3++TmUBsZoFgid6uyawgJcICLhI/bptDlLhKfGj7ygxhJ0msXrqNBcRmAWp9/HIr WJxXwFvi1Lw+JohV15kluk5sBktwCgRKNH7/zQZiMwId9/3UGqhd4hK3nsxngjhaQGLJnvPM ELaoxMvH/8BukBBQlFjeLwdRridxY+oUNghbW2LZwtdQewUlTs58wjKBUWwWkqmzkLTMQtIy C0nLAkaWVYzsuYmZOenl5psYgRFzcMtvgx2Mm+6LHWKU5mBREufVU93vLySQnliSmp2aWpBa FF9UmpNafIiRiYNTqoFR3CDp6rpC+zX8dzgKz2fmHzuaUla58taiCz9F7q/8PGNPxvXvb9+X bzrJPMdn9VvmRX9dd2TsOnbd9mPC8S9tCVU2r64V58l9KJU88yz2dVuE3AfzM+WZk98JMHV9 +u99e8eMp+sPCa09I2xueTzRYPHX7/Hh52NmBUq5dp+9wKw6LyymWOwEsxJLcUaioRZzUXEi AHpuzBVmAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Dec 2012 09:59:12 -0000 Hi, >>>> 1. This forces to negotiate transport parameters (ice candidates, encr= yption keys) every time encoding parameters are changed. I do not see a rea= son >>>> why we need to run ice state machine and re-negotiate encryption to ad= d or remove a bundled video stream or change encoding. To do this efficient= ly we need to have a side channel and additional operations to RFC 3264 >>> >>> I don't know that this is the case. If RFC 3264 renegotiation is done w= ithout changing the crypto and transport parameters from what's currently i= n force, I can't see why the ICE and crypto state machines should change. >> >> I agree. >> >> The parameters do need to be present in any new SDP offer/answer, but if= the values haven't changed it's just copies of the previous values. > > In case I need to add video, I would create a new offer, keep all the tra= nsport parameters from the previous offer, change the codec and media strea= ms, set this as a local description. Now I send this=20 > to a remote party. First of all, there is no=A0guarantee=A0that remote pa= rty will give me the answer with the same transport parameters, so I should= be prepared to renegotiate the transport. Sure. But, the remote party could as well send you a new offer, which would= trigger renegotiation. (I don't think the remote party will change the parameters simply because i= t can - there needs to be a reason for it) > Second, I am not 100% I can just keep the transport parameters from the p= revious offer and set it to local description and just expect this to work. IF the transport parameters change you will need to indicate that no matter= what. > From my point of view it would be much cleaner if transport settings and = codec settings were separate. It might not seem like a big deal, but=20 > these extra transport re-negotiations can lead to=A0audible=A0and visible= glitches when new media streams are setup or turn down. >=A0 >>> 3. Offer answer is not the only available scenario. One thing that was = discussed that each game or conference participant generates an offer, keep= s >>> it active for the duration of the conference and sends it to the server= , where it is cached. When new participant joins the conference, it gets ca= ched offers for all the other participants from the server and generates an= swers to them. >>> This removes an extra signaling hop but impossible with current API. >>> I'm not sure it's impossible. I'd like to try to build it first and see= where it fails. >> >> With SIP on the wire this "caching of offers" is probably not going to w= ork, but of course if you use offer/answer with some other protocol on the = wire... >> >> In any case, I don't really see any harm in the server returning an answ= er to the offer, and then sending a new offer to the participant when addit= ional participant(s) join the conference. > > In this particular case SIP is not important. Not every application has i= nteroperability requirements. Online game can very well only need to commun= icate with other=20 > instances of the same game and nothing else. In any case, would not it be= nice to have transport parameters cached (advertised on some rendezvous se= rver), and=20 > get each new party to open a data connection and then negotiate the rest = of the codec parameters over this peer-to-peer connection.=20 Based on the consensus, obviously not :) Regards, Christer From ibc@aliax.net Fri Dec 14 06:03:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725A321F85AE for ; Fri, 14 Dec 2012 06:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 sP-pDSZkqYoa for ; Fri, 14 Dec 2012 06:03:34 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A66921F8455 for ; Fri, 14 Dec 2012 06:03:33 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2785786lah.31 for ; Fri, 14 Dec 2012 06:03:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=SK9EDFIRbm0/it3VZGkucSJQgV6YPsHNGKZtST4oaho=; b=oIMf81EhQV93luZglh06wUcGlOrRkK6+lrkfuPGFbvWcEbb7gOp2D+uridNP/xVfiw Ow1xo/ZUhH1mDFJ8Poec107DIDcWU0TTJA8la0rfNTs2hM3jKPPtdzQP0cMGawEji4F4 GYLbnE/Gcx9aRXTOnRMLEFUyhdFCNffA0UNkgpZ/ktSZJclbsjifYGtON9uH+yUJ8oFq 0B5PIVSFN1Gtk+qlgq284bH8QTvqOkf051mNwO89rXVuoG2R4AYXd0OoDz5OL4ZSErK9 +/ASOc6Py7dEbpDI2Ufvk1831TdZD4jvF898nQ9hIHKUTfxHqsMG7FxFExfzko9gjJBM XwQg== Received: by 10.152.125.136 with SMTP id mq8mr2829783lab.41.1355493812348; Fri, 14 Dec 2012 06:03:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.1.237 with HTTP; Fri, 14 Dec 2012 06:03:12 -0800 (PST) In-Reply-To: <926732C8-C4FE-441B-AA7B-BE55F766569A@microsoft.com> References: <017c01cdcc26$1c1e8c40$545ba4c0$@us> <926732C8-C4FE-441B-AA7B-BE55F766569A@microsoft.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 14 Dec 2012 15:03:12 +0100 Message-ID: To: Francois Audet Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkbZZ9omCNEU6b4Zuapy6QQpg4OAbOhOwmiL94j8VvdBTsr4fH4f6eu8X817Xdi25PVkqmw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of 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, 14 Dec 2012 14:03:34 -0000 2012/11/27 Francois Audet : > Fax on H.323 was ridiculous back then, even more so over SIP. Now, with > RTCwebit's totally Steam Punk! Next stop Telegraph over rtcweb? Maybe AT commands... --=20 I=C3=B1aki Baz Castillo From oej@edvina.net Fri Dec 14 06:13:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E89921F8519 for ; Fri, 14 Dec 2012 06:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqa9WHCqiYGE for ; Fri, 14 Dec 2012 06:13:34 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 17B4521F850E for ; Fri, 14 Dec 2012 06:13:33 -0800 (PST) Received: from [192.168.40.36] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id CEFB6754A8AA; Fri, 14 Dec 2012 14:13:29 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 14 Dec 2012 15:13:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <017c01cdcc26$1c1e8c40$545ba4c0$@us> <926732C8-C4FE-441B-AA7B-BE55F766569A@microsoft.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1499) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of 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, 14 Dec 2012 14:13:34 -0000 14 dec 2012 kl. 15:03 skrev I=F1aki Baz Castillo : > 2012/11/27 Francois Audet : >> Fax on H.323 was ridiculous back then, even more so over SIP. Now, = with >> RTCwebit's totally Steam Punk! Next stop Telegraph over rtcweb? >=20 > Maybe AT commands... Over the data channel API. With WebRTC we can finally signal in morse code with flashlamps. That's = tunneling! IP over morse code over WebRTC. Soon weekend. Sorry for the interruption :-) /O= From harald@alvestrand.no Fri Dec 14 08:05:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF98821F88CB for ; Fri, 14 Dec 2012 08:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.49 X-Spam-Level: X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 4RUUfgG9yF+f for ; Fri, 14 Dec 2012 08:05:24 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1942D21F858E for ; Fri, 14 Dec 2012 08:05:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E491F39E1C6 for ; Fri, 14 Dec 2012 17:05:22 +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 23sPrKHatdtw for ; Fri, 14 Dec 2012 17:05: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 9BCFE39E1C0 for ; Fri, 14 Dec 2012 17:05:19 +0100 (CET) Message-ID: <50CB4E3E.8080402@alvestrand.no> Date: Fri, 14 Dec 2012 17:05:18 +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: <017c01cdcc26$1c1e8c40$545ba4c0$@us> <926732C8-C4FE-441B-AA7B-BE55F766569A@microsoft.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of 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, 14 Dec 2012 16:05:25 -0000 On 12/14/2012 03:13 PM, Olle E. Johansson wrote: > 14 dec 2012 kl. 15:03 skrev Iñaki Baz Castillo : > >> 2012/11/27 Francois Audet : >>> Fax on H.323 was ridiculous back then, even more so over SIP. Now, with >>> RTCwebit's totally Steam Punk! Next stop Telegraph over rtcweb? >> Maybe AT commands... > Over the data channel API. > > With WebRTC we can finally signal in morse code with flashlamps. That's tunneling! > > IP over morse code over WebRTC. Too low level. We need a flashlamp emulator written in Javascript that we can transmit over the data channel and have executed at the remote end, which interfaces to a canvas element from which we generate a video of the flashing light; at the receiving end that is in turn is connected to an eye simulator that drives a neural network that has been trained to recognize Morse signals. THEN we can start running IP over it. > > Soon weekend. Sorry for the interruption :-) > /O > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From internet-drafts@ietf.org Fri Dec 14 08:19:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47BA21F890E; Fri, 14 Dec 2012 08:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 uQpfp1nX3ySx; Fri, 14 Dec 2012 08:19:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4507221F891F; Fri, 14 Dec 2012 08:19:14 -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.36 Message-ID: <20121214161914.10857.21113.idtracker@ietfa.amsl.com> Date: Fri, 14 Dec 2012 08:19:14 -0800 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-05.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, 14 Dec 2012 16:19:14 -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 : Overview: Real Time Protocols for Brower-based Applicati= ons Author(s) : Harald T. Alvestrand Filename : draft-ietf-rtcweb-overview-05.txt Pages : 22 Date : 2012-12-14 Abstract: This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is a work item of the RTCWEB working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-overview-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-overview-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From harald@alvestrand.no Fri Dec 14 08:21:30 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9897B21F898D for ; Fri, 14 Dec 2012 08:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.495 X-Spam-Level: X-Spam-Status: No, score=-110.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 17l4ZEK+psPg for ; Fri, 14 Dec 2012 08:21:30 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id EF73421F894D for ; Fri, 14 Dec 2012 08:21:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0037C39E1AC for ; Fri, 14 Dec 2012 17:21:29 +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 gQysaNZgcK22 for ; Fri, 14 Dec 2012 17:21:28 +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 16B4239E13B for ; Fri, 14 Dec 2012 17:21:27 +0100 (CET) Message-ID: <50CB5206.4070101@alvestrand.no> Date: Fri, 14 Dec 2012 17:21: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: <20121214161914.10857.21113.idtracker@ietfa.amsl.com> In-Reply-To: <20121214161914.10857.21113.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-05.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, 14 Dec 2012 16:21:30 -0000 Since there has been very little debate over the overview draft over the last 6 months, this is mainly a stay-alive refresh and an opportunity to fix some grammar and spelling mistakes. Harald On 12/14/2012 05:19 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. > > Title : Overview: Real Time Protocols for Brower-based Applications > Author(s) : Harald T. Alvestrand > Filename : draft-ietf-rtcweb-overview-05.txt > Pages : 22 > Date : 2012-12-14 > > Abstract: > This document gives an overview and context of a protocol suite > intended for use with real-time applications that can be deployed in > browsers - "real time communication on the Web". > > It intends to serve as a starting and coordination point to make sure > all the parts that are needed to achieve this goal are findable, and > that the parts that belong in the Internet protocol suite are fully > specified and on the right publication track. > > This document is a work item of the RTCWEB working group. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-overview-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Mon Dec 17 01:18:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5161321F8A6D for ; Mon, 17 Dec 2012 01:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.208 X-Spam-Level: X-Spam-Status: No, score=-106.208 tagged_above=-999 required=5 tests=[AWL=0.041, 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 iaiX0CNLEjbg for ; Mon, 17 Dec 2012 01:18:00 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id ED3C021F8A62 for ; Mon, 17 Dec 2012 01:17:59 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-bc-50cee343fb07 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4F.F2.24873.343EEC05; Mon, 17 Dec 2012 10:17:55 +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; Mon, 17 Dec 2012 10:17:54 +0100 Message-ID: <50CEE339.3020000@ericsson.com> Date: Mon, 17 Dec 2012 10:17:45 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPJMWRmVeSWpSXmKPExsUyM+Jvja7z43MBBvtua1t0TGazWPuvnd2i ca6dA7PHlN8bWT12zrrL7rFkyU+mAOYoLpuU1JzMstQifbsEroxv13kLjrNWnNhymrWB8SxL FyMnh4SAicSTN+/ZIWwxiQv31rOB2EICJxklPp8L6mLkArKXM0pcnvMbrIFXQFuicdNRZhCb RUBVomXTXLAGNgELiZs/GsFsUQFfiVl7fjFB1AtKnJz5BKxXREBd4vLDC2DLmAXcJeYdfAcW FxbQkOibuBvqIEmJRdM6WSBq9CSmXG1hhLDlJZq3zmaGOE5boqGpg3UCo8AsJCtmIWmZhaRl ASPzKkb23MTMnPRyo02MwEA8uOW36g7GO+dEDjFKc7AoifNab93jLySQnliSmp2aWpBaFF9U mpNafIiRiYNTqoFxrcnHyYrBO0NW8Xev9XFg3/5HqneN5tTZP3s1Av4f2WDz4yWP5/+ImoZ6 jk+an3cc35lx9fTsds16xtD79+orns8+HlXDFhgYp9fNvFRKpWafqPGn093rtUKtDzm6b8rf EHW5dbOo2Hz176KG6T7mrJYO2qoLrxm8rp+noOch4Jd6SOnEhiglluKMREMt5qLiRAAPS1vP EgIAAA== Cc: Cullen Jennings Subject: [rtcweb] Agenda Items for 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: Mon, 17 Dec 2012 09:18:01 -0000 WG, Document editors, WG participants. Please indicate what issues and topics that you believe should be discussed at the WG's interim meeting in February. Please do this this week, i.e. before Christmas Eve (24th of December). 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 harald@alvestrand.no Mon Dec 17 01:28:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CBE21F895C for ; Mon, 17 Dec 2012 01:28:51 -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 i+xgtbCtX7tk for ; Mon, 17 Dec 2012 01:28:50 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A821A21F8957 for ; Mon, 17 Dec 2012 01:28:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AF65139E1C9 for ; Mon, 17 Dec 2012 10:28:46 +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 TyfqGC8oT+dl for ; Mon, 17 Dec 2012 10:28:45 +0100 (CET) Received: from [172.28.90.88] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D045739E129 for ; Mon, 17 Dec 2012 10:28:44 +0100 (CET) Message-ID: <50CEE5CB.3020903@alvestrand.no> Date: Mon, 17 Dec 2012 10:28:43 +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: <50CEE339.3020000@ericsson.com> In-Reply-To: <50CEE339.3020000@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [rtcweb] Request for -overview time (Re: Agenda Items for 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: Mon, 17 Dec 2012 09:28:51 -0000 On 12/17/2012 10:17 AM, Magnus Westerlund wrote: > WG, > > Document editors, WG participants. Please indicate what issues and > topics that you believe should be discussed at the WG's interim meeting > in February. Please do this this week, i.e. before Christmas Eve (24th > of December). Speaking as -overview editor: Please set aside some time for disposing of last-call issues (provided you issue a last call) for -overview. If this isn't settled by discussion before the meeting, please also set aside time for deciding the proper disposition of the text currently stored in appendix A of 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 From magnus.westerlund@ericsson.com Tue Dec 18 02:50:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D5421F866D for ; Tue, 18 Dec 2012 02:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.214 X-Spam-Level: X-Spam-Status: No, score=-106.214 tagged_above=-999 required=5 tests=[AWL=0.035, 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 vI3jc2+TtdzA for ; Tue, 18 Dec 2012 02:50:05 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DB28F21F868F for ; Tue, 18 Dec 2012 02:50:04 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-07-50d04a5b9980 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 35.61.10459.B5A40D05; Tue, 18 Dec 2012 11:50:03 +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; Tue, 18 Dec 2012 11:50:02 +0100 Message-ID: <50D04A5A.80607@ericsson.com> Date: Tue, 18 Dec 2012 11:50:02 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> In-Reply-To: <50B87606.5030802@ericsson.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBJMWRmVeSWpSXmKPExsUyM+JvjW6014UAgyuzNSzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRv+8iUwFW7kqPi39wdLAuJqji5GTQ0LARGLF8ZnsELaYxIV7 69lAbCGBk4wSWzabQdjLGSVaz1eC2LwCmhIrb6xgArFZBFQllt37xQxiswlYSNz80QjWKyrg KzFrzy8miHpBiZMzn7CA2CICwhJbX/UCxTk4hAXMJa5fKYAYry0x9+MjsBJOAR2J1fe2sECc IymxaFonmM0soCcx5WoLI4QtL9G8dTYzTG9DUwfrBEbBWUi2zULSMgtJywJG5lWM7LmJmTnp 5YabGIGhd3DLb90djKfOiRxilOZgURLnDXO9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB seuD+GKlUH6NzQvFwt5e/2zk9bJI0rfFveDF07UqzC2T4oUn1fNX7xX93OR751B8ZdMjj38P v5vs/vxvJbP6tcWaLn6O2bJeyjVphn/fv4pReWPhqzWTp2r7knVsFxk/ha6wb02vWeT/uGev tt+V/7//qD1d/yxv0pG700+W8bXdCH0azxGyU4mlOCPRUIu5qDgRAF/7C7MLAgAA Subject: [rtcweb] Result of Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Dec 2012 10:50:05 -0000 WG, We have been running a consensus call regarding Text Communication in RTCWEB. The consensus call did not result in any clear conclusions. However a couple of observations we chairs can make. - There is interest in providing an inter-operable solution for real-time text communication - Some participants believe that the data channel can be part of a solution. - There has also been discussion regarding using T.140 over RTP. - A lot of questions on what amount if any of standardization that is required to provide the functionality. We don't see any consensus on the approach at this point. We recommend that the people interested write individual drafts that clarify their approaches for the WG; this may also help the WG understand if this is primarily an issue for the IETF or the W3C. Regards Magnus Westerlund As WG chair ---------------------------------------------------------------------- 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 dwing@cisco.com Tue Dec 18 22:47:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B7721F8A0A for ; Tue, 18 Dec 2012 22:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.494 X-Spam-Level: X-Spam-Status: No, score=-110.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 qtqNOrrsdSMk for ; Tue, 18 Dec 2012 22:47:34 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id B744721F8711 for ; Tue, 18 Dec 2012 22:47:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=593; q=dns/txt; s=iport; t=1355899654; x=1357109254; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=oFF/jrAJ2ps9TVVH0TIVl1vwEBxGnx2rUIPtwINCgHA=; b=I18H6Xi55FNies9QfY04GgTYlAejdhfI5Ki8gTry2sGr571fpKWMB8c0 Mb4LTsrNWqjzu9PanbvPgz1ANkkRyl7+yP1/5/qsFdlxTURpr3X7/m2/a l+9qEfrVl9UhB7MQU6Xqg8v4fO1+9bCdq0B7tjM6bbEmuJiWGX2iXia6F 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksHALpi0VCrRDoG/2dsb2JhbAA8CYNIgiy4LxZzgiUIAjBMBRtNMA8BBB4FiAINlyuREZAajF2BCIMpA4hhhRyIDYEcjyyDFQ X-IronPort-AV: E=Sophos;i="4.84,313,1355097600"; d="scan'208";a="63829423" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 19 Dec 2012 06:47:34 +0000 Received: from DWINGWS01 ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBJ6lYEn006009 for ; Wed, 19 Dec 2012 06:47:34 GMT From: "Dan Wing" To: Date: Tue, 18 Dec 2012 22:47:34 -0800 Message-ID: <0f7501cdddb4$b9c0e250$2d42a6f0$@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: Ac3dtCX/orQ3RpleSjWSrD15V9Eh9Q== Content-Language: en-us Subject: [rtcweb] Problems with Security Descriptions in RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 06:47:35 -0000 I just published a summary of the problems specific to RTCWEB if Security Descriptions is part of the RTCWEB architecture (that is, if voice calls can use Security Descriptions to key SRTP). The two major problems with Security Descriptions in RTCWEB described in the document are (a) passive listening by SIP signaling entities whenever a Security Description call leg is added (two party calls or three party calls), and (b) impossible to prove remote user's identity. Draft is here, http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems Comments welcome. -d From internet-drafts@ietf.org Wed Dec 19 04:37:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F8821F8AC4; Wed, 19 Dec 2012 04:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 7y7xDUTjl2Ml; Wed, 19 Dec 2012 04:37:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175DB21F8AD8; Wed, 19 Dec 2012 04:37:45 -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: <20121219123745.24792.31546.idtracker@ietfa.amsl.com> Date: Wed, 19 Dec 2012 04:37:45 -0800 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-10.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, 19 Dec 2012 12:37:45 -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 : Web Real-Time Communication Use-cases and Requirements Author(s) : Christer Holmberg Stefan Hakansson Goran AP Eriksson Filename : draft-ietf-rtcweb-use-cases-and-requirements-10.txt Pages : 28 Date : 2012-12-19 Abstract: This document describes web based real-time communication use-cases. Based on the use-cases, the document also derives requirements related to the browser, and the API used by web applications to request and control media stream and data exchange services provided by the browser. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requiremen= ts There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-use-cases-and-requirem= ents-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christer.holmberg@ericsson.com Wed Dec 19 04:39:25 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C22521F8A0A for ; Wed, 19 Dec 2012 04:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 KgFqEqVs3o2z for ; Wed, 19 Dec 2012 04:39:24 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 27FAF21F8742 for ; Wed, 19 Dec 2012 04:39:23 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-ae-50d1b57bdd9b Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 81.DF.10459.B75B1D05; Wed, 19 Dec 2012 13:39:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.43]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 13:39:22 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: Draft new version: draft-ietf-rtcweb-use-cases-and-requirements-10 Thread-Index: Ac3d5b0oqQYJfj/fTWqc5MRlrDE/AQ== Date: Wed, 19 Dec 2012 12:39:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B06D051@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B06D051ESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvjW711osBBk1PeS3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqx539gKbohVtKy6xtjAOEeki5GTQ0LARKLvwh1mCFtM4sK9 9WxdjFwcQgKHGCXmfT/FBOEsZpTo3HsRyOHgYBOwkOj+pw3SICKgLnH54QV2EFtYwFviXON+ doh4kMTK7b9YIGw9iUVH7oMtYBFQlVh/YzIbiM0LVH+7qYkVxGYEWvz91BomEJtZQFzi1pP5 TBAHCUgs2XMe6jhRiZeP/7GCnCAhoCixvF8Oojxf4urvX0wQIwUlTs58wjKBUWgWkkmzkJTN QlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzGy5yZm5qSXG25iBAb9wS2/dXcwnjon cohRmoNFSZw3zPVCgJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGlW8iElPlXjparYore6Pj tvZ6R1/XJv3uD9wPZDtKkubuLypcWuVxQjh7Q0oXwwpf3h/urSG6+UejnRxSTqXk9Gy1/NSd In+0XiaSee4ux2b79e23qsU4L25Pf2VgY/U767JC9J2H+ms6zx4XTYw++KD9CrdP7Lwtkca6 t9Ru2vEVVVr7+iuxFGckGmoxFxUnAgDZutl9SAIAAA== Subject: [rtcweb] Draft new version: 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, 19 Dec 2012 12:39:25 -0000 --_000_7594FB04B1934943A5C02806D1A2204B06D051ESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We've submitted a new version (-10) of the use-case and requirements draft. The only difference from the previous version is a minor editorial change (= "video communication session" -> "audiovisual communication session"). Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B06D051ESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We’ve submitted a new version (-10) of the use= -case and requirements draft.

 

The only difference from the previous version is a m= inor editorial change (“video communication session” -> R= 20;audiovisual communication session”).

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B06D051ESESSMB209ericsso_-- From christer.holmberg@ericsson.com Wed Dec 19 07:55:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF2921F8583 for ; Wed, 19 Dec 2012 07:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 zhZ0q-SUhCBe for ; Wed, 19 Dec 2012 07:55:04 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4029F21F857D for ; Wed, 19 Dec 2012 07:55:04 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-37-50d1e357298a Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7E.67.24873.753E1D05; Wed, 19 Dec 2012 16:55:03 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.43]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 16:55:02 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: Support of video with different resolutions Thread-Index: Ac3eAPnQIvwgLiQDS2yGSHFqvIzF8g== Date: Wed, 19 Dec 2012 15:55:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B06E211@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B06E211ESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+JvjW7444sBBt8mylis/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMs/7rIXrLeumNR3kLGBcb5xFyMnh4SAicStT+/YIWwxiQv3 1rN1MXJxCAkcYpQ4O38aO4SzmFFi2ZaXzF2MHBxsAhYS3f+0QRpEBNQlLj+8wA4SFgYatPRy MUTYUuLkl9tMELaexOS3z9hAbBYBVYnJX46BTeEV8Ja4+CMSJMwItPb7qTVg5cwC4hK3nsxn gjhHQGLJnvPMELaoxMvH/1hBWiUEFCWW98tBlOdLbHo+DaycV0BQ4uTMJywTGIVmIZk0C0nZ LCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUje25iZk56udEmRmDAH9zyW3UH451z IocYpTlYlMR5w10vBAgJpCeWpGanphakFsUXleakFh9iZOLglGpgVNWuUuK5afb6rkTeXclD J6oiPz1P4MzTf9NmWif6PtK87sqc+eL1T5w4di848m7pSsn2LdY+iswpwf+EprndYjyo5xpR zHFu2ZUmw/brj88zf7kuxxkh1P0uUbV4ia6MQk+MaZfkT8sDL776vBefZiE2O32TOdcdnlAh Qcb/exZesfudOuGwEktxRqKhFnNRcSIA03IlJkYCAAA= Subject: [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, 19 Dec 2012 15:55:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B06E211ESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section 4.3.3.1 (description of the 'Video conferencing system with central server' use-case) of the use-case-and-requirements draft contains a note, describing different mechanisms for providing video streams with different resolution. "Note: This use-case adds requirements on support for fast = stream switches F7, on encryption of media and on ability to traverse very restrictive FWs. There exist several solution= s that enable the server to forward one high resolution and several low resolution video streams: a) each browser could send a high= resolution, but scalable stream, and the server could send just the base layer for the low resolution streams, b) each browser = could in a simulcast fashion send one high resolution and one low resolution stream, and the server just selects or c) each b= rowser sends just a high resolution stream, the server transcodes into low resolution streams as required." If we want to support content sent in different resolutions, the question i= s whether we need to mandate the browser to support a specific mechanism. As shown in the note, there are basically 3 mechanism: SVC, simulcast and "= local transcoding". The "local transcoding" alternative doesn't put any requirements on browsers. The SVC and simulcast alternatives would. However, the "local transcoding" alternative will consume lots of resources= , and as far as I know none of the proposed MTI video codecs support SVC. Some people have indicated support for simulcast in the past, but it would be nice to get a wider view. Opinions? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B06E211ESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Section 4.3.3.1 (description of the ‘Video con= ferencing system with

central server’ use-case) of the use-case-and-= requirements draft

contains a note, describing different mechanisms for= providing

video streams with different resolution.<= /p>

 

        &nbs= p;       “Note: This use-case adds requ= irements on support for fast stream switches F7, on encryption of media and= on ability to

        &nbs= p;       traverse very restrictive FWs. There= exist several solutions that enable the server to forward one high resolut= ion and several low

        &nbs= p;       resolution video streams: a) each br= owser could send a high resolution, but scalable stream, and the server cou= ld send just the

        &nbs= p;       base layer for the low resolution st= reams, b) each browser could in a simulcast fashion send one high resolutio= n and one low

        &nbs= p;       resolution stream, and the server ju= st selects or c) each browser sends just a high resolution stream, the serv= er transcodes into

low resolution streams = as required.”

If we want to support content sent in different reso= lutions, the question is whether we need to mandate the browser to support = a specific

mechanism.

 

As shown in the note, there are basically 3 mechanis= m: SVC, simulcast and “local transcoding”.

 

The “local transcoding” alternative does= n’t put any requirements on

browsers. The SVC and simulcast alternatives would.<= o:p>

 

However, the “local transcoding” alte= rnative will consume lots of resources,

and as far as I know none of the proposed MTI vid= eo codecs support SVC.

 

Some people have indicated support for simulcast = in the past, but it would

be nice to get a wider view.

 

Opinions?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B06E211ESESSMB209ericsso_-- From magnus.westerlund@ericsson.com Thu Dec 20 00:29:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086A521F84EE for ; Thu, 20 Dec 2012 00:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.217 X-Spam-Level: X-Spam-Status: No, score=-106.217 tagged_above=-999 required=5 tests=[AWL=0.032, 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 JgZA0IlAz3N6 for ; Thu, 20 Dec 2012 00:29:33 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4610F21F891C for ; Thu, 20 Dec 2012 00:29:32 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-90-50d2cc6b25bd Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 32.CB.24873.B6CC2D05; Thu, 20 Dec 2012 09:29:31 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Thu, 20 Dec 2012 09:29:31 +0100 Message-ID: <50D2CC6A.4090500@ericsson.com> Date: Thu, 20 Dec 2012 09:29:30 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMJMWRmVeSWpSXmKPExsUyM+JvjW72mUsBBg9fWlqs/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO4fbWwFfzkq7pw4zdbAuJy9i5GTQ0LARGLfk8OsELaYxIV7 69m6GLk4hAROMko0bfjKBOEsZ5T4vu8xE0gVr4C2RNOUo2wgNouAqsTm87/AbDYBC4mbPxrB bFEBX4lZe35B1QtKnJz5hAXEFhFQl7j88ALYZmEBD4m1576xQWyWlFg0rROshllAT2LK1RZG CFteonnrbGYQWwhob0NTB+sERv5ZSMbOQtIyC0nLAkbmVYzsuYmZOenlRpsYgQF1cMtv1R2M d86JHGKU5mBREucNd70QICSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHR9E2ISx0nUwv3kxtp fy63p2Tr/Ji7NdJ8Rsl+BkOflW45uj3MNowCXB7KU280GQhMFT72PvqS6uuwSd6Jb4U/LIg/ bv2yLJez7wDj13uJbh+Cb3uJ8Ig/7IqwVZ42Ib0n0WLavOagrR3LhJiP1L9ye73Yb9mDJx/W 7/QOdeZ/Y7RYQt7x+HslluKMREMt5qLiRADBYGXY9gEAAA== Subject: [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, 20 Dec 2012 08:29:34 -0000 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 ---------------------------------------------------------------------- From Markus.Isomaki@nokia.com Thu Dec 20 03:23:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875B121F87AD for ; Thu, 20 Dec 2012 03:23:58 -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 pivbWriFvnul for ; Thu, 20 Dec 2012 03:23:58 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id B12D821F87A6 for ; Thu, 20 Dec 2012 03:23:57 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qBKBNogv008892; Thu, 20 Dec 2012 13:23:50 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Dec 2012 13:23:50 +0200 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.185]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0318.003; Thu, 20 Dec 2012 11:23:49 +0000 From: To: , Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN3owmOUOVL5OmGUO4DZe3qRHxe5ghhaqQ Date: Thu, 20 Dec 2012 11:23:49 +0000 Message-ID: References: <50D2CC6A.4090500@ericsson.com> In-Reply-To: <50D2CC6A.4090500@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.81.137] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2012 11:23:50.0578 (UTC) FILETIME=[7C585920:01CDDEA4] X-Nokia-AV: Clean 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, 20 Dec 2012 11:23:58 -0000 Hi, I think we should make an attempt at 1), i.e. to at least find out if there= is a consensus on such as small set of recommended codecs. I don't know wh= at is small, but I would say no more than 1-3. And there has to be a convin= cing case for each why they add value over G.711 AND Opus. My proposal would be to recommend AMR, and perhaps AMR-WB. The rationale is= that those codecs are widely supported in mobile devices and in Circuit Sw= itched and IMS/LTE based VoIP telephony. So they are helpful for transcode-= free interoperability with the current and future :-) legacy systems, and i= n that dimension they would add value to G.711 and Opus. It is not a releva= nt use case for all WebRTC services, but to a large enough set I believe. Q= uite many people even proposed AMR/AMR-WB as mandatory for WebRTC. The main= reason it was not acceptable was the IPR situation, which quite a few saw = inhibitive. That has not changed, but I think the deliberations in that reg= ard are different for "recommended" than "mandatory". Markus >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of ext Magnus Westerlund >Sent: 20 December, 2012 10:30 >To: rtcweb@ietf.org >Subject: [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/spee= ch >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 From richard@shockey.us Thu Dec 20 11:16:21 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C0921F8A59 for ; Thu, 20 Dec 2012 11:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.188 X-Spam-Level: X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zLEeAkSby1D for ; Thu, 20 Dec 2012 11:16:21 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 2F0DD21F8A57 for ; Thu, 20 Dec 2012 11:16:21 -0800 (PST) Received: (qmail 18727 invoked by uid 0); 20 Dec 2012 19:15:45 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 20 Dec 2012 19:15:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=YyISOABFLJm3qnuaclLWQNAPcxDWkaw8HrTe40HNE3w=; b=gFfaRSwPMPnptJWavNis+iZPiQVpp1faoTuN9Vj7A0SGue7WK2TFqr6lDJu6ohMudWs7Qm9mAu1kCgZQMp6Csby0uoMazhOAkOT2Tl6lvZnGqPHM6xdpdjZst8cix0BZ; Received: from [71.191.243.130] (port=53685 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Tllam-000269-B7 for rtcweb@ietf.org; Thu, 20 Dec 2012 12:15:40 -0700 From: "Richard Shockey" To: References: <50D2CC6A.4090500@ericsson.com> In-Reply-To: Date: Thu, 20 Dec 2012 14:15:36 -0500 Message-ID: <000501cddee6$666ce7b0$3346b710$@us> 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: AQHN3owmOUOVL5OmGUO4DZe3qRHxe5ghhaqQgACJKzA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: Re: [rtcweb] 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, 20 Dec 2012 19:16:21 -0000 +1 .. 722 AMR AMR-WB was and still is the optimal choices for SHOULD. = That would cover interoperability with existing enterprise SIP PBX systems = and the VoLTE deployments that are rolling out now and will gather market momentum in 2014.=20 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Markus.Isomaki@nokia.com Sent: Thursday, December 20, 2012 6:24 AM To: magnus.westerlund@ericsson.com; rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Hi, I think we should make an attempt at 1), i.e. to at least find out if = there is a consensus on such as small set of recommended codecs. I don't know = what is small, but I would say no more than 1-3. And there has to be a = convincing case for each why they add value over G.711 AND Opus. My proposal would be to recommend AMR, and perhaps AMR-WB. The rationale = is that those codecs are widely supported in mobile devices and in Circuit Switched and IMS/LTE based VoIP telephony. So they are helpful for transcode-free interoperability with the current and future :-) legacy systems, and in that dimension they would add value to G.711 and Opus. = It is not a relevant use case for all WebRTC services, but to a large enough = set I believe. Quite many people even proposed AMR/AMR-WB as mandatory for = WebRTC. The main reason it was not acceptable was the IPR situation, which quite = a few saw inhibitive. That has not changed, but I think the deliberations = in that regard are different for "recommended" than "mandatory". Markus >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >Behalf Of ext Magnus Westerlund >Sent: 20 December, 2012 10:30 >To: rtcweb@ietf.org >Subject: [rtcweb] Call for Consensus Regarding Selecting Recommended=20 >Audio Codecs > >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 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 From roman@telurix.com Thu Dec 20 11:22:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FF321F8A51 for ; Thu, 20 Dec 2012 11:22:08 -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 XwXle2hdg965 for ; Thu, 20 Dec 2012 11:22:07 -0800 (PST) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2EF21F89FB for ; Thu, 20 Dec 2012 11:22:06 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id r1so1848349wey.1 for ; Thu, 20 Dec 2012 11:22:05 -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=1tvC9ZKnxA42O5cpEtcWhUBLrILypr01cee17HmR/DM=; b=lokoWG+E/e7IVFytQhd6ac1ssAk2LFJI4qJFwAca+GN3BrMwtEnmIK2FcEbTIJA3qm pAWN74Y7gemKsX90DDVwTNLRZ07rid3Q0/sEc9pXvA4oBjlfeSjbs3m1VtS+lb8ihb4P cyY4MY81BaO+yGg0d3DJYsR/pLKwi5DMJoqz+IhyhEKG0GbyHoqhv/HnrEv4jfgjXin6 fOSDECiGNwFrCO65zkP5ZpRDmCf2qYOD1bxDqSP9zvAeB2pgzDL50Fhx2pEoACCJgOPG 9gSt5TH56VzVQmrbTcHwZn/6F5ENYIP1fUVG7yKHDC0Yr3bkL5ypYd5saW3wLIYMxLrg I0rA== X-Received: by 10.180.95.135 with SMTP id dk7mr11763468wib.29.1356031325700; Thu, 20 Dec 2012 11:22:05 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by mx.google.com with ESMTPS id df2sm17332096wib.0.2012.12.20.11.22.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 11:22:04 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id gg4so1654074wgb.18 for ; Thu, 20 Dec 2012 11:22:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.101.99 with SMTP id ff3mr19024524wib.21.1356031322831; Thu, 20 Dec 2012 11:22:02 -0800 (PST) Received: by 10.216.16.134 with HTTP; Thu, 20 Dec 2012 11:22:02 -0800 (PST) In-Reply-To: <000501cddee6$666ce7b0$3346b710$@us> References: <50D2CC6A.4090500@ericsson.com> <000501cddee6$666ce7b0$3346b710$@us> Date: Thu, 20 Dec 2012 14:22:02 -0500 Message-ID: From: Roman Shpount To: Richard Shockey Content-Type: multipart/alternative; boundary=f46d044280e84d3bb804d14da580 X-Gm-Message-State: ALoCoQnr5Yq1zDJcN/XhguP9i5nN3lWXNgzTFNpVEaw/RftvDRmwTP0kWMzagZAJ8/rqvyuA1YAa 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, 20 Dec 2012 19:22:08 -0000 --f46d044280e84d3bb804d14da580 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would also vote for G.722, AMR, and AMR-WB. _____________ Roman Shpount On Thu, Dec 20, 2012 at 2:15 PM, Richard Shockey wrote= : > +1 .. 722 AMR AMR-WB was and still is the optimal choices for SHOULD. Tha= t > would cover interoperability with existing enterprise SIP PBX systems and > the VoLTE deployments that are rolling out now and will gather market > momentum in 2014. > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of > Markus.Isomaki@nokia.com > Sent: Thursday, December 20, 2012 6:24 AM > To: magnus.westerlund@ericsson.com; rtcweb@ietf.org > Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended > Audio Codecs > > Hi, > > I think we should make an attempt at 1), i.e. to at least find out if the= re > is a consensus on such as small set of recommended codecs. I don't know > what > is small, but I would say no more than 1-3. And there has to be a > convincing > case for each why they add value over G.711 AND Opus. > > My proposal would be to recommend AMR, and perhaps AMR-WB. The rationale = is > that those codecs are widely supported in mobile devices and in Circuit > Switched and IMS/LTE based VoIP telephony. So they are helpful for > transcode-free interoperability with the current and future :-) legacy > systems, and in that dimension they would add value to G.711 and Opus. It > is > not a relevant use case for all WebRTC services, but to a large enough se= t > I > believe. Quite many people even proposed AMR/AMR-WB as mandatory for > WebRTC. > The main reason it was not acceptable was the IPR situation, which quite = a > few saw inhibitive. That has not changed, but I think the deliberations i= n > that regard are different for "recommended" than "mandatory". > > Markus > > > >-----Original Message----- > >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >Behalf Of ext Magnus Westerlund > >Sent: 20 December, 2012 10:30 > >To: rtcweb@ietf.org > >Subject: [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 > _______________________________________________ > 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 > --f46d044280e84d3bb804d14da580 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would also vote for G.722, AMR, and AMR-WB.
_______= ______
Roman Shpount


On Thu, Dec 20, 2012 at 2:15 PM, Richard= Shockey <richard@shockey.us> wrote:
+1 .. 722 AMR AMR-WB was and still is the optimal choices for SHOULD. That<= br> would cover interoperability with existing enterprise SIP PBX systems and the VoLTE deployments that are rolling out now and will gather market
momentum in 2014.

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.or= g] On Behalf Of
Markus.Isomaki@nokia.com
Sent: Thursday, December 20, 2012 6:24 AM
To: magnus.westerlund@eri= csson.com; rtcweb@ietf.org
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

Hi,

I think we should make an attempt at 1), i.e. to at least find out if there=
is a consensus on such as small set of recommended codecs. I don't know= what
is small, but I would say no more than 1-3. And there has to be a convincin= g
case for each why they add value over G.711 AND Opus.

My proposal would be to recommend AMR, and perhaps AMR-WB. The rationale is=
that those codecs are widely supported in mobile devices and in Circuit
Switched and IMS/LTE based VoIP telephony. So they are helpful for
transcode-free interoperability with the current and future :-) legacy
systems, and in that dimension they would add value to G.711 and Opus. It i= s
not a relevant use case for all WebRTC services, but to a large enough set = I
believe. Quite many people even proposed AMR/AMR-WB as mandatory for WebRTC= .
The main reason it was not acceptable was the IPR situation, which quite a<= br> few saw inhibitive. That has not changed, but I think the deliberations in<= br> that regard are different for "recommended" than "mandatory&= quot;.

Markus


>-----Original Message-----
>From: rtcweb-bounces@ietf.or= g [mailto:rtcweb-bounces@iet= f.org] On
>Behalf Of ext Magnus Westerlund
>Sent: 20 December, 2012 10:30
>To: rtcweb@ietf.org
>Subject: [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<= br> >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<= br> >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
>
>----------------------------------------------------------------------<= br> >Multimedia Technologies, Ericsson Research EAB/TVM
>----------------------------------------------------------------------<= br> >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
>----------------------------------------------------------------------<= br> >
>_______________________________________________
>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

--f46d044280e84d3bb804d14da580-- From James.Rafferty@dialogic.com Thu Dec 20 11:33:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51AA21F8A54 for ; Thu, 20 Dec 2012 11:33:05 -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, 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 gieGCDNGuMU6 for ; Thu, 20 Dec 2012 11:33:04 -0800 (PST) Received: from outbound.dialogic.com (outbound.dialogic.com [173.210.122.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC4C21F895C for ; Thu, 20 Dec 2012 11:33:04 -0800 (PST) Received: from MBX.dialogic.com ([fe80::bd56:b76c:8d2c:437b]) by pysxht01.dialogic.com ([::1]) with mapi; Thu, 20 Dec 2012 14:33:03 -0500 From: James Rafferty To: Roman Shpount , Richard Shockey Date: Thu, 20 Dec 2012 14:32:55 -0500 Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: Ac3e50+aorUEFJg+T8OV5hAV1kKCPgAAXfcw Message-ID: <54633A5E61DC84429CB9FE3D9143C721E6F50A64@MBX.dialogic.com> References: <50D2CC6A.4090500@ericsson.com> <000501cddee6$666ce7b0$3346b710$@us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_54633A5E61DC84429CB9FE3D9143C721E6F50A64MBXdialogiccom_" 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: Thu, 20 Dec 2012 19:33:05 -0000 --_000_54633A5E61DC84429CB9FE3D9143C721E6F50A64MBXdialogiccom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable + 1 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Roman Shpount Sent: Thursday, December 20, 2012 2:22 PM To: Richard Shockey Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Au= dio Codecs I would also vote for G.722, AMR, and AMR-WB. _____________ Roman Shpount On Thu, Dec 20, 2012 at 2:15 PM, Richard Shockey > wrote: +1 .. 722 AMR AMR-WB was and still is the optimal choices for SHOULD. That would cover interoperability with existing enterprise SIP PBX systems and the VoLTE deployments that are rolling out now and will gather market momentum in 2014. -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Markus.Isomaki@nokia.com Sent: Thursday, December 20, 2012 6:24 AM To: magnus.westerlund@ericsson.com; = rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Hi, I think we should make an attempt at 1), i.e. to at least find out if there is a consensus on such as small set of recommended codecs. I don't know wha= t is small, but I would say no more than 1-3. And there has to be a convincin= g case for each why they add value over G.711 AND Opus. My proposal would be to recommend AMR, and perhaps AMR-WB. The rationale is that those codecs are widely supported in mobile devices and in Circuit Switched and IMS/LTE based VoIP telephony. So they are helpful for transcode-free interoperability with the current and future :-) legacy systems, and in that dimension they would add value to G.711 and Opus. It i= s not a relevant use case for all WebRTC services, but to a large enough set = I believe. Quite many people even proposed AMR/AMR-WB as mandatory for WebRTC= . The main reason it was not acceptable was the IPR situation, which quite a few saw inhibitive. That has not changed, but I think the deliberations in that regard are different for "recommended" than "mandatory". Markus >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcw= eb-bounces@ietf.org] On >Behalf Of ext Magnus Westerlund >Sent: 20 December, 2012 10:30 >To: rtcweb@ietf.org >Subject: [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 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_54633A5E61DC84429CB9FE3D9143C721E6F50A64MBXdialogiccom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+ 1<= /o:p>

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.o= rg] On Behalf Of Roman Shpount
Sent: Thursday, December 20= , 2012 2:22 PM
To: Richard Shockey
Cc: rtcweb@ietf.org<= br>Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Reco= mmended Audio Codecs

 <= /o:p>

I would also vote for G.722, AMR, and AMR-WB.=

_____________
R= oman Shpount

 

On Thu, Dec 20, 20= 12 at 2:15 PM, Richard Shockey <richard@shockey.us> wrote:

+1 .. 722 AMR AMR-WB was and still is the optimal choices for SHO= ULD. That
would cover interoperability with existing enterprise SIP PBX = systems and
the VoLTE deployments that are rolling out now and will gath= er market
momentum in 2014.


= -----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of

=

Marku= s.Isomaki@nokia.com
Sent: Thursday, December 20, 2012 6:24 AM
To:= magnus.westerlund@ericss= on.com; rtcweb@ietf.org
Subje= ct: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended
Audi= o Codecs

Hi,

I think we should make an attempt at 1), i.e. to= at least find out if there
is a consensus on such as small set of recom= mended codecs. I don't know what
is small, but I would say no more than = 1-3. And there has to be a convincing
case for each why they add value o= ver G.711 AND Opus.

My proposal would be to recommend AMR, and perha= ps AMR-WB. The rationale is
that those codecs are widely supported in mo= bile devices and in Circuit
Switched and IMS/LTE based VoIP telephony. S= o they are helpful for
transcode-free interoperability with the current = and future :-) legacy
systems, and in that dimension they would add valu= e to G.711 and Opus. It is
not a relevant use case for all WebRTC servic= es, but to a large enough set I
believe. Quite many people even proposed= AMR/AMR-WB as mandatory for WebRTC.
The main reason it was not acceptab= le was the IPR situation, which quite a
few saw inhibitive. That has not= changed, but I think the deliberations in
that regard are different for= "recommended" than "mandatory".

Markus

<= br>>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>Behalf Of ext Mag= nus Westerlund
>Sent: 20 December, 2012 10:30
>To: rtcweb@ietf.org
>Subject: [rtcweb] Call fo= r Consensus Regarding Selecting Recommended
>Audio Codecs
>
= >WG,
>
>As an outcome of the Vancouver IETF meeting codec di= scussions we did
>promise to run a call for consensus regarding if th= e WG was interested
>in specifying a small set of recommended audio c= odecs. We are sorry
>this has been delayed until now.
>
>= The question for the call of consensus is between two options.
>
&= gt;1) Run a process in the WG to select and specify a small set of
>a= udio/speech codecs that would be RECOMMNEDED to implement by a WebRTC
&g= t;end-points
>
>2) Do nothing and let the already specified Man= datory to Implement
>Audio codecs be the only audio codecs mentioned = in the WebRTC
specification.
>
>Please indicate your positio= n by January 16th 2013.
>
>Regards
>
>Magnus Wester= lund
>
>-------------------------------------------------------= ---------------
>Multimedia Technologies, Ericsson Research EAB/TVM>---------------------------------------------------------------------= -
>Ericsson AB                = ;| Phone  +46 10 7148287
&= gt;F=E4r=F6gatan 6                |= Mobile +46 73 0949079
>SE-1= 64 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@ie= tf.org
https://www.ietf.org/mailman/listinfo/rtcweb

_____= __________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/ma= ilman/listinfo/rtcweb

 

= --_000_54633A5E61DC84429CB9FE3D9143C721E6F50A64MBXdialogiccom_-- From denglingli@chinamobile.com Thu Dec 20 18:12:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F3121F8951 for ; Thu, 20 Dec 2012 18:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.886 X-Spam-Level: * X-Spam-Status: No, score=1.886 tagged_above=-999 required=5 tests=[BAD_ENC_HEADER=1.81, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wC3qyhDwqMFM for ; Thu, 20 Dec 2012 18:12:34 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9A421F8932 for ; Thu, 20 Dec 2012 18:12:33 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 22ECCE518; Fri, 21 Dec 2012 10:12:29 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 1173EE40C; Fri, 21 Dec 2012 10:12:29 +0800 (CST) Received: from cmccPC ([10.2.43.200]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012122110122664-77572 ; Fri, 21 Dec 2012 10:12:26 +0800 From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: "'James Rafferty'" , "'Roman Shpount'" , "'Richard Shockey'" References: <50D2CC6A.4090500@ericsson.com> <000501cddee6$666ce7b0$3346b710$@us> <54633A5E61DC84429CB9FE3D9143C721E6F50A64@MBX.dialogic.com> In-Reply-To: <54633A5E61DC84429CB9FE3D9143C721E6F50A64@MBX.dialogic.com> Date: Fri, 21 Dec 2012 10:12:27 +0800 Message-ID: <002101cddf20$9f73b400$de5b1c00$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3e50+aorUEFJg+T8OV5hAV1kKCPgAAXfcwAA3z/tA= X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-12-21 10:12:26, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-12-21 10:12:28, Serialize complete at 2012-12-21 10:12:28 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01CDDF63.AD971B10" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19470.000 X-TM-AS-Result: No--39.277-7.0-31-10 X-imss-scan-details: No--39.277-7.0-31-10;No--39.277-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: rtcweb@ietf.org Subject: [rtcweb] =?utf-8?b?562U5aSNOiAgQ2FsbCBmb3IgQ29uc2Vuc3VzIFJlZ2Fy?= =?utf-8?q?ding_Selecting=09Recommended=09Audio_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, 21 Dec 2012 02:12:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0022_01CDDF63.AD971B10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" +1 =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 James Rafferty =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2012=E5=B9=B412=E6=9C=8821=E6=97=A5 3:33 =E6=94=B6=E4=BB=B6=E4=BA=BA: Roman Shpount; Richard Shockey =E6=8A=84=E9=80=81: rtcweb@ietf.org =E4=B8=BB=E9=A2=98: Re: [rtcweb] Call for Consensus Regarding Selecting = Recommended Audio Codecs =20 + 1 =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Roman Shpount Sent: Thursday, December 20, 2012 2:22 PM To: Richard Shockey Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended = Audio Codecs =20 I would also vote for G.722, AMR, and AMR-WB. _____________ Roman Shpount =20 On Thu, Dec 20, 2012 at 2:15 PM, Richard Shockey = wrote: +1 .. 722 AMR AMR-WB was and still is the optimal choices for SHOULD. = That would cover interoperability with existing enterprise SIP PBX systems = and the VoLTE deployments that are rolling out now and will gather market momentum in 2014. -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Markus.Isomaki@nokia.com Sent: Thursday, December 20, 2012 6:24 AM To: magnus.westerlund@ericsson.com; rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Hi, I think we should make an attempt at 1), i.e. to at least find out if = there is a consensus on such as small set of recommended codecs. I don't know = what is small, but I would say no more than 1-3. And there has to be a = convincing case for each why they add value over G.711 AND Opus. My proposal would be to recommend AMR, and perhaps AMR-WB. The rationale = is that those codecs are widely supported in mobile devices and in Circuit Switched and IMS/LTE based VoIP telephony. So they are helpful for transcode-free interoperability with the current and future :-) legacy systems, and in that dimension they would add value to G.711 and Opus. = It is not a relevant use case for all WebRTC services, but to a large enough = set I believe. Quite many people even proposed AMR/AMR-WB as mandatory for = WebRTC. The main reason it was not acceptable was the IPR situation, which quite = a few saw inhibitive. That has not changed, but I think the deliberations = in that regard are different for "recommended" than "mandatory". Markus >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >Behalf Of ext Magnus Westerlund >Sent: 20 December, 2012 10:30 >To: rtcweb@ietf.org >Subject: [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 = =20 >F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 = =20 >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 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------=_NextPart_000_0022_01CDDF63.AD971B10 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

+1

 

=E5=8F=91=E4=BB=B6=E4=BA=BA= : rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 = James = Rafferty
=E5=8F=91=E9=80=81=E6=97=B6= =E9=97=B4: 2012=E5=B9=B412=E6=9C=8821=E6=97=A5 = 3:33
=E6=94=B6=E4=BB=B6=E4=BA=BA: Roman Shpount; Richard = Shockey
=E6=8A=84=E9=80=81: = rtcweb@ietf.org
=E4=B8=BB=E9=A2=98: Re: [rtcweb] Call for = Consensus Regarding Selecting Recommended Audio = Codecs

 

+ 1

 

From:= = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Roman Shpount
Sent: Thursday, December 20, 2012 2:22 = PM
To: Richard Shockey
Cc: = rtcweb@ietf.org
Subject: Re: [rtcweb] Call for Consensus = Regarding Selecting Recommended Audio Codecs

 

I would also vote for G.722, AMR, = and AMR-WB.

_____________
Roman = Shpount

 

On Thu, Dec 20, 2012 at 2:15 PM, Richard Shockey <richard@shockey.us> = wrote:

+1 = .. 722 AMR AMR-WB was and still is the optimal choices for SHOULD. = That
would cover interoperability with existing enterprise SIP PBX = systems and
the VoLTE deployments that are rolling out now and will = gather market
momentum in 2014.


-----Original = Message-----
From: rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] On = Behalf Of

Markus.Isomaki@nokia.com
= Sent: Thursday, December 20, 2012 6:24 AM
To: magnus.westerlund@ericsson= .com; rtcweb@ietf.org
Subject: Re: = [rtcweb] Call for Consensus Regarding Selecting Recommended
Audio = Codecs

Hi,

I think we should make an attempt at 1), i.e. = to at least find out if there
is a consensus on such as small set of = recommended codecs. I don't know what
is small, but I would say no = more than 1-3. And there has to be a convincing
case for each why = they add value over G.711 AND Opus.

My proposal would be to = recommend AMR, and perhaps AMR-WB. The rationale is
that those codecs = are widely supported in mobile devices and in Circuit
Switched and = IMS/LTE based VoIP telephony. So they are helpful for
transcode-free = interoperability with the current and future :-) legacy
systems, and = in that dimension they would add value to G.711 and Opus. It is
not a = relevant use case for all WebRTC services, but to a large enough set = I
believe. Quite many people even proposed AMR/AMR-WB as mandatory = for WebRTC.
The main reason it was not acceptable was the IPR = situation, which quite a
few saw inhibitive. That has not changed, = but I think the deliberations in
that regard are different for = "recommended" than = "mandatory".

Markus


>-----Original = Message-----
>From: rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] = On
>Behalf Of ext Magnus Westerlund
>Sent: 20 December, 2012 = 10:30
>To: rtcweb@ietf.org
>Subject: = [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=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
___= ____________________________________________
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

 

------=_NextPart_000_0022_01CDDF63.AD971B10-- From tterriberry@mozilla.com Thu Dec 20 20:21:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C59C21E803F for ; Thu, 20 Dec 2012 20:21:26 -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 cb1Hh+xZsuvd for ; Thu, 20 Dec 2012 20:21:24 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0749A21F8964 for ; Thu, 20 Dec 2012 20:21:23 -0800 (PST) Received: from [192.168.11.10] (pool-71-114-8-24.washdc.dsl-w.verizon.net [71.114.8.24]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id CC166F2140 for ; Thu, 20 Dec 2012 20:21:20 -0800 (PST) Message-ID: <50D3E3BF.7070609@mozilla.com> Date: Thu, 20 Dec 2012 20:21:19 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50D2CC6A.4090500@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 21 Dec 2012 04:21:26 -0000 Markus.Isomaki@nokia.com wrote: > My proposal would be to recommend AMR, and perhaps AMR-WB. The rationale is I don't think we should list a set of RECOMMENDED codecs. If we were talking just G.722, iLBC, etc., I might be persuaded. But this is a 2119 RECOMMENDED, which is a bit stronger than "Gee, it would be nice," and given the aforementioned IPR situation, Mozilla is not likely to be deploying any of the AMR family anytime soon. If the goal is interoperability with deployed systems, you're going to implement what you need to implement to achieve that, and nothing we write down in an RFC will change what that needs to be. From bernard_aboba@hotmail.com Fri Dec 21 07:40:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9D621F85D7 for ; Fri, 21 Dec 2012 07:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[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 UytyocX+sTHG for ; Fri, 21 Dec 2012 07:40:45 -0800 (PST) Received: from blu0-omc3-s10.blu0.hotmail.com (blu0-omc3-s10.blu0.hotmail.com [65.55.116.85]) by ietfa.amsl.com (Postfix) with ESMTP id D936821F869B for ; Fri, 21 Dec 2012 07:40:44 -0800 (PST) Received: from BLU002-W15 ([65.55.116.73]) by blu0-omc3-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Dec 2012 07:40:44 -0800 X-EIP: [+R8NMCwebpcOr3cWnUUCnRr+ZVsUUpwJ] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_1c00f51b-6167-4fa1-9f83-1c6f00ba1aaa_" From: Bernard Aboba To: Christer Holmberg , "rtcweb@ietf.org" Date: Fri, 21 Dec 2012 07:40:43 -0800 Importance: Normal In-Reply-To: <7594FB04B1934943A5C02806D1A2204B06E211@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B06E211@ESESSMB209.ericsson.se> MIME-Version: 1.0 X-OriginalArrivalTime: 21 Dec 2012 15:40:44.0486 (UTC) FILETIME=[8A29CE60:01CDDF91] 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: Fri, 21 Dec 2012 15:40:46 -0000 --_1c00f51b-6167-4fa1-9f83-1c6f00ba1aaa_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Christer said:=20 =0A= "If we want to support content sent in different resolutions=2C the questio= n is whether we need to mandate the browser to support a specific=0A= =0A= =0A= =0A= mechanism. As shown in the note=2C there are basically 3 mechanisms: SVC= =2C simulcast and =93local transcoding=94." [BA] One of the reasons that "no MTI codec proposal supports SVC" is that b= y definition mandates apply to a wide range of situations=2C from a browser= on a mobile device to a desktop scenario involving exchange of multiple st= reams at high bandwidth. This leads to mandates focusing on the "lowest co= mmon denominator"=2C which may make it difficult mandate browser support fo= r encoding of SVC or simulcast.=20 SVC supports multiple scalability mechanisms: temporal=2C spatial and qual= ity. Temporal is the most widely implemented in software (at least for H.2= 64/SVC)=2C although there is an open source implementation that supports al= l modes. In hardware=2C support for spatial or quality scaling is not comm= on. As a result=2C a browser on a mobile device could have difficulty comp= lying with a mandate to support spatial scaling within the encoder.=20 Although cameras on mobile devices are growing increasingly capable=2C unli= mited usage LTE plans are still not ubiquitous=2C which puts a damper on se= nding of simulcast from mobile devices. Given the above=2C it seems hard to mandate any of the above options.=20 =20 =20 =0A= =0A= =0A= = --_1c00f51b-6167-4fa1-9f83-1c6f00ba1aaa_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Christer said:

=0A=

"If we want to support content sent in different = resolutions=2C the question is whether we need to mandate the browser to su= pport a specific=0A=

=0A= =0A= =0A=

mechanism. =3B As shown in the note=2C there = are basically 3 mechanisms: SVC=2C simulcast and =93local transcoding=94."<= /p>


[BA] One of = the reasons that "no MTI codec proposal supports SVC" is that by definition= mandates apply to a wide range of situations=2C from a browser on a mobile= device to a desktop scenario involving exchange of multiple streams at hig= h bandwidth. =3B This leads to mandates focusing on the "lowest common = denominator"=2C which may make it difficult mandate browser support for enc= oding of SVC or simulcast.


SVC supports multiple scalability mechanisms: =3B t= emporal=2C spatial and quality. =3B Temporal is the most widely impleme= nted in software (at least for H.264/SVC)=2C although there is an open sour= ce implementation that supports all modes. =3B In hardware=2C support f= or spatial or quality scaling is not common. =3B As a result=2C a brows= er on a mobile device could have difficulty complying with a mandate to sup= port spatial scaling within the encoder.

=

Although cameras on mobile devices are gr= owing increasingly capable=2C unlimited usage LTE plans are still not ubiqu= itous=2C which puts a damper on sending of simulcast from mobile devices.


Given the abo= ve=2C it seems hard to mandate any of the above options.




 =3B



=0A= =0A= =0A=
= --_1c00f51b-6167-4fa1-9f83-1c6f00ba1aaa_-- From adam@nostrum.com Fri Dec 21 08:27:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEADA21F87C7 for ; Fri, 21 Dec 2012 08:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.564 X-Spam-Level: X-Spam-Status: No, score=-103.564 tagged_above=-999 required=5 tests=[AWL=1.036, BAYES_00=-2.599, GB_I_LETTER=-2, 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 L7BJ1LmmGLyN for ; Fri, 21 Dec 2012 08:27:06 -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 0DA9921F84F9 for ; Fri, 21 Dec 2012 08:27:05 -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 qBLGR4Oo001450 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 21 Dec 2012 10:27:05 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50D48DD8.3050702@nostrum.com> Date: Fri, 21 Dec 2012 10:27:04 -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: "Timothy B. Terriberry" References: <50D2CC6A.4090500@ericsson.com> <50D3E3BF.7070609@mozilla.com> In-Reply-To: <50D3E3BF.7070609@mozilla.com> 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, 21 Dec 2012 16:27:06 -0000 On 12/20/12 22:21, Timothy B. Terriberry wrote: > Markus.Isomaki@nokia.com wrote: >> My proposal would be to recommend AMR, and perhaps AMR-WB. The >> rationale is > > I don't think we should list a set of RECOMMENDED codecs. If we were > talking just G.722, iLBC, etc., I might be persuaded. But this is a > 2119 RECOMMENDED, which is a bit stronger than "Gee, it would be > nice," and given the aforementioned IPR situation, Mozilla is not > likely to be deploying any of the AMR family anytime soon. > > If the goal is interoperability with deployed systems, you're going to > implement what you need to implement to achieve that, and nothing we > write down in an RFC will change what that needs to be. I'm going to have to agree with Tim -- very little would be served by having normative SHOULD-strength requirements here. What I think would be beneficial would be a section documenting codecs in widespread use today, where they're used, and what is gained by including them in WebRTC implementations (mostly transcoder-free interop with those other implementations). Documenting that AMR is used in 3GPP VoIP networks would allow implementors to make an educated decision about the benefit of including that codec. A similar mention that many modern VoIP phones support G.722 and/or AAC-LD would provide similar guidance. But I don't think there's much to be gained by readying the scarlet letter of "conditionally compliant" that would result from a SHOULD-strength normative statement about royalty-bearing codecs. /a From richard@shockey.us Fri Dec 21 13:14:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A031221F87D5 for ; Fri, 21 Dec 2012 13:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.196 X-Spam-Level: X-Spam-Status: No, score=-103.196 tagged_above=-999 required=5 tests=[AWL=1.069, BAYES_00=-2.599, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03AJ6M4sGpPB for ; Fri, 21 Dec 2012 13:14:58 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id C0DAA21F8792 for ; Fri, 21 Dec 2012 13:14:58 -0800 (PST) Received: (qmail 10537 invoked by uid 0); 21 Dec 2012 21:14:35 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy2.bluehost.com with SMTP; 21 Dec 2012 21:14:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=dIk4Gg1mkljQt70labrEZXk7xq9UEgeiweSO2F2B+Hk=; b=dY3sfqTkYHgAjsKm/2ODX/oiRAZKZVkIpqoi7P+EYBSrqWkmpEX469JEr28v1wIqOJ728RmE8DHQ0bwMK9enq5dagG9YOXEVfulxKe9JLON4r1U5zuwV7BNW+XMl9rCt; Received: from [71.191.243.130] (port=60761 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Tm9vO-0003B6-ET for rtcweb@ietf.org; Fri, 21 Dec 2012 14:14:34 -0700 From: "Richard Shockey" To: References: <50D2CC6A.4090500@ericsson.com> <50D3E3BF.7070609@mozilla.com> <50D48DD8.3050702@nostrum.com> In-Reply-To: <50D48DD8.3050702@nostrum.com> Date: Fri, 21 Dec 2012 16:14:32 -0500 Message-ID: <009b01cddfc0$2d4e1820$87ea4860$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3fmAjXCjxDxaPPQQCdiGnkPQ5CnQAJq80w Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: Re: [rtcweb] 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, 21 Dec 2012 21:14:59 -0000 I'm really trying to understand the tortured logic here. The presumption was that you wanted to have some limited MTI's here in order to guarantee a minimum level of interoperability. Its clear there will be virtually no consensus on Video Codec's not very much agreement on how text will be supported and now a sustained whine for either SHOULD/RECOMMENDED ( whatever) for the most practical advanced codec's that are or will be in use in the public SIP networks. So instead of providing any minimum guidance to implementers why don't you basically say "Well there is no consensus on anything and we've collectively decided to drive off the protocol cliff and see what happens". Cliff diving is very popular in the US these days. Eliminate all MTI's and just say here is Video menu A, Audio menu B, Text menu C and Dessert menu D good luck folks! That seems to be where you seem to be going. -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach Sent: Friday, December 21, 2012 11:27 AM To: Timothy B. Terriberry Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs On 12/20/12 22:21, Timothy B. Terriberry wrote: > Markus.Isomaki@nokia.com wrote: >> My proposal would be to recommend AMR, and perhaps AMR-WB. The >> rationale is > > I don't think we should list a set of RECOMMENDED codecs. If we were > talking just G.722, iLBC, etc., I might be persuaded. But this is a > 2119 RECOMMENDED, which is a bit stronger than "Gee, it would be > nice," and given the aforementioned IPR situation, Mozilla is not > likely to be deploying any of the AMR family anytime soon. > > If the goal is interoperability with deployed systems, you're going to > implement what you need to implement to achieve that, and nothing we > write down in an RFC will change what that needs to be. I'm going to have to agree with Tim -- very little would be served by having normative SHOULD-strength requirements here. What I think would be beneficial would be a section documenting codecs in widespread use today, where they're used, and what is gained by including them in WebRTC implementations (mostly transcoder-free interop with those other implementations). Documenting that AMR is used in 3GPP VoIP networks would allow implementors to make an educated decision about the benefit of including that codec. A similar mention that many modern VoIP phones support G.722 and/or AAC-LD would provide similar guidance. But I don't think there's much to be gained by readying the scarlet letter of "conditionally compliant" that would result from a SHOULD-strength normative statement about royalty-bearing codecs. /a _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From adam@nostrum.com Fri Dec 21 13:21:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C1B21F87D5 for ; Fri, 21 Dec 2012 13:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.694 X-Spam-Level: X-Spam-Status: No, score=-102.694 tagged_above=-999 required=5 tests=[AWL=-0.094, 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 L4T6acQgcpQG for ; Fri, 21 Dec 2012 13:21:49 -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 9E60621F85BF for ; Fri, 21 Dec 2012 13:21:37 -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 qBLLLaXY032999 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 21 Dec 2012 15:21:37 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50D4D2E0.9070301@nostrum.com> Date: Fri, 21 Dec 2012 15:21:36 -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: rtcweb@ietf.org References: <50D2CC6A.4090500@ericsson.com> <50D3E3BF.7070609@mozilla.com> <50D48DD8.3050702@nostrum.com> <009b01cddfc0$2d4e1820$87ea4860$@us> In-Reply-To: <009b01cddfc0$2d4e1820$87ea4860$@us> 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) 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, 21 Dec 2012 21:21:49 -0000 On 12/21/12 15:14, Richard Shockey wrote: > So instead of providing any minimum guidance to implementers... I see you didn't make it all the way to the second paragraph of my response where I propose providing guidance to implementors. I highly recommend it as a riveting sequel to the first paragraph. /a From roman@telurix.com Fri Dec 21 13:43:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EDA21F890F for ; Fri, 21 Dec 2012 13:43:18 -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 dzi0T6pSNdt5 for ; Fri, 21 Dec 2012 13:43:18 -0800 (PST) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) by ietfa.amsl.com (Postfix) with ESMTP id D6ED721F88E6 for ; Fri, 21 Dec 2012 13:43:17 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id t57so2364933wey.39 for ; Fri, 21 Dec 2012 13:43:17 -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=0GsbsKm2GHhCUKVD8IigYjqShsrDsoaG3SVB6GngPuM=; b=RE4U/ykT9n5f6c8Puk/dit2H6umlUnla0YYdao0MCCgHgUfXZ67dnlKxhVKjKDqjXm 4QtentL9eMc2GQkz9ap2pnolPNGTLPBhuPsiu47nSFMMShQVJopePWmN4cpBeWMA1g/r iqdSd12KXHORQNq/Qy5c/TH29s/2V7FP8yjI6+qSdtljXCORpQ9fMeGStIl47IlTFK6m E7LxGKWyqJ41Ta6wC9PkjS9xtGdKs5nCB+HHGUR8518nHOFLoXhIosQR4DwD/CG6qXgk /ctcsDKCajfEczh2D7+7ywhafqq2eKZ30ddWwn+/3L2BwoSYR81E3CYejEWw9b//vFxx a+Pg== X-Received: by 10.194.174.196 with SMTP id bu4mr25863059wjc.35.1356126196972; Fri, 21 Dec 2012 13:43:16 -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 gz3sm31657058wib.2.2012.12.21.13.43.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Dec 2012 13:43:15 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id z53so2414653wey.20 for ; Fri, 21 Dec 2012 13:43:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.84.131 with SMTP id z3mr17783299wiy.25.1356126193928; Fri, 21 Dec 2012 13:43:13 -0800 (PST) Received: by 10.216.16.134 with HTTP; Fri, 21 Dec 2012 13:43:13 -0800 (PST) In-Reply-To: <50D48DD8.3050702@nostrum.com> References: <50D2CC6A.4090500@ericsson.com> <50D3E3BF.7070609@mozilla.com> <50D48DD8.3050702@nostrum.com> Date: Fri, 21 Dec 2012 16:43:13 -0500 Message-ID: From: Roman Shpount To: Adam Roach Content-Type: multipart/alternative; boundary=f46d043bdd640f4b7604d163bca5 X-Gm-Message-State: ALoCoQlppM/SmOUXxtTsJGuMG0eTAIqntzvaNkBs4feQkPBaJBBi6k+KNb/FWKUZ+jl8RtSQNhda 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, 21 Dec 2012 21:43:18 -0000 --f46d043bdd640f4b7604d163bca5 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 21, 2012 at 11:27 AM, Adam Roach wrote: > What I think would be beneficial would be a section documenting codecs in > widespread use today, where they're used, and what is gained by including > them in WebRTC implementations (mostly transcoder-free interop with those > other implementations). Documenting that AMR is used in 3GPP VoIP networks > would allow implementors to make an educated decision about the benefit of > including that codec. A similar mention that many modern VoIP phones > support G.722 and/or AAC-LD would provide similar guidance. In reality very few phones support AAC-LD. For me the major concern is support for G.722. There is no reason not to support it. None. It is free, it is efficient, and it sounds better then G.711 any day of the week. It was not made an MTI for political reasons to promote OPUS. I think it deserves a SHOULD in the standard. As far as AMR and AMR-WB are concerned, they should be implemented if your platform provides it. I, personally, would never pay a license fee for these codecs, but if implementing a browser on a cell phone where these codecs are present, I would make an extra effort to support them. So, these codecs probably do not deserve a SHOULD, but some guidance to implementers is probably required. _____________ Roman Shpount --f46d043bdd640f4b7604d163bca5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 21, 2012 at 11:27 AM, Adam Roach <adam@n= ostrum.com> wrote:
What I think would be beneficial would be a section documenting codecs in w= idespread use today, where they're used, and what is gained by includin= g them in WebRTC implementations (mostly transcoder-free interop with those= other implementations). Documenting that AMR is used in 3GPP VoIP networks= would allow implementors to make an educated decision about the benefit of= including that codec. A similar mention that many modern VoIP phones suppo= rt G.722 and/or AAC-LD would provide similar guidance.

In reality very few phones support AAC-LD.=A0

=
For me the major concern is support for G.722. There is no reaso= n not to support it. None. It is free, it is efficient, and it sounds bette= r then G.711 any day of the week. It was not made an MTI for political reas= ons to promote OPUS. I think it deserves a SHOULD in the standard.

As far =A0as AMR and AMR-WB are concerned, they should = be implemented if your platform provides it. I, personally, would never pay= a license fee for these codecs, but if implementing a browser on a cell ph= one where these codecs are present, I would make an extra effort to support= them. So, these codecs probably do not deserve a SHOULD, but some=A0guidan= ce to implementers is probably required.
_____________
Roman Shpount

--f46d043bdd640f4b7604d163bca5-- From adam@nostrum.com Fri Dec 21 14:40:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6405121F882D for ; Fri, 21 Dec 2012 14:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.683 X-Spam-Level: X-Spam-Status: No, score=-102.683 tagged_above=-999 required=5 tests=[AWL=-0.084, 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 osXiE-QrQmA2 for ; Fri, 21 Dec 2012 14:40:13 -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 7C3B221F87DF for ; Fri, 21 Dec 2012 14:40:13 -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 qBLMeA7r041095 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 21 Dec 2012 16:40:10 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50D4E549.6020202@nostrum.com> Date: Fri, 21 Dec 2012 16:40:09 -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> <50D3E3BF.7070609@mozilla.com> <50D48DD8.3050702@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030206050106010803040605" 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, 21 Dec 2012 22:40:14 -0000 This is a multi-part message in MIME format. --------------030206050106010803040605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/21/12 15:43, Roman Shpount wrote: > > On Fri, Dec 21, 2012 at 11:27 AM, Adam Roach > wrote: > > What I think would be beneficial would be a section documenting > codecs in widespread use today, where they're used, and what is > gained by including them in WebRTC implementations (mostly > transcoder-free interop with those other implementations). > Documenting that AMR is used in 3GPP VoIP networks would allow > implementors to make an educated decision about the benefit of > including that codec. A similar mention that many modern VoIP > phones support G.722 and/or AAC-LD would provide similar guidance. > > > In reality very few phones support AAC-LD. > > For me the major concern is support for G.722. There is no reason not > to support it. None. It is free, it is efficient, and it sounds better > then G.711 any day of the week. It was not made an MTI for political > reasons to promote OPUS. I think it deserves a SHOULD in the standard. > > As far as AMR and AMR-WB are concerned, they should be implemented if > your platform provides it. I, personally, would never pay a license > fee for these codecs, but if implementing a browser on a cell phone > where these codecs are present, I would make an extra effort to > support them. So, these codecs probably do not deserve a SHOULD, but > some guidance to implementers is probably required. I can live with this proposal if need be, but think it's somewhat outside the spirit of RFC 2119: > 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. With an MTI, we have guaranteed interoperability already. The currently proposed RECOMMENDED/SHOULD language seems to be the exact kind of thing 2119 was trying to stave off in the last sentence I cite above. /a --------------030206050106010803040605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/21/12 15:43, Roman Shpount wrote:

On Fri, Dec 21, 2012 at 11:27 AM, Adam Roach <adam@nostrum.com> wrote:
What I think would be beneficial would be a section documenting codecs in widespread use today, where they're used, and what is gained by including them in WebRTC implementations (mostly transcoder-free interop with those other implementations). Documenting that AMR is used in 3GPP VoIP networks would allow implementors to make an educated decision about the benefit of including that codec. A similar mention that many modern VoIP phones support G.722 and/or AAC-LD would provide similar guidance.

In reality very few phones support AAC-LD. 

For me the major concern is support for G.722. There is no reason not to support it. None. It is free, it is efficient, and it sounds better then G.711 any day of the week. It was not made an MTI for political reasons to promote OPUS. I think it deserves a SHOULD in the standard.

As far  as AMR and AMR-WB are concerned, they should be implemented if your platform provides it. I, personally, would never pay a license fee for these codecs, but if implementing a browser on a cell phone where these codecs are present, I would make an extra effort to support them. So, these codecs probably do not deserve a SHOULD, but some guidance to implementers is probably required.

I can live with this proposal if need be, but think it's somewhat outside the spirit of RFC 2119:

   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.

With an MTI, we have guaranteed interoperability already. The currently proposed RECOMMENDED/SHOULD language seems to be the exact kind of thing 2119 was trying to stave off in the last sentence I cite above.

/a
--------------030206050106010803040605-- From gunnar.hellstrom@omnitor.se Fri Dec 21 15:28:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4981421F89CE for ; Fri, 21 Dec 2012 15:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jE4aTgmQgvAD for ; Fri, 21 Dec 2012 15:28:22 -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 593F121F8994 for ; Fri, 21 Dec 2012 15:28:22 -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 ; Sat, 22 Dec 2012 00:27:39 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-08-01.atm.binero.net (Postfix) with ESMTPA id 039F73A107 for ; Sat, 22 Dec 2012 00:27:39 +0100 (CET) Message-ID: <50D4F06D.3020602@omnitor.se> Date: Sat, 22 Dec 2012 00:27:41 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= 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: multipart/alternative; boundary="------------060305040709050106050703" 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: Fri, 21 Dec 2012 23:28:23 -0000 This is a multi-part message in MIME format. --------------060305040709050106050703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2012-12-21 16:40, Bernard Aboba wrote: > 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. > This is sad. For good usability of video, maintained frame rate is usually much more important than maintained spatial resolution. E.g. for sign language or lip reading usage with a single person in image, a frame rate under 20 fps introduces loss of language contents, and requires the users to try to fill in the gaps by imagination, while spatial resolution reduction down to QCIF causes much less harm to language perception possibilities. Gunnar --------------060305040709050106050703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2012-12-21 16:40, Bernard Aboba wrote:
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.

This is sad. For good usability of video, maintained frame rate is usually much more important than maintained spatial resolution. E.g. for sign language or lip reading usage with a single person in image, a frame rate under 20 fps introduces loss of language contents, and requires the users to try to fill in the gaps by imagination, while spatial resolution reduction down to QCIF causes much less harm to language perception possibilities.

Gunnar

--------------060305040709050106050703-- From jmvalin@mozilla.com Fri Dec 21 17:00:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAC121F8A83 for ; Fri, 21 Dec 2012 17:00:08 -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 SLZEPHSJEEfd for ; Fri, 21 Dec 2012 17:00:07 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id CC07421F8A82 for ; Fri, 21 Dec 2012 17:00:07 -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 DE625F217D; Fri, 21 Dec 2012 17:00:02 -0800 (PST) Message-ID: <50D50611.9090003@mozilla.com> Date: Fri, 21 Dec 2012 20:00:01 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Magnus Westerlund References: <50D2CC6A.4090500@ericsson.com> In-Reply-To: <50D2CC6A.4090500@ericsson.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 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: Sat, 22 Dec 2012 01:00:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - From RFC 2119: 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. As Tim pointer out, this is a pretty strong recommendation. I would prefer something weaker like application-dependent guidelines. For example, something along the lines of "for compatibility with mobile phones you MAY support AMR, for ISDN you MAY support G.722" and so on. If all you care about is communication between two browsers, I don't think there's any codec that needs a SHOULD. Overall, I think there's about a dozen codecs that can be useful for some applications, but I don't see any that's really useful for most people. Cheers, Jean-Marc On 12/20/2012 03: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ä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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ1QYRAAoJEJ6/8sItn9q9N7sH/R5RxDUq5DvLaTW/rRwFvoRO ar3UaRobdmfV4eFYEuj3Xg8KIZdbBAzj6e0MXoYygu7b7RJTAXi/eKIBDvK4iKOI y7U3yWVlZvJEVwBqhKCeRpQR6Y4DEikPN1pu2PR+gl29eEd4MB9L7nLq1FXxxSyo uzk23i9C3INfKbfRU8cbxalMlWABzyOQgtzrPCoag/AeQfNJlSZH5B5arnIY2wTj /xqTyAuk/5HNKQlv5zj2a4+s0XLT8d1TPvnGklEKvuSuDEm3O7chZAykYd0nPtSC /ZCBsAv/4C/3m58e6GpPHLqJP6rmpdeLIoUp5TCg5qyMy0tt9LO53SM6SQwvATQ= =mkuZ -----END PGP SIGNATURE----- From bernard_aboba@hotmail.com Fri Dec 21 17:01:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFBC21F8A9A for ; Fri, 21 Dec 2012 17:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 AE4EGnnTQ7ZP for ; Fri, 21 Dec 2012 17:01:56 -0800 (PST) Received: from blu0-omc3-s29.blu0.hotmail.com (blu0-omc3-s29.blu0.hotmail.com [65.55.116.104]) by ietfa.amsl.com (Postfix) with ESMTP id 52B3D21F8A83 for ; Fri, 21 Dec 2012 17:01:56 -0800 (PST) Received: from BLU402-EAS330 ([65.55.116.72]) by blu0-omc3-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Dec 2012 17:01:55 -0800 X-EIP: [HyHbhF2cXIrZNMl6pfpvJH5myBhV78hY] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/related; boundary="_ab360fe9-f14d-4847-8911-7e0aa478bf1b_" References: <7594FB04B1934943A5C02806D1A2204B06E211@ESESSMB209.ericsson.se> <50D4F06D.3020602@omnitor.se> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <50D4F06D.3020602@omnitor.se> Date: Fri, 21 Dec 2012 17:02:25 -0800 To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= X-OriginalArrivalTime: 22 Dec 2012 01:01:55.0667 (UTC) FILETIME=[EFC04A30:01CDDFDF] 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: Sat, 22 Dec 2012 01:01:57 -0000 --_ab360fe9-f14d-4847-8911-7e0aa478bf1b_ Content-Type: multipart/alternative; boundary="Apple-Mail-A7D3EE77-6FF2-4FA8-9923-F6936EAC48F5" Content-Transfer-Encoding: 7bit --Apple-Mail-A7D3EE77-6FF2-4FA8-9923-F6936EAC48F5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBtaW5pbXVtIGZyYW1lIHJhdGUgY2FuIGJlIGFzc3VyZWQgaW4gU1ZDIGJ5IGhhdmluZyB0aGUg YmFzZSBsYXllciBzdXBwb3J0IHRoZSByZXF1aXJlZCByZXNvbHV0aW9uIChlLmcuICAzMCBmcHMp LCB3aGlsZSBoYXZpbmcgYWRkaXRpb25hbCBsYXllcnMgZW5hYmxlIGhpZ2hlciBmcmFtZSByYXRl cyAoZS5nLiBBbiBhZGRpdGlvbmFsIDMwIGZwcywgYnJpbmdpbmcgdGhlIHRvdGFsIHRvIDYwIGZw cykuIFNvbWUgY2hpcHNldHMgZG8gc3VwcG9ydCB0ZW1wb3JhbCBzY2FsaW5nLCBhbmQgc28gdGhl IHNpdHVhdGlvbiBmb3IgdGVtcG9yYWwgc2NhbGluZyBpcyBjb25zaWRlcmFibHkgYmV0dGVyLg0K DQoNCg0KT24gRGVjIDIxLCAyMDEyLCBhdCAxNToyOCwgIkd1bm5hciBIZWxsc3Ryw7ZtIiA8Z3Vu bmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPiB3cm90ZToNCg0KPiBPbiAyMDEyLTEyLTIxIDE2OjQw LCBCZXJuYXJkIEFib2JhIHdyb3RlOg0KPj4gU1ZDIHN1cHBvcnRzIG11bHRpcGxlIHNjYWxhYmls aXR5IG1lY2hhbmlzbXM6ICB0ZW1wb3JhbCwgc3BhdGlhbCBhbmQgcXVhbGl0eS4gIFRlbXBvcmFs IGlzIHRoZSBtb3N0IHdpZGVseSBpbXBsZW1lbnRlZCBpbiBzb2Z0d2FyZSAoYXQgbGVhc3QgZm9y IEguMjY0L1NWQyksIGFsdGhvdWdoIHRoZXJlIGlzIGFuIG9wZW4gc291cmNlIGltcGxlbWVudGF0 aW9uIHRoYXQgc3VwcG9ydHMgYWxsIG1vZGVzLiAgSW4gaGFyZHdhcmUsIHN1cHBvcnQgZm9yIHNw YXRpYWwgb3IgcXVhbGl0eSBzY2FsaW5nIGlzIG5vdCBjb21tb24uICBBcyBhIHJlc3VsdCwgYSBi cm93c2VyIG9uIGEgbW9iaWxlIGRldmljZSBjb3VsZCBoYXZlIGRpZmZpY3VsdHkgY29tcGx5aW5n IHdpdGggYSBtYW5kYXRlIHRvIHN1cHBvcnQgc3BhdGlhbCBzY2FsaW5nIHdpdGhpbiB0aGUgZW5j b2Rlci4gDQo+PiANCj4gVGhpcyBpcyBzYWQuIEZvciBnb29kIHVzYWJpbGl0eSBvZiB2aWRlbywg bWFpbnRhaW5lZCBmcmFtZSByYXRlIGlzIHVzdWFsbHkgbXVjaCBtb3JlIGltcG9ydGFudCB0aGFu IG1haW50YWluZWQgc3BhdGlhbCByZXNvbHV0aW9uLiBFLmcuIGZvciBzaWduIGxhbmd1YWdlIG9y IGxpcCByZWFkaW5nIHVzYWdlIHdpdGggYSBzaW5nbGUgcGVyc29uIGluIGltYWdlLCBhIGZyYW1l IHJhdGUgdW5kZXIgMjAgZnBzIGludHJvZHVjZXMgbG9zcyBvZiBsYW5ndWFnZSBjb250ZW50cywg YW5kIHJlcXVpcmVzIHRoZSB1c2VycyB0byB0cnkgdG8gZmlsbCBpbiB0aGUgZ2FwcyBieSBpbWFn aW5hdGlvbiwgd2hpbGUgc3BhdGlhbCByZXNvbHV0aW9uIHJlZHVjdGlvbiBkb3duIHRvIFFDSUYg Y2F1c2VzIG11Y2ggbGVzcyBoYXJtIHRvIGxhbmd1YWdlIHBlcmNlcHRpb24gcG9zc2liaWxpdGll cy4NCj4gDQo+IEd1bm5hcg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg== --Apple-Mail-A7D3EE77-6FF2-4FA8-9923-F6936EAC48F5 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+QSBtaW5p bXVtIGZyYW1lIHJhdGUgY2FuIGJlIGFzc3VyZWQgaW4gU1ZDIGJ5IGhhdmluZyB0aGUgYmFzZSBs YXllciBzdXBwb3J0IHRoZSByZXF1aXJlZCByZXNvbHV0aW9uIChlLmcuICZuYnNwOzMwIGZwcyks IHdoaWxlIGhhdmluZyBhZGRpdGlvbmFsIGxheWVycyBlbmFibGUgaGlnaGVyIGZyYW1lIHJhdGVz IChlLmcuIEFuIGFkZGl0aW9uYWwgMzAgZnBzLCBicmluZ2luZyB0aGUgdG90YWwgdG8gNjAgZnBz KS4gU29tZSBjaGlwc2V0cyBkbyBzdXBwb3J0IHRlbXBvcmFsIHNjYWxpbmcsIGFuZCBzbyZuYnNw O3RoZSBzaXR1YXRpb24gZm9yIHRlbXBvcmFsIHNjYWxpbmcgaXMgY29uc2lkZXJhYmx5IGJldHRl ci48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj5PbiBEZWMgMjEs IDIwMTIsIGF0IDE1OjI4LCAiR3VubmFyIEhlbGxzdHLDtm0iICZsdDs8YSBocmVmPSJtYWlsdG86 Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlIj5ndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U8 L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+ DQogIA0KICAgIDxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1JU08tODg1OS0xIiBo dHRwLWVxdWl2PSJDb250ZW50LVR5cGUiPg0KICANCiAgDQogICAgPGRpdiBjbGFzcz0ibW96LWNp dGUtcHJlZml4Ij5PbiAyMDEyLTEyLTIxIDE2OjQwLCBCZXJuYXJkIEFib2JhDQogICAgICB3cm90 ZTo8YnI+DQogICAgPC9kaXY+DQogICAgPGJsb2NrcXVvdGUgY2l0ZT0ibWlkOkJMVTAwMi1XMTVF NzNCM0FBRDVEQkM0RDEyQzVEQzkzMzYwQHBoeC5nYmwiIHR5cGU9ImNpdGUiPg0KICAgICAgPHN0 eWxlPjwhLS0NCi5obW1lc3NhZ2UgUA0Kew0KbWFyZ2luOjBweDsNCnBhZGRpbmc6MHB4DQp9DQpi b2R5LmhtbWVzc2FnZQ0Kew0KZm9udC1zaXplOiAxMnB0Ow0KZm9udC1mYW1pbHk6Q2FsaWJyaQ0K fQ0KLS0+PC9zdHlsZT4NCiAgICAgIDxkaXYgZGlyPSJsdHIiPlNWQyBzdXBwb3J0cyBtdWx0aXBs ZSBzY2FsYWJpbGl0eSBtZWNoYW5pc21zOiZuYnNwOw0KICAgICAgICB0ZW1wb3JhbCwgc3BhdGlh bCBhbmQgcXVhbGl0eS4mbmJzcDsgVGVtcG9yYWwgaXMgdGhlIG1vc3Qgd2lkZWx5DQogICAgICAg IGltcGxlbWVudGVkIGluIHNvZnR3YXJlIChhdCBsZWFzdCBmb3IgSC4yNjQvU1ZDKSwgYWx0aG91 Z2ggdGhlcmUNCiAgICAgICAgaXMgYW4gb3BlbiBzb3VyY2UgaW1wbGVtZW50YXRpb24gdGhhdCBz dXBwb3J0cyBhbGwgbW9kZXMuJm5ic3A7IEluDQogICAgICAgIGhhcmR3YXJlLCBzdXBwb3J0IGZv ciBzcGF0aWFsIG9yIHF1YWxpdHkgc2NhbGluZyBpcyBub3QgY29tbW9uLiZuYnNwOw0KICAgICAg ICBBcyBhIHJlc3VsdCwgYSBicm93c2VyIG9uIGEgbW9iaWxlIGRldmljZSBjb3VsZCBoYXZlIGRp ZmZpY3VsdHkNCiAgICAgICAgY29tcGx5aW5nIHdpdGggYSBtYW5kYXRlIHRvIHN1cHBvcnQgc3Bh dGlhbCBzY2FsaW5nIHdpdGhpbiB0aGUNCiAgICAgICAgZW5jb2Rlci4gPGJyPg0KICAgICAgICA8 ZGl2Pg0KICAgICAgICAgIDxkaXYgY2xhc3M9ImVjeFdvcmRTZWN0aW9uMSI+PGJyPg0KICAgICAg ICAgIDwvZGl2Pg0KICAgICAgICA8L2Rpdj4NCiAgICAgIDwvZGl2Pg0KICAgIDwvYmxvY2txdW90 ZT4NCiAgICBUaGlzIGlzIHNhZC4gRm9yIGdvb2QgdXNhYmlsaXR5IG9mIHZpZGVvLCBtYWludGFp bmVkIGZyYW1lIHJhdGUgaXMNCiAgICB1c3VhbGx5IG11Y2ggbW9yZSBpbXBvcnRhbnQgdGhhbiBt YWludGFpbmVkIHNwYXRpYWwgcmVzb2x1dGlvbi4gRS5nLg0KICAgIGZvciBzaWduIGxhbmd1YWdl IG9yIGxpcCByZWFkaW5nIHVzYWdlIHdpdGggYSBzaW5nbGUgcGVyc29uIGluDQogICAgaW1hZ2Us IGEgZnJhbWUgcmF0ZSB1bmRlciAyMCBmcHMgaW50cm9kdWNlcyBsb3NzIG9mIGxhbmd1YWdlDQog ICAgY29udGVudHMsIGFuZCByZXF1aXJlcyB0aGUgdXNlcnMgdG8gdHJ5IHRvIGZpbGwgaW4gdGhl IGdhcHMgYnkNCiAgICBpbWFnaW5hdGlvbiwgd2hpbGUgc3BhdGlhbCByZXNvbHV0aW9uIHJlZHVj dGlvbiBkb3duIHRvIFFDSUYgY2F1c2VzDQogICAgbXVjaCBsZXNzIGhhcm0gdG8gbGFuZ3VhZ2Ug cGVyY2VwdGlvbiBwb3NzaWJpbGl0aWVzLjxicj4NCiAgICA8YnI+DQogICAgR3VubmFyPGJyPg0K ICAgIDxicj4NCiAgDQoNCjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPC9zcGFuPjxicj48c3Bhbj5ydGN3ZWIgbWFpbGluZyBsaXN0PC9zcGFuPjxicj48c3Bhbj48 YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PC9zcGFu Pjxicj48c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3J0Y3dlYiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+ PC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-A7D3EE77-6FF2-4FA8-9923-F6936EAC48F5-- --_ab360fe9-f14d-4847-8911-7e0aa478bf1b_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_ab360fe9-f14d-4847-8911-7e0aa478bf1b_-- From andrew.hutton@siemens-enterprise.com Sat Dec 22 05:17:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E5621F8B2E for ; Sat, 22 Dec 2012 05:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.056, 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 09r0jmESZ9HB for ; Sat, 22 Dec 2012 05:17:38 -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 7C47821F8B43 for ; Sat, 22 Dec 2012 05:17:37 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 0879D23F0505 for ; Sat, 22 Dec 2012 14:17:36 +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; Sat, 22 Dec 2012 14:17:35 +0100 From: "Hutton, Andrew" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN38Q0WdzBi0dEWkqbZL0YDfKFj5gkzCvw Date: Sat, 22 Dec 2012 13:17:18 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0139B118@MCHP04MSX.global-ad.net> References: <50D2CC6A.4090500@ericsson.com> <50D3E3BF.7070609@mozilla.com> <50D48DD8.3050702@nostrum.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: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF0139B118MCHP04MSXglobal_" 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: Sat, 22 Dec 2012 13:17:39 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF0139B118MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Roman's comments below. So +1 for providing some recommendations on additional audio codec's for RT= CWEB. Andy From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Roman Shpount Sent: 21 December 2012 21:43 To: Adam Roach Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Au= dio Codecs On Fri, Dec 21, 2012 at 11:27 AM, Adam Roach > wrote: What I think would be beneficial would be a section documenting codecs in w= idespread use today, where they're used, and what is gained by including th= em in WebRTC implementations (mostly transcoder-free interop with those oth= er implementations). Documenting that AMR is used in 3GPP VoIP networks wou= ld allow implementors to make an educated decision about the benefit of inc= luding that codec. A similar mention that many modern VoIP phones support G= .722 and/or AAC-LD would provide similar guidance. In reality very few phones support AAC-LD. For me the major concern is support for G.722. There is no reason not to su= pport it. None. It is free, it is efficient, and it sounds better then G.71= 1 any day of the week. It was not made an MTI for political reasons to prom= ote OPUS. I think it deserves a SHOULD in the standard. As far as AMR and AMR-WB are concerned, they should be implemented if your= platform provides it. I, personally, would never pay a license fee for the= se codecs, but if implementing a browser on a cell phone where these codecs= are present, I would make an extra effort to support them. So, these codec= s probably do not deserve a SHOULD, but some guidance to implementers is pr= obably required. _____________ Roman Shpount --_000_9F33F40F6F2CD847824537F3C4E37DDF0139B118MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Roman’= s comments below.

 <= /p>

So +1 for providing s= ome recommendations on additional audio codec’s for RTCWEB.

 <= /p>

Andy

 <= /p>

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: 21 December 2012 21:43
To: Adam Roach
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recomme= nded Audio Codecs

 


On Fri, Dec 21, 2012 at 11:27 AM, Adam Roach <adam@nostrum.com>= wrote:

What I think would be beneficial would be a section = documenting codecs in widespread use today, where they're used, and what is= gained by including them in WebRTC implementations (mostly transcoder-free= interop with those other implementations). Documenting that AMR is used in 3GPP VoIP networks would allow implementor= s to make an educated decision about the benefit of including that codec. A= similar mention that many modern VoIP phones support G.722 and/or AAC-LD w= ould provide similar guidance.

 

In reality very few phones support AAC-LD. 

 

For me the major concern is support for G.722. There= is no reason not to support it. None. It is free, it is efficient, and it = sounds better then G.711 any day of the week. It was not made an MTI for po= litical reasons to promote OPUS. I think it deserves a SHOULD in the standard.

 

As far  as AMR and AMR-WB are concerned, they s= hould be implemented if your platform provides it. I, personally, would nev= er pay a license fee for these codecs, but if implementing a browser on a c= ell phone where these codecs are present, I would make an extra effort to support them. So, these codecs probably do= not deserve a SHOULD, but some guidance to implementers is probably r= equired.

_____________
Roman Shpount

 

--_000_9F33F40F6F2CD847824537F3C4E37DDF0139B118MCHP04MSXglobal_-- From adam@nostrum.com Sat Dec 22 09:09:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C66421F8A1E for ; Sat, 22 Dec 2012 09:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 gsA-O+t08eX7 for ; Sat, 22 Dec 2012 09:09:48 -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 4D9EF21F8976 for ; Sat, 22 Dec 2012 09:09:48 -0800 (PST) Received: from [192.168.0.159] (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 qBMH9kqd060788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Dec 2012 11:09:47 -0600 (CST) (envelope-from adam@nostrum.com) References: <50D2CC6A.4090500@ericsson.com> <50D3E3BF.7070609@mozilla.com> <50D48DD8.3050702@nostrum.com> <9F33F40F6F2CD847824537F3C4E37DDF0139B118@MCHP04MSX.global-ad.net> Mime-Version: 1.0 (1.0) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0139B118@MCHP04MSX.global-ad.net> Content-Type: multipart/alternative; boundary=Apple-Mail-D86817BE-39D3-466C-8CD7-73002C150CFC Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10A403) From: Adam Roach Date: Sat, 22 Dec 2012 11:12:19 -0600 To: "Hutton, Andrew" 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: Sat, 22 Dec 2012 17:09:49 -0000 --Apple-Mail-D86817BE-39D3-466C-8CD7-73002C150CFC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Recommendations or *normative* recommendations?=20 I think the former is a very good idea. The latter, not so much.=20 /a On Dec 22, 2012, at 7:17, "Hutton, Andrew" wrote: > I agree with Roman=E2=80=99s comments below. > =20 > So +1 for providing some recommendations on additional audio codec=E2=80=99= s for RTCWEB. > =20 > Andy > =20 > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O= f Roman Shpount > Sent: 21 December 2012 21:43 > To: Adam Roach > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended A= udio Codecs > =20 >=20 > On Fri, Dec 21, 2012 at 11:27 AM, Adam Roach wrote: > What I think would be beneficial would be a section documenting codecs in w= idespread use today, where they're used, and what is gained by including the= m in WebRTC implementations (mostly transcoder-free interop with those other= implementations). Documenting that AMR is used in 3GPP VoIP networks would a= llow implementors to make an educated decision about the benefit of includin= g that codec. A similar mention that many modern VoIP phones support G.722 a= nd/or AAC-LD would provide similar guidance. > =20 > In reality very few phones support AAC-LD.=20 > =20 > For me the major concern is support for G.722. There is no reason not to s= upport it. None. It is free, it is efficient, and it sounds better then G.71= 1 any day of the week. It was not made an MTI for political reasons to promo= te OPUS. I think it deserves a SHOULD in the standard. > =20 > As far as AMR and AMR-WB are concerned, they should be implemented if you= r platform provides it. I, personally, would never pay a license fee for the= se codecs, but if implementing a browser on a cell phone where these codecs a= re present, I would make an extra effort to support them. So, these codecs p= robably do not deserve a SHOULD, but some guidance to implementers is probab= ly required. > _____________ > Roman Shpount > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-D86817BE-39D3-466C-8CD7-73002C150CFC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Recommendations or *normative* recomme= ndations? 

I think the former is a very good i= dea. The latter,  not so much. 

/a
On Dec 22, 2012, at 7:17, "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com> wro= te:

=

I agree with Roman=E2=80=99= s comments below.

 

So +1 for providing some re= commendations on additional audio codec=E2=80=99s for RTCWEB.

 

Andy

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: 21 December 2012 21:43
To: Adam Roach
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommen= ded Audio Codecs

 


On Fri, Dec 21, 2012 at 11:27 AM, Adam Roach <adam@nostrum.com> w= rote:

What I think would be beneficial would be a section d= ocumenting codecs in widespread use today, where they're used, and what is g= ained by including them in WebRTC implementations (mostly transcoder-free in= terop with those other implementations). Documenting that AMR is used in 3GPP VoIP networks would allow implementors= to make an educated decision about the benefit of including that codec. A s= imilar mention that many modern VoIP phones support G.722 and/or AAC-LD woul= d provide similar guidance.

 

In reality very few phones support AAC-LD. =

 

For me the major concern is support for G.722. There i= s no reason not to support it. None. It is free, it is efficient, and it sou= nds better then G.711 any day of the week. It was not made an MTI for politi= cal reasons to promote OPUS. I think it deserves a SHOULD in the standard.

 

As far  as AMR and AMR-WB are concerned, they sh= ould be implemented if your platform provides it. I, personally, would never= pay a license fee for these codecs, but if implementing a browser on a cell= phone where these codecs are present, I would make an extra effort to support them. So, these codecs probably do n= ot deserve a SHOULD, but some guidance to implementers is probably requ= ired.

_____________
Roman Shpount

 

____________________= ___________________________
rtcweb mailing list
rtcweb@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org= /mailman/listinfo/rtcweb
= --Apple-Mail-D86817BE-39D3-466C-8CD7-73002C150CFC-- From alex@vidyo.com Sat Dec 22 22:50:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4236D21F891C for ; Sat, 22 Dec 2012 22:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.515 X-Spam-Level: X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZGYuIVYqfRE for ; Sat, 22 Dec 2012 22:50:22 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 9F15421F84F5 for ; Sat, 22 Dec 2012 22:50:22 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 005D28BE645; Sun, 23 Dec 2012 01:50:23 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 8D4A88BE297; Sun, 23 Dec 2012 01:50:23 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Sun, 23 Dec 2012 01:50:08 -0500 From: Alex Eleftheriadis To: Bernard Aboba Date: Sun, 23 Dec 2012 01:50:19 -0500 Thread-Topic: [rtcweb] Support of video with different resolutions Thread-Index: Ac3g2cY5ghqIGqPBTuSW20fXcsuy6A== Message-ID: <09A5A7B8-5719-48AE-8A8D-C0E9961563B6@vidyo.com> References: <7594FB04B1934943A5C02806D1A2204B06E211@ESESSMB209.ericsson.se> <50D4F06D.3020602@omnitor.se> In-Reply-To: <50D4F06D.3020602@omnitor.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_09A5A7B8571948AE8A8DC0E9961563B6vidyocom_" MIME-Version: 1.0 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: Sun, 23 Dec 2012 06:50:23 -0000 --_000_09A5A7B8571948AE8A8DC0E9961563B6vidyocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Benard, I don't believe that it is true that temporal is the most widely im= plemented in software. Vidyo introduced, and has been shipping, software-b= ased temporal+scalable SVC since 2008 (with deployments including Google+ H= angouts). What other implementation are you referring to that would tip the= scale towards temporal only? --Alex On Dec 22, 2012, at 1:27 AM, Gunnar Hellstr=F6m > wrote: On 2012-12-21 16:40, Bernard Aboba wrote: SVC supports multiple scalability mechanisms: temporal, spatial and qualit= y. Temporal is the most widely implemented in software (at least for H.264= /SVC), although there is an open source implementation that supports all mo= des. In hardware, support for spatial or quality scaling is not common. A= s a result, a browser on a mobile device could have difficulty complying wi= th a mandate to support spatial scaling within the encoder. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_09A5A7B8571948AE8A8DC0E9961563B6vidyocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Benard, I don't believe= that it is true that temporal is the most widely implemented in software. = Vidyo introduced, and has been shipping,  software-based temporal+scal= able SVC since 2008 (with deployments including Google+ Hangouts). Wha= t other implementation are you referring to that would tip the scale toward= s temporal only? 
 
--Alex

On Dec 22, 2012, at 1:27 AM, Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor.se>= wrote:

=20 =20 =20
On 2012-12-21 16:40, Bernard Aboba wrote:
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.&nbs= p; As a result, a browser on a mobile device could have difficulty complying with a mandate to support spatial scaling within the encoder.


_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org">rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb

= --_000_09A5A7B8571948AE8A8DC0E9961563B6vidyocom_-- From gunnar.hellstrom@omnitor.se Sat Dec 22 23:47:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E6821F8AD5 for ; Sat, 22 Dec 2012 23:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vp91vu8Imu4T for ; Sat, 22 Dec 2012 23:47:00 -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 5D52021F8ACB for ; Sat, 22 Dec 2012 23:46:51 -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 ; Sun, 23 Dec 2012 08:46:42 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id 427623A163 for ; Sun, 23 Dec 2012 08:46:42 +0100 (CET) Message-ID: <50D6B6E3.5000102@omnitor.se> Date: Sun, 23 Dec 2012 08:46:43 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= 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: <50D2CC6A.4090500@ericsson.com> <50D3E3BF.7070609@mozilla.com> <50D48DD8.3050702@nostrum.com> <9F33F40F6F2CD847824537F3C4E37DDF0139B118@MCHP04MSX.global-ad.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000308070007040109040806" 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, 23 Dec 2012 07:47:02 -0000 This is a multi-part message in MIME format. --------------000308070007040109040806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit There is an accessibility side of this as well. Wide band audio can make it much easier for persons with hearing impairments to use voice communication over distance. Therefore both US and European draft regulation or draft standards for support of regulation requires wide band audio wherever you have voice communication. And these drafts point at G.722 as the common codec at least to assure interoperability with wide-band audio between providers. These draft regulations aim at public procurement and at marketing of electronic communication products and services. Therefore, it seems logical to include G.722 in a codec recommendation document. Gunnar On 2012-12-22 18:12, Adam Roach wrote: > Recommendations or *normative* recommendations? > > I think the former is a very good idea. The latter, not so much. > > /a > > On Dec 22, 2012, at 7:17, "Hutton, Andrew" > > wrote: > >> I agree with Roman's comments below. >> >> So +1 for providing some recommendations on additional audio codec's >> for RTCWEB. >> >> Andy >> >> *From:*rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Roman Shpount >> *Sent:* 21 December 2012 21:43 >> *To:* Adam Roach >> *Cc:* rtcweb@ietf.org >> *Subject:* Re: [rtcweb] Call for Consensus Regarding Selecting >> Recommended Audio Codecs >> >> >> On Fri, Dec 21, 2012 at 11:27 AM, Adam Roach > > wrote: >> >> What I think would be beneficial would be a section documenting >> codecs in widespread use today, where they're used, and what is >> gained by including them in WebRTC implementations (mostly >> transcoder-free interop with those other implementations). >> Documenting that AMR is used in 3GPP VoIP networks would allow >> implementors to make an educated decision about the benefit of >> including that codec. A similar mention that many modern VoIP >> phones support G.722 and/or AAC-LD would provide similar guidance. >> >> In reality very few phones support AAC-LD. >> >> For me the major concern is support for G.722. There is no reason not >> to support it. None. It is free, it is efficient, and it sounds >> better then G.711 any day of the week. It was not made an MTI for >> political reasons to promote OPUS. I think it deserves a SHOULD in >> the standard. >> >> As far as AMR and AMR-WB are concerned, they should be implemented >> if your platform provides it. I, personally, would never pay a >> license fee for these codecs, but if implementing a browser on a cell >> phone where these codecs are present, I would make an extra effort to >> support them. So, these codecs probably do not deserve a SHOULD, but >> some guidance to implementers is probably required. >> >> _____________ >> 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 --------------000308070007040109040806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
There is an accessibility side of this as well.

Wide band audio can make it much easier for persons with hearing impairments to use voice communication over distance.
Therefore both US and European draft regulation or draft standards for support of regulation requires wide band audio wherever you have voice communication. And these drafts point at G.722 as the common codec at least to assure interoperability with wide-band audio between providers.
These draft regulations aim at public procurement and at marketing of electronic communication products and services.

Therefore, it seems logical to include G.722 in a codec recommendation document.

Gunnar


On 2012-12-22 18:12, Adam Roach wrote:
Recommendations or *normative* recommendations? 

I think the former is a very good idea. The latter,  not so much. 

/a

On Dec 22, 2012, at 7:17, "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com> wrote:

I agree with Roman’s comments below.

 

So +1 for providing some recommendations on additional audio codec’s for RTCWEB.

 

Andy

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: 21 December 2012 21:43
To: Adam Roach
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

 


On Fri, Dec 21, 2012 at 11:27 AM, Adam Roach <adam@nostrum.com> wrote:

What I think would be beneficial would be a section documenting codecs in widespread use today, where they're used, and what is gained by including them in WebRTC implementations (mostly transcoder-free interop with those other implementations). Documenting that AMR is used in 3GPP VoIP networks would allow implementors to make an educated decision about the benefit of including that codec. A similar mention that many modern VoIP phones support G.722 and/or AAC-LD would provide similar guidance.

 

In reality very few phones support AAC-LD. 

 

For me the major concern is support for G.722. There is no reason not to support it. None. It is free, it is efficient, and it sounds better then G.711 any day of the week. It was not made an MTI for political reasons to promote OPUS. I think it deserves a SHOULD in the standard.

 

As far  as AMR and AMR-WB are concerned, they should be implemented if your platform provides it. I, personally, would never pay a license fee for these codecs, but if implementing a browser on a cell phone where these codecs are present, I would make an extra effort to support them. So, these codecs probably do not deserve a SHOULD, but some guidance to implementers is probably required.

_____________
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

--------------000308070007040109040806-- From bernard_aboba@hotmail.com Sat Dec 22 23:49:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B486E21F8ACB for ; Sat, 22 Dec 2012 23:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.93 X-Spam-Level: X-Spam-Status: No, score=-101.93 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, URIBL_RHS_DOB=1.083, 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 Z1MMUgi+qlWP for ; Sat, 22 Dec 2012 23:49:50 -0800 (PST) Received: from blu0-omc3-s29.blu0.hotmail.com (blu0-omc3-s29.blu0.hotmail.com [65.55.116.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8F90A21F8A8C for ; Sat, 22 Dec 2012 23:49:50 -0800 (PST) Received: from BLU404-EAS275 ([65.55.116.74]) by blu0-omc3-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 22 Dec 2012 23:49:49 -0800 X-EIP: [G/mtf1nK+7WxCVVqtkrKSStkV0+ioK5P] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: MIME-Version: 1.0 From: Bernard Aboba To: "=?utf-8?Q?rtcweb@ietf.org?=" , =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= Importance: Normal Date: Sun, 23 Dec 2012 07:49:48 +0000 Content-Type: multipart/alternative; boundary="_9DCFE9D3-B59E-4F03-8D42-E8F8A1A49D16_" X-OriginalArrivalTime: 23 Dec 2012 07:49:49.0995 (UTC) FILETIME=[16001FB0:01CDE0E2] Subject: Re: [rtcweb] =?utf-8?q?Call_for_Consensus_Regarding_Selecting_Recomme?= =?utf-8?q?nded=09Audio_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, 23 Dec 2012 07:49:51 -0000 --_9DCFE9D3-B59E-4F03-8D42-E8F8A1A49D16_ Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" SSB3b3VsZCBhZ3JlZS4gIEcuNzIyIGlzIHdpZGVseSBpbXBsZW1lbnRlZCBhbmQgdGhlcmUgYXJl IG5vIElQUiBpc3N1ZXMuIFNvIG1ha2luZyBpdCBhIFNIT1VMRCBzZWVtcyBjb21wZWxsaW5nLg0K DQoNCkZyb206IEd1bm5hciBIZWxsc3Ryw7ZtDQpTZW50OiDigI5EZWNlbWJlcuKAjiDigI4yMuKA jiwg4oCOMjAxMiDigI4xMeKAjjrigI40N+KAjiDigI5QTQ0KVG86IHJ0Y3dlYkBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtydGN3ZWJdIENhbGwgZm9yIENvbnNlbnN1cyBSZWdhcmRpbmcgU2VsZWN0 aW5nIFJlY29tbWVuZGVkIEF1ZGlvIENvZGVjcw0KDQoNCg0KVGhlcmUgaXMgYW4gYWNjZXNzaWJp bGl0eSBzaWRlIG9mIHRoaXMgYXMgd2VsbC4NCg0KV2lkZSBiYW5kIGF1ZGlvIGNhbiBtYWtlIGl0 IG11Y2ggZWFzaWVyIGZvciBwZXJzb25zIHdpdGggaGVhcmluZyBpbXBhaXJtZW50cyB0byB1c2Ug dm9pY2UgY29tbXVuaWNhdGlvbiBvdmVyIGRpc3RhbmNlLiANClRoZXJlZm9yZSBib3RoIFVTIGFu ZCBFdXJvcGVhbiBkcmFmdCByZWd1bGF0aW9uIG9yIGRyYWZ0IHN0YW5kYXJkcyBmb3Igc3VwcG9y dCBvZiByZWd1bGF0aW9uIHJlcXVpcmVzIHdpZGUgYmFuZCBhdWRpbyB3aGVyZXZlciB5b3UgaGF2 ZSB2b2ljZSBjb21tdW5pY2F0aW9uLiBBbmQgdGhlc2UgZHJhZnRzIHBvaW50IGF0IEcuNzIyIGFz IHRoZSBjb21tb24gY29kZWMgYXQgbGVhc3QgdG8gYXNzdXJlIGludGVyb3BlcmFiaWxpdHkgd2l0 aCB3aWRlLWJhbmQgYXVkaW8gYmV0d2VlbiBwcm92aWRlcnMuDQpUaGVzZSBkcmFmdCByZWd1bGF0 aW9ucyBhaW0gYXQgcHVibGljIHByb2N1cmVtZW50IGFuZCBhdCBtYXJrZXRpbmcgb2YgZWxlY3Ry b25pYyBjb21tdW5pY2F0aW9uIHByb2R1Y3RzIGFuZCBzZXJ2aWNlcy4NCg0KVGhlcmVmb3JlLCBp dCBzZWVtcyBsb2dpY2FsIHRvIGluY2x1ZGUgRy43MjIgaW4gYSBjb2RlYw0KIHJlY29tbWVuZGF0 aW9uIGRvY3VtZW50LiANCkd1bm5hcg0KDQoNCk9uIDIwMTItMTItMjIgMTg6MTIsIEFkYW0gUm9h Y2ggd3JvdGU6DQoNCg0KDQpSZWNvbW1lbmRhdGlvbnMgb3IgKm5vcm1hdGl2ZSogcmVjb21tZW5k YXRpb25zPyANCg0KDQoNCg0KSSB0aGluayB0aGUgZm9ybWVyIGlzIGEgdmVyeSBnb29kIGlkZWEu IFRoZSBsYXR0ZXIsICBub3Qgc28gbXVjaC4gDQoNCg0KDQoNCi9hDQoNCk9uIERlYyAyMiwgMjAx MiwgYXQgNzoxNywgIkh1dHRvbiwgQW5kcmV3IiA8YW5kcmV3Lmh1dHRvbkBzaWVtZW5zLWVudGVy cHJpc2UuY29tPiB3cm90ZToNCg0KDQoNCg0KDQoNCkkgYWdyZWUgd2l0aCBSb21hbuKAmXMgY29t bWVudHMgYmVsb3cuDQoNCiANCg0KU28gKzEgZm9yIHByb3ZpZGluZyBzb21lIHJlY29tbWVuZGF0 aW9ucyBvbiBhZGRpdGlvbmFsIGF1ZGlvIGNvZGVj4oCZcyBmb3IgUlRDV0VCLg0KDQogDQoNCkFu ZHkNCg0KIA0KDQoNCg0KDQpGcm9tOiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0 Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9tYW4gU2hwb3VudA0KU2VudDog MjEgRGVjZW1iZXIgMjAxMiAyMTo0Mw0KVG86IEFkYW0gUm9hY2gNCkNjOiBydGN3ZWJAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBDYWxsIGZvciBDb25zZW5zdXMgUmVnYXJkaW5nIFNl bGVjdGluZyBSZWNvbW1lbmRlZCBBdWRpbyBDb2RlY3MNCg0KIA0KDQoNCg0KDQoNCk9uIEZyaSwg RGVjIDIxLCAyMDEyIGF0IDExOjI3IEFNLCBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPiB3 cm90ZToNCg0KDQoNCldoYXQgSSB0aGluayB3b3VsZCBiZSBiZW5lZmljaWFsIHdvdWxkIGJlIGEg c2VjdGlvbiBkb2N1bWVudGluZyBjb2RlY3MgaW4gd2lkZXNwcmVhZCB1c2UgdG9kYXksIHdoZXJl IHRoZXkncmUgdXNlZCwgYW5kIHdoYXQgaXMgZ2FpbmVkIGJ5IGluY2x1ZGluZyB0aGVtIGluIFdl YlJUQyBpbXBsZW1lbnRhdGlvbnMgKG1vc3RseSB0cmFuc2NvZGVyLWZyZWUgaW50ZXJvcCB3aXRo IHRob3NlIG90aGVyIGltcGxlbWVudGF0aW9ucykuIERvY3VtZW50aW5nIHRoYXQgQU1SIGlzIHVz ZWQgaW4gM0dQUCBWb0lQIG5ldHdvcmtzIHdvdWxkIGFsbG93IGltcGxlbWVudG9ycyB0byBtYWtl IGFuIGVkdWNhdGVkIGRlY2lzaW9uIGFib3V0IHRoZSBiZW5lZml0IG9mIGluY2x1ZGluZyB0aGF0 IGNvZGVjLiBBIHNpbWlsYXIgbWVudGlvbiB0aGF0IG1hbnkgbW9kZXJuIFZvSVAgcGhvbmVzIHN1 cHBvcnQgRy43MjIgYW5kL29yIEFBQy1MRCB3b3VsZCBwcm92aWRlIHNpbWlsYXIgZ3VpZGFuY2Uu DQoNCg0KIA0KDQpJbiByZWFsaXR5IHZlcnkgZmV3IHBob25lcyBzdXBwb3J0IEFBQy1MRC4gDQoN Cg0KIA0KDQoNCkZvciBtZSB0aGUgbWFqb3IgY29uY2VybiBpcyBzdXBwb3J0IGZvciBHLjcyMi4g VGhlcmUgaXMgbm8gcmVhc29uIG5vdCB0byBzdXBwb3J0IGl0LiBOb25lLiBJdCBpcyBmcmVlLCBp dCBpcyBlZmZpY2llbnQsIGFuZCBpdCBzb3VuZHMgYmV0dGVyIHRoZW4gRy43MTEgYW55IGRheSBv ZiB0aGUgd2Vlay4gSXQgd2FzIG5vdCBtYWRlIGFuIE1USSBmb3IgcG9saXRpY2FsIHJlYXNvbnMg dG8gcHJvbW90ZSBPUFVTLiBJIHRoaW5rIGl0IGRlc2VydmVzIGEgU0hPVUxEIGluIHRoZSBzdGFu ZGFyZC4NCg0KDQogDQoNCg0KQXMgZmFyICBhcyBBTVIgYW5kIEFNUi1XQiBhcmUgY29uY2VybmVk LCB0aGV5IHNob3VsZCBiZSBpbXBsZW1lbnRlZCBpZiB5b3VyIHBsYXRmb3JtIHByb3ZpZGVzIGl0 LiBJLCBwZXJzb25hbGx5LCB3b3VsZCBuZXZlciBwYXkgYSBsaWNlbnNlIGZlZSBmb3IgdGhlc2Ug Y29kZWNzLCBidXQgaWYgaW1wbGVtZW50aW5nIGEgYnJvd3NlciBvbiBhIGNlbGwgcGhvbmUgd2hl cmUgdGhlc2UgY29kZWNzIGFyZSBwcmVzZW50LCBJIHdvdWxkIG1ha2UgYW4gZXh0cmEgZWZmb3J0 IHRvIHN1cHBvcnQgdGhlbS4gU28sIHRoZXNlIGNvZGVjcyBwcm9iYWJseSBkbyBub3QgZGVzZXJ2 ZSBhIFNIT1VMRCwgYnV0IHNvbWUgZ3VpZGFuY2UgdG8gaW1wbGVtZW50ZXJzIGlzIHByb2JhYmx5 IHJlcXVpcmVkLg0KDQoNCg0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQogDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBt YWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGN3ZWINCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI= --_9DCFE9D3-B59E-4F03-8D42-E8F8A1A49D16_ Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" PGh0bWw+PGhlYWQ+PHN0eWxlIGRhdGEtZXh0ZXJuYWxzdHlsZT0idHJ1ZSI+CnAuTXNvTGlzdFBh cmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGggewptYXJn aW4tdG9wOjBpbjsKbWFyZ2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1hcmdpbi1s ZWZ0Oi41aW47Cm1hcmdpbi1ib3R0b206LjAwMDFwdDsKfQoKcC5Nc29MaXN0UGFyYWdyYXBoQ3hT cEZpcnN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCBkaXYuTXNvTGlzdFBhcmFncmFw aEN4U3BGaXJzdCwgcC5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgbGkuTXNvTGlzdFBhcmFn cmFwaEN4U3BNaWRkbGUsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgcC5Nc29MaXN0 UGFyYWdyYXBoQ3hTcExhc3QsIGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgZGl2Lk1zb0xp c3RQYXJhZ3JhcGhDeFNwTGFzdCB7Cm1hcmdpbi10b3A6MGluOwptYXJnaW4tcmlnaHQ6MGluOwpt YXJnaW4tYm90dG9tOjBpbjsKbWFyZ2luLWxlZnQ6LjVpbjsKbWFyZ2luLWJvdHRvbTouMDAwMXB0 OwpsaW5lLWhlaWdodDoxMTUlOwp9Cjwvc3R5bGU+PHN0eWxlPjwhLS0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbCB7Cm1hcmdpbjowY20gMGNtIDBwdDsKZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsKZm9udC1zaXplOjEycHQ7Cn0KCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsgewpjb2xvcjpibHVlOwp0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l Owp9CgpzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsKY29sb3I6cHVycGxlOwp0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOwp9CgpzcGFuLkVtYWlsU3R5bGUxNyB7CmNvbG9yOnJnYigzMSwgNzMs IDEyNSk7CmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Cn0KCi5Nc29DaHBEZWZh dWx0IHsKfQoKZGl2LldvcmRTZWN0aW9uMSB7Cn0KLS0+PC9zdHlsZT48L2hlYWQ+PGJvZHk+PGRp diBkYXRhLWV4dGVybmFsc3R5bGU9ImZhbHNlIiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSwn U2Vnb2UgVUknLE1laXJ5bywnTWljcm9zb2Z0IFlhSGVpIFVJJywnTWljcm9zb2Z0IEpoZW5nSGVp IFVJJywnTWFsZ3VuIEdvdGhpYycsJ0tobWVyIFVJJywnTmlybWFsYSBVSScsVHVuZ2EsJ0xhbyBV SScsRWJyaW1hLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE2cHg7Ij48ZGl2Pkkgd291bGQgYWdyZWUu Jm5ic3A7IEcuNzIyIGlzIHdpZGVseSBpbXBsZW1lbnRlZCBhbmQgdGhlcmUgYXJlIG5vIElQUiBp c3N1ZXMuIFNvIG1ha2luZyBpdCBhIFNIT1VMRCBzZWVtcyBjb21wZWxsaW5nLjwvZGl2PjxkaXY+ Jm5ic3A7PC9kaXY+CTxkaXYgc3R5bGU9ImJvcmRlci10b3AtY29sb3I6IHJnYigyMjUsIDIyNSwg MjI1KTsgYm9yZGVyLXRvcC13aWR0aDogMXB4OyBib3JkZXItdG9wLXN0eWxlOiBzb2xpZDsiPgkJ PHN0cm9uZz5Gcm9tOjwvc3Ryb25nPiZuYnNwO0d1bm5hciBIZWxsc3Ryw7ZtPGJyPgkJPHN0cm9u Zz5TZW50Ojwvc3Ryb25nPiZuYnNwO+KAjkRlY2VtYmVy4oCOIOKAjjIy4oCOLCDigI4yMDEyIOKA jjEx4oCOOuKAjjQ34oCOIOKAjlBNPGJyPgkJPHN0cm9uZz5Ubzo8L3N0cm9uZz4mbmJzcDtydGN3 ZWJAaWV0Zi5vcmc8YnI+CQk8c3Ryb25nPlN1YmplY3Q6PC9zdHJvbmc+Jm5ic3A7UmU6IFtydGN3 ZWJdIENhbGwgZm9yIENvbnNlbnN1cyBSZWdhcmRpbmcgU2VsZWN0aW5nIFJlY29tbWVuZGVkCUF1 ZGlvIENvZGVjczxicj4JPC9kaXY+CTxkaXY+Jm5ic3A7PC9kaXY+CiAgCiAgICAKICAKICAKICAg IDxkaXYgY2xhc3M9IiBtb3otY2l0ZS1wcmVmaXgiPlRoZXJlIGlzIGFuIGFjY2Vzc2liaWxpdHkg c2lkZSBvZiB0aGlzCiAgICAgIGFzIHdlbGwuPGJyPgogICAgICA8YnI+CiAgICAgIFdpZGUgYmFu ZCBhdWRpbyBjYW4gbWFrZSBpdCBtdWNoIGVhc2llciBmb3IgcGVyc29ucyB3aXRoIGhlYXJpbmcK ICAgICAgaW1wYWlybWVudHMgdG8gdXNlIHZvaWNlIGNvbW11bmljYXRpb24gb3ZlciBkaXN0YW5j ZS4gPGJyPgogICAgICBUaGVyZWZvcmUgYm90aCBVUyBhbmQgRXVyb3BlYW4gZHJhZnQgcmVndWxh dGlvbiBvciBkcmFmdCBzdGFuZGFyZHMKICAgICAgZm9yIHN1cHBvcnQgb2YgcmVndWxhdGlvbiBy ZXF1aXJlcyB3aWRlIGJhbmQgYXVkaW8gd2hlcmV2ZXIgeW91CiAgICAgIGhhdmUgdm9pY2UgY29t bXVuaWNhdGlvbi4gQW5kIHRoZXNlIGRyYWZ0cyBwb2ludCBhdCBHLjcyMiBhcyB0aGUKICAgICAg Y29tbW9uIGNvZGVjIGF0IGxlYXN0IHRvIGFzc3VyZSBpbnRlcm9wZXJhYmlsaXR5IHdpdGggd2lk ZS1iYW5kCiAgICAgIGF1ZGlvIGJldHdlZW4gcHJvdmlkZXJzLjxicj4KICAgICAgVGhlc2UgZHJh ZnQgcmVndWxhdGlvbnMgYWltIGF0IHB1YmxpYyBwcm9jdXJlbWVudCBhbmQgYXQgbWFya2V0aW5n CiAgICAgIG9mIGVsZWN0cm9uaWMgY29tbXVuaWNhdGlvbiBwcm9kdWN0cyBhbmQgc2VydmljZXMu PGJyPgogICAgICA8YnI+CiAgICAgIFRoZXJlZm9yZSwgaXQgc2VlbXMgbG9naWNhbCB0byBpbmNs dWRlIEcuNzIyIGluIGEgY29kZWMKICAgICAgcmVjb21tZW5kYXRpb24gZG9jdW1lbnQuIDxicj4K ICAgICAgPGJyPgogICAgICBHdW5uYXI8YnI+CiAgICAgIDxicj4KICAgICAgPGJyPgogICAgICBP biAyMDEyLTEyLTIyIDE4OjEyLCBBZGFtIFJvYWNoIHdyb3RlOjxicj4KICAgIDwvZGl2PgogICAg PGJsb2NrcXVvdGUgY2l0ZT0ibWlkOkI2RjY0QkRELUY3MjYtNEY5QS1CMzUwLTk2ODg5NjE0RDQ2 M0Bub3N0cnVtLmNvbSI+CiAgICAgIAogICAgICA8ZGl2PlJlY29tbWVuZGF0aW9ucyBvciAqbm9y bWF0aXZlKiByZWNvbW1lbmRhdGlvbnM/Jm5ic3A7PC9kaXY+CiAgICAgIDxkaXY+PGJyPgogICAg ICA8L2Rpdj4KICAgICAgPGRpdj5JIHRoaW5rIHRoZSBmb3JtZXIgaXMgYSB2ZXJ5IGdvb2QgaWRl YS4gVGhlIGxhdHRlciwgJm5ic3A7bm90IHNvCiAgICAgICAgbXVjaC4mbmJzcDs8L2Rpdj4KICAg ICAgPGRpdj48YnI+CiAgICAgIDwvZGl2PgogICAgICA8ZGl2Pi9hPGJyPgogICAgICAgIDxicj4K ICAgICAgICBPbiBEZWMgMjIsIDIwMTIsIGF0IDc6MTcsICJIdXR0b24sIEFuZHJldyIgJmx0Ozxh IHRhYmluZGV4PSItMSIgaHJlZj0ibWFpbHRvOmFuZHJldy5odXR0b25Ac2llbWVucy1lbnRlcnBy aXNlLmNvbSI+YW5kcmV3Lmh1dHRvbkBzaWVtZW5zLWVudGVycHJpc2UuY29tPC9hPiZndDsKICAg ICAgICB3cm90ZTo8YnI+CiAgICAgICAgPGJyPgogICAgICA8L2Rpdj4KICAgICAgPGJsb2NrcXVv dGU+CiAgICAgICAgPGRpdj4KICAgICAgICAgIAogICAgICAgICAgCiAgICAgICAgICAKICAgICAg ICAgIDxkaXYgY2xhc3M9IiBXb3JkU2VjdGlvbjEiPgogICAgICAgICAgICA8cCBjbGFzcz0iIE1z b05vcm1hbCI+PHNwYW4gc3R5bGU9J2NvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWls eTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIjsgZm9udC1zaXplOiAxMXB0Oyc+SQogICAgICAgICAg ICAgICAgYWdyZWUgd2l0aCBSb21hbuKAmXMgY29tbWVudHMgYmVsb3cuPC9zcGFuPjwvcD4KICAg ICAgICAgICAgPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSdjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsgZm9udC1mYW1pbHk6ICJDYWxpYnJpIiwic2Fucy1zZXJpZiI7IGZvbnQtc2l6 ZTogMTFwdDsnPiZuYnNwOzwvc3Bhbj48L3A+CiAgICAgICAgICAgIDxwIGNsYXNzPSIgTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0nY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiAi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOyBmb250LXNpemU6IDExcHQ7Jz5TbwogICAgICAgICAgICAg ICAgKzEgZm9yIHByb3ZpZGluZyBzb21lIHJlY29tbWVuZGF0aW9ucyBvbiBhZGRpdGlvbmFsCiAg ICAgICAgICAgICAgICBhdWRpbyBjb2RlY+KAmXMgZm9yIFJUQ1dFQi48L3NwYW4+PC9wPgogICAg ICAgICAgICA8cCBjbGFzcz0iIE1zb05vcm1hbCI+PHNwYW4gc3R5bGU9J2NvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyBmb250LWZhbWlseTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIjsgZm9udC1zaXpl OiAxMXB0Oyc+Jm5ic3A7PC9zcGFuPjwvcD4KICAgICAgICAgICAgPHAgY2xhc3M9IiBNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSdjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6ICJD YWxpYnJpIiwic2Fucy1zZXJpZiI7IGZvbnQtc2l6ZTogMTFwdDsnPkFuZHk8L3NwYW4+PC9wPgog ICAgICAgICAgICA8cCBjbGFzcz0iIE1zb05vcm1hbCI+PHNwYW4gc3R5bGU9J2NvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIjsgZm9udC1z aXplOiAxMXB0Oyc+Jm5ic3A7PC9zcGFuPjwvcD4KICAgICAgICAgICAgPGRpdiBzdHlsZT0iYm9y ZGVyLXdpZHRoOiBtZWRpdW0gbWVkaXVtIG1lZGl1bSAxLjVwdDsgYm9yZGVyLXN0eWxlOiBub25l IG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWNvbG9yOiBibGFjayBibGFjayBibGFjayBibHVlOyBw YWRkaW5nOiAwY20gMGNtIDBjbSA0cHQ7Ij4KICAgICAgICAgICAgICA8ZGl2PgogICAgICAgICAg ICAgICAgPGRpdiBzdHlsZT0iYm9yZGVyLXdpZHRoOiAxcHQgbWVkaXVtIG1lZGl1bTsgYm9yZGVy LXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMp IGJsYWNrIGJsYWNrOyBwYWRkaW5nOiAzcHQgMGNtIDBjbTsiPgogICAgICAgICAgICAgICAgICA8 cCBjbGFzcz0iIE1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiAiVGFob21h Iiwic2Fucy1zZXJpZiI7IGZvbnQtc2l6ZTogMTBwdDsnPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6ICJUYWhvbWEiLCJzYW5zLXNlcmlmIjsgZm9udC1zaXplOiAxMHB0 Oyc+CiAgICAgICAgICAgICAgICAgICAgICA8YSB0YWJpbmRleD0iLTEiIGhyZWY9Im1haWx0bzpy dGN3ZWItYm91bmNlc0BpZXRmLm9yZyI+cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+CiAgICAg ICAgICAgICAgICAgICAgICBbPGEgdGFiaW5kZXg9Ii0xIiBocmVmPSJtYWlsdG86cnRjd2ViLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT5dCiAgICAg ICAgICAgICAgICAgICAgICA8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvbWFuIFNocG91bnQ8YnI+CiAg ICAgICAgICAgICAgICAgICAgICA8Yj5TZW50OjwvYj4gMjEgRGVjZW1iZXIgMjAxMiAyMTo0Mzxi cj4KICAgICAgICAgICAgICAgICAgICAgIDxiPlRvOjwvYj4gQWRhbSBSb2FjaDxicj4KICAgICAg ICAgICAgICAgICAgICAgIDxiPkNjOjwvYj4gPGEgdGFiaW5kZXg9Ii0xIiBocmVmPSJtYWlsdG86 cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPgogICAgICAgICAgICAgICAg ICAgICAgPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBDYWxsIGZvciBDb25zZW5zdXMKICAg ICAgICAgICAgICAgICAgICAgIFJlZ2FyZGluZyBTZWxlY3RpbmcgUmVjb21tZW5kZWQgQXVkaW8g Q29kZWNzPC9zcGFuPjwvcD4KICAgICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAgIDwv ZGl2PgogICAgICAgICAgICAgIDxwIGNsYXNzPSIgTXNvTm9ybWFsIj4mbmJzcDs8L3A+CiAgICAg ICAgICAgICAgPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4KICAgICAgICAg ICAgICAgIDwvcD4KICAgICAgICAgICAgICA8ZGl2PgogICAgICAgICAgICAgICAgPHAgY2xhc3M9 IiBNc29Ob3JtYWwiPk9uIEZyaSwgRGVjIDIxLCAyMDEyIGF0IDExOjI3IEFNLAogICAgICAgICAg ICAgICAgICBBZGFtIFJvYWNoICZsdDs8YSB0YWJpbmRleD0iLTEiIGhyZWY9Im1haWx0bzphZGFt QG5vc3RydW0uY29tIiB0YXJnZXQ9Il9ibGFuayI+YWRhbUBub3N0cnVtLmNvbTwvYT4mZ3Q7CiAg ICAgICAgICAgICAgICAgIHdyb3RlOjwvcD4KICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAg ICAgICA8ZGl2PgogICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci13aWR0 aDogbWVkaXVtIG1lZGl1bSBtZWRpdW0gMXB0OyBib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBub25l IHNvbGlkOyBib3JkZXItY29sb3I6IGJsYWNrIGJsYWNrIGJsYWNrIHJnYigyMDQsIDIwNCwgMjA0 KTsgcGFkZGluZzogMGNtIDBjbSAwY20gNnB0OyBtYXJnaW4tcmlnaHQ6IDBjbTsgbWFyZ2luLWxl ZnQ6IDQuOHB0OyI+CiAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSIgTXNvTm9ybWFsIj5XaGF0 IEkgdGhpbmsgd291bGQgYmUgYmVuZWZpY2lhbAogICAgICAgICAgICAgICAgICAgIHdvdWxkIGJl IGEgc2VjdGlvbiBkb2N1bWVudGluZyBjb2RlY3MgaW4gd2lkZXNwcmVhZAogICAgICAgICAgICAg ICAgICAgIHVzZSB0b2RheSwgd2hlcmUgdGhleSdyZSB1c2VkLCBhbmQgd2hhdCBpcyBnYWluZWQg YnkKICAgICAgICAgICAgICAgICAgICBpbmNsdWRpbmcgdGhlbSBpbiBXZWJSVEMgaW1wbGVtZW50 YXRpb25zIChtb3N0bHkKICAgICAgICAgICAgICAgICAgICB0cmFuc2NvZGVyLWZyZWUgaW50ZXJv cCB3aXRoIHRob3NlIG90aGVyCiAgICAgICAgICAgICAgICAgICAgaW1wbGVtZW50YXRpb25zKS4g RG9jdW1lbnRpbmcgdGhhdCBBTVIgaXMgdXNlZCBpbgogICAgICAgICAgICAgICAgICAgIDNHUFAg Vm9JUCBuZXR3b3JrcyB3b3VsZCBhbGxvdyBpbXBsZW1lbnRvcnMgdG8gbWFrZQogICAgICAgICAg ICAgICAgICAgIGFuIGVkdWNhdGVkIGRlY2lzaW9uIGFib3V0IHRoZSBiZW5lZml0IG9mIGluY2x1 ZGluZwogICAgICAgICAgICAgICAgICAgIHRoYXQgY29kZWMuIEEgc2ltaWxhciBtZW50aW9uIHRo YXQgbWFueSBtb2Rlcm4gVm9JUAogICAgICAgICAgICAgICAgICAgIHBob25lcyBzdXBwb3J0IEcu NzIyIGFuZC9vciBBQUMtTEQgd291bGQgcHJvdmlkZQogICAgICAgICAgICAgICAgICAgIHNpbWls YXIgZ3VpZGFuY2UuPC9wPgogICAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPgogICAgICAgICAg ICAgIDwvZGl2PgogICAgICAgICAgICAgIDxkaXY+CiAgICAgICAgICAgICAgICA8cCBjbGFzcz0i IE1zb05vcm1hbCI+Jm5ic3A7PC9wPgogICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAg IDxwIGNsYXNzPSIgTXNvTm9ybWFsIj5JbiByZWFsaXR5IHZlcnkgZmV3IHBob25lcyBzdXBwb3J0 CiAgICAgICAgICAgICAgICBBQUMtTEQuJm5ic3A7PC9wPgogICAgICAgICAgICAgIDxkaXY+CiAg ICAgICAgICAgICAgICA8cCBjbGFzcz0iIE1zb05vcm1hbCI+Jm5ic3A7PC9wPgogICAgICAgICAg ICAgIDwvZGl2PgogICAgICAgICAgICAgIDxkaXY+CiAgICAgICAgICAgICAgICA8cCBjbGFzcz0i IE1zb05vcm1hbCI+Rm9yIG1lIHRoZSBtYWpvciBjb25jZXJuIGlzIHN1cHBvcnQKICAgICAgICAg ICAgICAgICAgZm9yIEcuNzIyLiBUaGVyZSBpcyBubyByZWFzb24gbm90IHRvIHN1cHBvcnQgaXQu IE5vbmUuCiAgICAgICAgICAgICAgICAgIEl0IGlzIGZyZWUsIGl0IGlzIGVmZmljaWVudCwgYW5k IGl0IHNvdW5kcyBiZXR0ZXIgdGhlbgogICAgICAgICAgICAgICAgICBHLjcxMSBhbnkgZGF5IG9m IHRoZSB3ZWVrLiBJdCB3YXMgbm90IG1hZGUgYW4gTVRJIGZvcgogICAgICAgICAgICAgICAgICBw b2xpdGljYWwgcmVhc29ucyB0byBwcm9tb3RlIE9QVVMuIEkgdGhpbmsgaXQgZGVzZXJ2ZXMKICAg ICAgICAgICAgICAgICAgYSBTSE9VTEQgaW4gdGhlIHN0YW5kYXJkLjwvcD4KICAgICAgICAgICAg ICA8L2Rpdj4KICAgICAgICAgICAgICA8ZGl2PgogICAgICAgICAgICAgICAgPHAgY2xhc3M9IiBN c29Ob3JtYWwiPiZuYnNwOzwvcD4KICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgICAgICA8 ZGl2PgogICAgICAgICAgICAgICAgPHAgY2xhc3M9IiBNc29Ob3JtYWwiPkFzIGZhciAmbmJzcDth cyBBTVIgYW5kIEFNUi1XQiBhcmUKICAgICAgICAgICAgICAgICAgY29uY2VybmVkLCB0aGV5IHNo b3VsZCBiZSBpbXBsZW1lbnRlZCBpZiB5b3VyIHBsYXRmb3JtCiAgICAgICAgICAgICAgICAgIHBy b3ZpZGVzIGl0LiBJLCBwZXJzb25hbGx5LCB3b3VsZCBuZXZlciBwYXkgYSBsaWNlbnNlCiAgICAg ICAgICAgICAgICAgIGZlZSBmb3IgdGhlc2UgY29kZWNzLCBidXQgaWYgaW1wbGVtZW50aW5nIGEg YnJvd3NlciBvbgogICAgICAgICAgICAgICAgICBhIGNlbGwgcGhvbmUgd2hlcmUgdGhlc2UgY29k ZWNzIGFyZSBwcmVzZW50LCBJIHdvdWxkCiAgICAgICAgICAgICAgICAgIG1ha2UgYW4gZXh0cmEg ZWZmb3J0IHRvIHN1cHBvcnQgdGhlbS4gU28sIHRoZXNlIGNvZGVjcwogICAgICAgICAgICAgICAg ICBwcm9iYWJseSBkbyBub3QgZGVzZXJ2ZSBhIFNIT1VMRCwgYnV0IHNvbWUmbmJzcDtndWlkYW5j ZSB0bwogICAgICAgICAgICAgICAgICBpbXBsZW1lbnRlcnMgaXMgcHJvYmFibHkgcmVxdWlyZWQu PC9wPgogICAgICAgICAgICAgICAgPGRpdj4KICAgICAgICAgICAgICAgICAgPGRpdj4KICAgICAg ICAgICAgICAgICAgICA8cCBjbGFzcz0iIE1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4KICAg ICAgICAgICAgICAgICAgICAgIFJvbWFuIFNocG91bnQ8L3A+CiAgICAgICAgICAgICAgICAgIDwv ZGl2PgogICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iIE1zb05vcm1hbCI+Jm5ic3A7PC9wPgog ICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgIDwv ZGl2PgogICAgICAgICAgPC9kaXY+CiAgICAgICAgPC9kaXY+CiAgICAgIDwvYmxvY2txdW90ZT4K ICAgICAgPGJsb2NrcXVvdGU+CiAgICAgICAgPGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+CiAgICAgICAgICA8c3Bhbj5y dGN3ZWIgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4KICAgICAgICAgIDxzcGFuPjxhIHRhYmluZGV4 PSItMSIgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjwv c3Bhbj48YnI+CiAgICAgICAgICA8c3Bhbj48YSB0YWJpbmRleD0iLTEiIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48L3NwYW4+PGJyPgogICAgICAgIDwvZGl2Pgog ICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgIDxicj4KICAgICAgPGZpZWxkc2V0IGNsYXNzPSIgbWlt ZUF0dGFjaG1lbnRIZWFkZXIiPjwvZmllbGRzZXQ+CiAgICAgIDxicj4KICAgICAgPHByZT5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpydGN3ZWIgbWFpbGlu ZyBsaXN0CjxhIHRhYmluZGV4PSItMSIgY2xhc3M9IiBtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQi IGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4KPGEgdGFi aW5kZXg9Ii0xIiBjbGFzcz0iIG1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPgo8L3ByZT4KICAgIDwvYmxvY2txdW90ZT4KICAg IDxicj4KICAKCjwvZGl2PjwvYm9keT48L2h0bWw+ --_9DCFE9D3-B59E-4F03-8D42-E8F8A1A49D16_-- From gunnar.hellstrom@omnitor.se Sun Dec 23 00:37:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502C021F85CC for ; Sun, 23 Dec 2012 00:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=-0.518, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0Mzh4X83rJH for ; Sun, 23 Dec 2012 00:37:40 -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 673A121F85C6 for ; Sun, 23 Dec 2012 00:37:38 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Sun, 23 Dec 2012 09:37:28 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id 8CDE23A121; Sun, 23 Dec 2012 09:37:28 +0100 (CET) Message-ID: <50D6C2C9.80004@omnitor.se> Date: Sun, 23 Dec 2012 09:37:29 +0100 From: =?UTF-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; 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="------------040406010708000206030509" 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, 23 Dec 2012 08:37:41 -0000 This is a multi-part message in MIME format. --------------040406010708000206030509 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Here is the current US regulation draft: http://www.access-board.gov/sec508/refresh/draft-rule.htm#_Toc310327586 Look at point 408.5. The European draft is here: http://www.mandate376.eu/doc/EN301549v008.zip The wide-band codec is mentioned in point 6.2. It is a bit weak, but still points at G.722 with should. Both drafts allow other codecs to be used by endpoints, as long as G722 interoperability is provided, e.g. by transcoding. *I looked back to Magnus' original question for voting, **I think in consequence with the information I provided, I vote for alternative 1).** * And, excuse me for again clobbering the voting thread with discussion. We should keep discussions in other threads to make it easier to count votes. Gunnar On 2012-12-23 08:49, Bernard Aboba wrote: > I would agree. G.722 is widely implemented and there are no IPR > issues. So making it a SHOULD seems compelling. > *From:* Gunnar Hellström > *Sent:* ‎December‎ ‎22‎, ‎2012 ‎11‎:‎47‎ ‎PM > *To:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Call for Consensus Regarding Selecting > Recommended Audio Codecs > There is an accessibility side of this as well. > > Wide band audio can make it much easier for persons with hearing > impairments to use voice communication over distance. > Therefore both US and European draft regulation or draft standards for > support of regulation requires wide band audio wherever you have voice > communication. And these drafts point at G.722 as the common codec at > least to assure interoperability with wide-band audio between providers. > These draft regulations aim at public procurement and at marketing of > electronic communication products and services. > > Therefore, it seems logical to include G.722 in a codec recommendation > document. > > Gunnar > > > On 2012-12-22 18:12, Adam Roach wrote: > > Recommendations or *normative* recommendations? > > I think the former is a very good idea. The latter, not so much. > > /a > > On Dec 22, 2012, at 7:17, "Hutton, Andrew" > > wrote: > > I agree with Roman’s comments below. > > So +1 for providing some recommendations on additional audio > codec’s for RTCWEB. > > Andy > > *From:*rtcweb-bounces@ietf.org > > [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Roman Shpount > *Sent:* 21 December 2012 21:43 > *To:* Adam Roach > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Call for Consensus Regarding Selecting > Recommended Audio Codecs > > > On Fri, Dec 21, 2012 at 11:27 AM, Adam Roach > wrote: > > What I think would be beneficial would be a section > documenting codecs in widespread use today, where they're > used, and what is gained by including them in WebRTC > implementations (mostly transcoder-free interop with those > other implementations). Documenting that AMR is used in > 3GPP VoIP networks would allow implementors to make an > educated decision about the benefit of including that > codec. A similar mention that many modern VoIP phones > support G.722 and/or AAC-LD would provide similar guidance. > > In reality very few phones support AAC-LD. > > For me the major concern is support for G.722. There is no > reason not to support it. None. It is free, it is efficient, > and it sounds better then G.711 any day of the week. It was > not made an MTI for political reasons to promote OPUS. I think > it deserves a SHOULD in the standard. > > As far as AMR and AMR-WB are concerned, they should be > implemented if your platform provides it. I, personally, would > never pay a license fee for these codecs, but if implementing > a browser on a cell phone where these codecs are present, I > would make an extra effort to support them. So, these codecs > probably do not deserve a SHOULD, but some guidance to > implementers is probably required. > > _____________ > 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 > > --------------040406010708000206030509 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Here is the current US regulation draft:
http://www.access-board.gov/sec508/refresh/draft-rule.htm#_Toc310327586
Look at point 408.5.

The European draft is here:
http://www.mandate376.eu/doc/EN301549v008.zip
The wide-band codec is mentioned in point 6.2.
It is a bit weak, but still points at G.722 with should.

Both drafts allow other codecs to be used by endpoints, as long as G722 interoperability is provided, e.g. by transcoding.

I looked back to Magnus' original question for voting,  I think in consequence with the information I provided, I vote for alternative 1).

And, excuse me for again clobbering the voting thread with discussion. We should keep discussions in other threads to make it easier to count votes.

Gunnar

On 2012-12-23 08:49, Bernard Aboba wrote:
I would agree.  G.722 is widely implemented and there are no IPR issues. So making it a SHOULD seems compelling.
 
From: Gunnar Hellström
Sent: ‎December‎ ‎22‎, ‎2012 ‎11‎:‎47‎ ‎PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs
 
There is an accessibility side of this as well.

Wide band audio can make it much easier for persons with hearing impairments to use voice communication over distance.
Therefore both US and European draft regulation or draft standards for support of regulation requires wide band audio wherever you have voice communication. And these drafts point at G.722 as the common codec at least to assure interoperability with wide-band audio between providers.
These draft regulations aim at public procurement and at marketing of electronic communication products and services.

Therefore, it seems logical to include G.722 in a codec recommendation document.

Gunnar


On 2012-12-22 18:12, Adam Roach wrote:
Recommendations or *normative* recommendations? 

I think the former is a very good idea. The latter,  not so much. 

/a

On Dec 22, 2012, at 7:17, "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com> wrote:

I agree with Roman’s comments below.

 

So +1 for providing some recommendations on additional audio codec’s for RTCWEB.

 

Andy

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: 21 December 2012 21:43
To: Adam Roach
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

 


On Fri, Dec 21, 2012 at 11:27 AM, Adam Roach <adam@nostrum.com> wrote:

What I think would be beneficial would be a section documenting codecs in widespread use today, where they're used, and what is gained by including them in WebRTC implementations (mostly transcoder-free interop with those other implementations). Documenting that AMR is used in 3GPP VoIP networks would allow implementors to make an educated decision about the benefit of including that codec. A similar mention that many modern VoIP phones support G.722 and/or AAC-LD would provide similar guidance.

 

In reality very few phones support AAC-LD. 

 

For me the major concern is support for G.722. There is no reason not to support it. None. It is free, it is efficient, and it sounds better then G.711 any day of the week. It was not made an MTI for political reasons to promote OPUS. I think it deserves a SHOULD in the standard.

 

As far  as AMR and AMR-WB are concerned, they should be implemented if your platform provides it. I, personally, would never pay a license fee for these codecs, but if implementing a browser on a cell phone where these codecs are present, I would make an extra effort to support them. So, these codecs probably do not deserve a SHOULD, but some guidance to implementers is probably required.

_____________
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


--------------040406010708000206030509-- From fluffy@cisco.com Sun Dec 23 23:35:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C63B21F88B0; Sun, 23 Dec 2012 23:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.666 X-Spam-Level: X-Spam-Status: No, score=-104.666 tagged_above=-999 required=5 tests=[AWL=-5.883, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_BAD_ID=2.837, SARE_RECV_IP_211216=0.978, 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 rL6GDbw1ARRs; Sun, 23 Dec 2012 23:35:46 -0800 (PST) Received: from WIN-CDPOO5N337C (gw.ntelia.co.kr [175.196.232.146]) by ietfa.amsl.com (Postfix) with ESMTP id C9BA421F8846; Sun, 23 Dec 2012 23:35:45 -0800 (PST) Received: from mail pickup service by WIN-CDPOO5N337C with Microsoft SMTPSVC; Mon, 24 Dec 2012 16:34:51 +0900 Content-Transfer-Encoding: 7bit Content-ID: Content-Language: en-US x-sender: fluffy@cisco.com x-receiver: hongkee67@gmail.com Received: from smtpinbound01.entumoffice.com (10.10.0.46) by GW-SMTPIN1.entumoffice.com (10.10.0.225) with Microsoft SMTP Server id 14.2.247.3; Sun, 9 Dec 2012 09:19:53 +0900 Received: from spamgw.bizmeka.com ([211.218.127.39]) by smtpinbound01.entumoffice.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 9 Dec 2012 09:19:53 +0900 Received: from unknown (HELO mail.ietf.org) (64.170.98.30) by 211.218.127.39 with ESMTP; 9 Dec 2012 09:19:48 +0900 X-Original-SENDERIP: 64.170.98.30 X-Original-MAILFROM: mmusic-bounces@ietf.org Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E9321F8AEC; Sat, 8 Dec 2012 16:19:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1355012390; bh=3w3okXt2NXZVGieD3mQpEdGJ9BZ2Ks55OMBNPX74D3w=; 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=wNM7Vo+jTBsdmLGQq9uauVq5IkyXWqwKXsPkRxbzVR4dVJPJbaYoT0XdiXYCb/bHu W8t712obXl/OeJjjS90YZ/JBVNYyz26UgbexuNXiEHRj1MxoE5GcZeg9Vf5hBEoUYC zSipdWPFMowT9o4p7IwaXQj3NWlmzskifsqyZgP4= 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 09BF321F8AEA; Sat, 8 Dec 2012 16:19:49 -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 vNrqKDp+gij5; Sat, 8 Dec 2012 16:19:48 -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 2CCC921F8ADF; Sat, 8 Dec 2012 16:19:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2402; q=dns/txt; s=iport;t=1355012388; x=1356221988; h=from:to:cc:subject:date:message-id:references:in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Nc0Laq5KqESAbVg4cXK4ac8TweDr2vrfHs8pN5/NDdM=; b=ehCulsR7xXhp5FqUFV/2CiC71VFsDpCvMqLADjqg3MG+lhC8UBRVBZvJ48XQX5XToA/TxjS2y9JQEFBP+R1iGEPFAApUGu6X/lVUFx/wBpXrVcW7H3Dws0RKGsPxsnJZ1EAo2OTQP63ugQytFB0xb/Pl+jO9Sp+a1rLR2l8CjK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAN7Yw1CtJV2c/2dsb2JhbABEvmIWc4IeAQEBAwF5EAIBCA4KCiQyJQIEDgUIiAMGvyyMP4NiYQOIKp4kgnOCIg X-IronPort-AV: E=McAfee;i="5400,1158,6920"; a="150877202" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 09 Dec 2012 00:19:46 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76])by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qB90JkUA014590(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Dec 2012 00:19:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.91]) by xhc-rcd-x02.cisco.com([173.37.183.76]) with mapi id 14.02.0318.004; Sat, 8 Dec 2012 18:19:46 -0600 From: "Cullen Jennings (fluffy)" To: "Eric Rescorla" Thread-Topic: [MMUSIC] SDP work needed for WebRTC stuff Thread-Index: AQHN1ZrLc7vRdGyb+kCXOHgISQGSp5gP/yeA Message-ID: <1.28e056a9fdad5dab98cf@cisco.com> References: In-Reply-To: Accept-Language: en-US x-originating-ip: [10.20.249.167] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Sender: Errors-To: mmusic-bounces@ietf.org X-OriginalArrivalTime: 09 Dec 2012 00:19:53.0511 (UTC) FILETIME=[E90F1370:01CDD5A2] X-MS-Exchange-Organization-AuthSource: GW-SMTPIN1.entumoffice.com X-MS-Exchange-Organization-AuthAs: Anonymous MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_5805_C0763F0E.C9AF94FB" Cc: "" , mmusic WG , "" Subject: Re: [rtcweb] [MMUSIC] SDP work needed for WebRTC stuff 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: , Date: Mon, 24 Dec 2012 07:35:47 -0000 X-Original-Date: Sun, 9 Dec 2012 00:19:46 +0000 X-List-Received-Date: Mon, 24 Dec 2012 07:35:47 -0000 ------=_NextPart_000_5805_C0763F0E.C9AF94FB Content-Language: en-US Content-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Dec 8, 2012, at 4:21 PM, Eric Rescorla wrote: > +rtcweb > > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) wrote: > > I was looking over everything that needs to be completed to finish a fist cut of the WebRTC related work. There are a handful of big SDP problems that are currently blocking some of the WebRTC work and I'd like to figure out how to make some progress on them. > > Let me loosely characterize them as > > 1) If we have several video streams, how do theses map up to 1 or more m lines. > > 2) if we are doing port multiplexing, what does the SDP look like (the bundle problem) > > 3) How do we map the RTCWeb track and stream label concepts to identifiers in SDP > > 3) SDP for application running over SCTP/DTLS > > I don't want to speak for all the various chairs but I am under the impression that most of chairs of related groups in W3C and IETF believe these are issues that need to be resolved primarily in the MMUSIC WG and that they impact both WebRTC and CLUE as well as the general long term use of SDP in SIP and other protocols. > > I'd like to get some discussion going on how we can make some progress on these. I don't think we are going to solve these in 20 minutes of discussion at an IETF meeting so I think we probably need some interim (virtual or face to face) to sort this out. > > Thoughts? > > Wow, I'm totally confused here. > > I had assumed that the SDP-related issues were going to be the main > topics at the WebRTC/RTCWEB interim in January. Is that not the case? So far the interim was only talking about being a WebRTC & RTCWeb so this SDP stuff would be out of scope. Perhaps it would be better to have some of the time for mmusic topics? > > IMO the lack of clarity around how to encode various media > configurations into SDP is the major thing blocking progress here. In > particular, Firefox has opted not to implement multiplexing of media > streams over the same transport flow (whether of the bundle or > multiple m-line variety) until the SDP for it is well-defined. The > same thing applies to the question of how to map multiple m-lines to > incoming MediaStreams/Tracks. > > We really need to cover these issues in the interim. > > -Ekr > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic ------=_NextPart_000_5805_C0763F0E.C9AF94FB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On Dec 8, 2012, at 4:21 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> +rtcweb
>
> On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) <fluffy@ci= sco.com> wrote:
>
> I was looking over everything that needs to be completed to finish a f= ist cut of the WebRTC related work. There are a handful of big SDP problems= that are currently blocking some of the WebRTC work and I'd like to figure= out how to make some progress on them.
>
> Let me loosely characterize them as
>
> 1) If we have several video streams, how do theses map up to 1 or more= m lines.
>
> 2) if we are doing port multiplexing, what does the SDP look like (the= bundle problem)
>
> 3) How do we map the RTCWeb track and stream label concepts to identif= iers in SDP
>
> 3) SDP for application running over SCTP/DTLS
>
> I don't want to speak for all the various chairs but I am under the im= pression that most of chairs of related groups in W3C and IETF believe thes= e are issues that need to be resolved primarily in the MMUSIC WG and that t= hey impact both WebRTC and CLUE as well as the general long term use of SDP= in SIP and other protocols.
>
> I'd like to get some discussion going on how we can make some progress= on these. I don't think we are going to solve these in 20 minutes of discu= ssion at an IETF meeting so I think we probably need some interim (virtual = or face to face) to sort this out.
>
> Thoughts?
>
> Wow, I'm totally confused here.
>
> I had assumed that the SDP-related issues were going to be the main
> topics at the WebRTC/RTCWEB interim in January. Is that not the case?

So far the interim was only talking about being a WebRTC & RTCWeb so th= is SDP stuff would be out of scope. Perhaps it would be better to have some= of the time for mmusic topics?


>
> IMO the lack of clarity around how to encode various media
> configurations into SDP is the major thing blocking progress here. In
> particular, Firefox has opted not to implement multiplexing of media
> streams over the same transport flow (whether of the bundle or
> multiple m-line variety) until the SDP for it is well-defined. The
> same thing applies to the question of how to map multiple m-lines to
> incoming MediaStreams/Tracks.
>
> We really need to cover these issues in the interim.
>
> -Ekr
>
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
------=_NextPart_000_5805_C0763F0E.C9AF94FB-- From tim@phonefromhere.com Mon Dec 24 02:26:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B645D21F884F for ; Mon, 24 Dec 2012 02:26:01 -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 k3FUZYiOpELB for ; Mon, 24 Dec 2012 02:26:01 -0800 (PST) Received: from smtp003.apm-internet.net (smtp003.apm-internet.net [85.119.248.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1988D21F8809 for ; Mon, 24 Dec 2012 02:25:56 -0800 (PST) Received: (qmail 13941 invoked from network); 24 Dec 2012 10:25:55 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp003.apm-internet.net with SMTP; 24 Dec 2012 10:25:55 -0000 Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id F3DA818A0AEE for ; Mon, 24 Dec 2012 10:25:54 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Tim Panton In-Reply-To: <50D6C2C9.80004@omnitor.se> Date: Mon, 24 Dec 2012 10:25:46 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <8A68C6DA-B603-4450-A4B8-A72E99996AA5@phonefromhere.com> References: <50D6C2C9.80004@omnitor.se> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1283) 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, 24 Dec 2012 10:26:01 -0000 Looks like I'll be a lone voice again. I'm against any recommendation of use of g722 in webRTC=20 If implementers want to provide it that's fine but it should not be in = the standard. Even if it is available it always be at a lower preference than Opus g722 has several disadvantages over Opus and no real advantages. 1) The spec for g722 contains a historical error, so it's sample rate = gets=20 declared as 8khz even though it is actually 16khz - this means that the = rtp/audio processing code is littered with if( codec =3D=3D CODEC_G722) {} else {} clauses to try and = implement this mistake. I've seen g722 mis-implemented more often than any other codec. 2) g722 is a fixed rate codec - it uses 64kbits/sec irrespective of what = is available - it won't play nice with any congestion management that is specified with webRTC 3) g722 sounds ok (despite using 14 or the available 16 bits) - provided there is no packet loss - it has no built in FEC or PLC = modes, so falls apart=20 at quite low loss levels (especially compared to opus). 4) if we mandate g722 then we need to make some methods in the = constraints API to ensure that 2 browser endpoints that say they want wideband don't get g722 when = they could both be doing opus in full CELT mode for the same bandwidth. The often stated advantage is that there are many existing g722 = endpoints out there. This is irrelevant - there is only 1 platform I know of that implements = ICE+DTLS-SRTP and g722 but not opus=20 (asterisk for the curious and there's an opus patch available).=20 =20 Tim.= From tim@phonefromhere.com Mon Dec 24 02:28:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9DC21F8860 for ; Mon, 24 Dec 2012 02:28:34 -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 bly6VCDsbn3h for ; Mon, 24 Dec 2012 02:28: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 CC68C21F884F for ; Mon, 24 Dec 2012 02:28:33 -0800 (PST) Received: (qmail 15087 invoked from network); 24 Dec 2012 10:28:33 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp003.apm-internet.net with SMTP; 24 Dec 2012 10:28:33 -0000 Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id E2B9B18A0AEE; Mon, 24 Dec 2012 10:28:32 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: <50D2CC6A.4090500@ericsson.com> Date: Mon, 24 Dec 2012 10:28:32 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50D2CC6A.4090500@ericsson.com> To: Magnus Westerlund 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, 24 Dec 2012 10:28:35 -0000 I vote 2 - we have enough codec wars without opening another front - for = absolutely zero user benefit. =20 On 20 Dec 2012, at 08:29, Magnus Westerlund wrote: > 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 From roman@telurix.com Mon Dec 24 02:52:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9F721F87E0 for ; Mon, 24 Dec 2012 02:52:42 -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 JzPunfS0hkXf for ; Mon, 24 Dec 2012 02:52:41 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 08FDC21F87DF for ; Mon, 24 Dec 2012 02:52:40 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id hn14so6347414wib.16 for ; Mon, 24 Dec 2012 02:52:40 -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=uMYVTHtY+tFUlHdlFdaLTdZfHWjCvuqmpLgePOs7Os8=; b=CbQcaKc2IUslZgjF6vWAZgf4lUA/JlQhahaYA1fQqziVwZYMnozOArMTM82tLhfDu7 DW0xlwP7ODs8+jOoiCFGM7EehPHh1VgiTPQ3WDqQDPLkRZA6YqZuJcEK+IV4bsT+q+DT g0PjAO8GSZRzXv37IVQFp9AjxbTR1hQ/NdaPiD06xPKmUngvp6E95xsEu0KZf1B/G9e9 oezwRzEiiBH9K9GbLJlAdqlNQ6eZgHPJNTfxngvzwS6dl1MPKq0gcc2yIaceq+nanvIZ euJX4y9anBam7QkxUn+3OmVeKwSgVDDxdmJLRqt6ibOzxFC72/+KqidciQkAtMxcyD9+ yvjg== X-Received: by 10.180.78.226 with SMTP id e2mr32099437wix.1.1356346359958; Mon, 24 Dec 2012 02:52:39 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by mx.google.com with ESMTPS id hu8sm20482165wib.6.2012.12.24.02.52.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Dec 2012 02:52:38 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so3248743wey.31 for ; Mon, 24 Dec 2012 02:52:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.78.207 with SMTP id d15mr34893925wjx.52.1356346357227; Mon, 24 Dec 2012 02:52:37 -0800 (PST) Received: by 10.216.16.134 with HTTP; Mon, 24 Dec 2012 02:52:36 -0800 (PST) In-Reply-To: <8A68C6DA-B603-4450-A4B8-A72E99996AA5@phonefromhere.com> References: <50D6C2C9.80004@omnitor.se> <8A68C6DA-B603-4450-A4B8-A72E99996AA5@phonefromhere.com> Date: Mon, 24 Dec 2012 05:52:36 -0500 Message-ID: From: Roman Shpount To: Tim Panton Content-Type: multipart/alternative; boundary=047d7bfcf91ad0a00704d196fed6 X-Gm-Message-State: ALoCoQmRhzt5YOSZ9ZwhpIBFFoVW2Zw2GT36xh5oaoHBz8ks6z8A55+Hy6noVUGQ6JHIxQR3j7+z 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, 24 Dec 2012 10:52:42 -0000 --047d7bfcf91ad0a00704d196fed6 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 24, 2012 at 5:25 AM, Tim Panton wrote: > Looks like I'll be a lone voice again. > And I thought I was the lonely voice of reason saying exactly the opposite. > I'm against any recommendation of use of g722 in webRTC > If implementers want to provide it that's fine but it should not be in the > standard. > Even if it is available it always be at a lower preference than Opus > I agree it should be lower preference by default, but the application developer can change this if needed. > 1) The spec for g722 contains a historical error, so it's sample rate gets declared as 8khz even though it is actually 16khz - this means that the > rtp/audio processing code is littered with if( codec == CODEC_G722) {} else > {} clauses to try and implement this mistake. I've seen g722 > mis-implemented more often than any other codec. > I've seen more G722 implementations then of any other wide band codec. In fact this is the most commonly implemented and used wideband codec right now, may be with an exception of SILK. > 2) g722 is a fixed rate codec - it uses 64kbits/sec irrespective of what > is available - it won't play nice with any congestion management that is > specified with webRTC > So does G.711, but it still supported for interop reasons. In most cases 64kbps is little enough not to worry about it. > 3) g722 sounds ok (despite using 14 or the available 16 bits) > - provided there is no packet loss - it has no built in FEC or PLC modes, > so falls apart at quite low loss levels (especially compared to opus). > That is simply not true. PLC for G.722 is defined in Appendixes III and IV. It is not as good as OPUS but it is acceptable. > 4) if we mandate g722 then we need to make some methods in the > constraints API to ensure that 2 browser endpoints that say they want > wideband don't get g722 when they could both be doing opus in full CELT > mode for the same bandwidth. > This should be up to the application developers, not a standard comity. By default OPUS should have higher preference. > The often stated advantage is that there are many existing g722 endpoints > out there. This is irrelevant - there is only 1 platform I know of that > implements ICE+DTLS-SRTP and g722 but not opus (asterisk for the curious > and there's an opus patch available). > It is not irrelevant. If SRTP is supported there are a lot of end points that support ICE+SRTP+G.722. P.S. A saner, more conservative approach would have been to make G.722 a MUST and OPUS a SHOULD. Unfortunately, this ship has sailed together with such things like support of plain RTP, due to worrying about political appearences first and stable product later. --047d7bfcf91ad0a00704d196fed6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 24, 2012 at 5:25 AM, Tim Panton <tim@phonefromhere.co= m> wrote:
=A0
Looks like I'll be a lone voice again.

<= div>And I thought I was the lonely voice of reason saying exactly the oppos= ite.=A0
=A0
I'm against any recommendation of use of g722 in webRTC
If implementers want to provide it that's fine but it should not be in = the standard.
Even if it is available it always be at a lower preference than Opus

I agree it should be lower preference by defa= ult, but the application developer can change this if needed.
=A0
1) The spec for g722 contains a his= torical error, so it's sample rate gets
declared as 8khz even though it is actually 16khz - this means that the rtp= /audio processing code is=A0littered with if( codec =3D=3D CODEC_G722) {} e= lse {} clauses to try and implement this mistake.=A0I've seen g722 mis-= implemented more often than any other codec.

I've seen more G722 implementations th= en of any other wide band codec. In fact this is the most commonly implemen= ted and used wideband codec right now, may be with an exception of SILK.=A0=
=A0
2) g722 is a fixed rate codec - it uses 64kbits/sec irrespective of what is= available - it won't play nice with any=A0congestion management that i= s specified with webRTC

So does G.711, = but it still supported for interop reasons. In most cases 64kbps is little = enough not to worry about it.
=A0
3) g722 sounds ok =A0(despite = using 14 or the available 16 bits)
- provided there is no packet loss - it has no built in FEC or PLC modes, s= o falls apart=A0at quite low loss levels (especially compared to opus).
=

That is simply not true. PLC for G.722 is = defined in Appendixes III and IV. It is not as good as OPUS but it is accep= table.=A0
=A0
4) if we mandate g722 then we need to make some =A0methods =A0in the constr= aints API to ensure=A0that 2 browser endpoints that say they want wideband = don't get g722 when they could both be doing opus in=A0full CELT mode f= or the same bandwidth.

This should be up to the application devel= opers, not a standard comity. =A0By default OPUS should have higher prefere= nce.
=A0
The often stated advantage is that there are many existing g722 endpoints o= ut there. This is=A0irrelevant - there is only 1 platform I know of that im= plements ICE+DTLS-SRTP and g722 but not opus=A0(asterisk for the curious an= d there's an opus patch available).
=A0
It is not irrelevant. If SRTP is supported = there are a lot of end points that support ICE+SRTP+G.722.

P.S. A saner, more conservative approach would have been to make G= .722 a MUST and OPUS a SHOULD. Unfortunately, this ship has sailed together= with such things like support of plain RTP, due to worrying about politica= l appearences first and stable product later.
--047d7bfcf91ad0a00704d196fed6-- From tim@phonefromhere.com Mon Dec 24 03:29:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800A621F85AC for ; Mon, 24 Dec 2012 03:29:00 -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.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 WzYtUQxESdD6 for ; Mon, 24 Dec 2012 03:28:57 -0800 (PST) Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by ietfa.amsl.com (Postfix) with ESMTP id B17F821F8555 for ; Mon, 24 Dec 2012 03:28:56 -0800 (PST) Received: (qmail 57312 invoked from network); 24 Dec 2012 11:28:54 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp004.apm-internet.net with SMTP; 24 Dec 2012 11:28:54 -0000 Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 753A418A0996; Mon, 24 Dec 2012 11:28:54 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_2B55E4F4-7282-4C74-B1F8-364442A00130" From: Tim Panton In-Reply-To: Date: Mon, 24 Dec 2012 11:28:54 +0000 Message-Id: References: <50D6C2C9.80004@omnitor.se> <8A68C6DA-B603-4450-A4B8-A72E99996AA5@phonefromhere.com> To: Roman Shpount 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, 24 Dec 2012 11:29:00 -0000 --Apple-Mail=_2B55E4F4-7282-4C74-B1F8-364442A00130 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 24 Dec 2012, at 10:52, Roman Shpount wrote: > On Mon, Dec 24, 2012 at 5:25 AM, Tim Panton = wrote: > =20 > Looks like I'll be a lone voice again. >=20 > And I thought I was the lonely voice of reason saying exactly the = opposite.=20 Perhaps ;-) > =20 > I'm against any recommendation of use of g722 in webRTC > If implementers want to provide it that's fine but it should not be in = the standard. > Even if it is available it always be at a lower preference than Opus >=20 > I agree it should be lower preference by default, but the application = developer can change this if needed. How? by dipping into the SDP or with an API ? - see my point 4)=20 > =20 > 1) The spec for g722 contains a historical error, so it's sample rate = gets > declared as 8khz even though it is actually 16khz - this means that = the rtp/audio processing code is littered with if( codec =3D=3D = CODEC_G722) {} else {} clauses to try and implement this mistake. I've = seen g722 mis-implemented more often than any other codec. >=20 > I've seen more G722 implementations then of any other wide band codec. = In fact this is the most commonly implemented and used wideband codec = right now, may be with an exception of SILK.=20 And almost every one of them got this wrong the first time, and then had = a regression 6 months later. Lets admit it - it's a mess. > =20 > 2) g722 is a fixed rate codec - it uses 64kbits/sec irrespective of = what is available - it won't play nice with any congestion management = that is specified with webRTC >=20 > So does G.711, but it still supported for interop reasons. In most = cases 64kbps is little enough not to worry about it. Ah. now there we disagree. We can run opus over lossy Edge but not g722 = - many people's only internet connection is Edge at best. On the other side if I'm on a 50Mbps fibre I'll still only get 64kb/s = 722 quality even though I could have been in CELT stereo. Non adaptable = codecs aren't fit for the modern internet (IMHO). (- I also voted against 711 = being mandatory for exactly that reason). > =20 > 3) g722 sounds ok (despite using 14 or the available 16 bits) > - provided there is no packet loss - it has no built in FEC or PLC = modes, so falls apart at quite low loss levels (especially compared to = opus). >=20 > That is simply not true. PLC for G.722 is defined in Appendixes III = and IV. It is not as good as OPUS but it is acceptable.=20 I sorry, I forgot that - do all those legacy endpoints actually = implement that? > =20 > 4) if we mandate g722 then we need to make some methods in the = constraints API to ensure that 2 browser endpoints that say they want = wideband don't get g722 when they could both be doing opus in full CELT = mode for the same bandwidth. >=20 > This should be up to the application developers, not a standard = comity. By default OPUS should have higher preference. Agreed. I'm not saying implementors cant add it. I just say the standard = shouldn't even recommend something that isn't even close to the best we = can do. > =20 > The often stated advantage is that there are many existing g722 = endpoints out there. This is irrelevant - there is only 1 platform I = know of that implements ICE+DTLS-SRTP and g722 but not opus (asterisk = for the curious and there's an opus patch available). > =20 > It is not irrelevant. If SRTP is supported there are a lot of end = points that support ICE+SRTP+G.722. Interesting - I can't think of many full ICE clients that do SRTP and = g722 and not opus - Jitsi perhaps - but that couldn't swallow chrome's = SDP last=20 I tried. My experience with legacy interop is that you _always_ need a = gateway. If the consensus is to make (non-dtls) SRTP support mandatory I might = change my mind I suppose. >=20 > P.S. A saner, more conservative approach would have been to make G.722 = a MUST and OPUS a SHOULD. Unfortunately, this ship has sailed together = with such things like support of plain RTP, due to worrying about = political appearences first and stable product later. I can't agree that the reasons were about political appearance. Speaking = purely for myself they were about security and quality.=20 Phonefromhere was a start-up that built webrtc-like functionality into = browsers (using a java applet). So we have quite a bit of experience of what worked and what didn't - my views are shaped by that experience and = that of running a security startup westpoint.ltd.uk . =20 What works for the deskphone on a managed secure LAN does not = necessarily work for someone in a cafe in India on the wi[l]der = internet. T.= --Apple-Mail=_2B55E4F4-7282-4C74-B1F8-364442A00130 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On 24 Dec 2012, at 10:52, Roman Shpount wrote:

On Mon, Dec 24, 2012 at 5:25 AM, Tim Panton <tim@phonefromhere.com> wrote:
 
Looks like I'll be a lone voice again.

And I thought I was the lonely voice of reason saying exactly the opposite. 

Perhaps ;-)

 
I'm against any recommendation of use of g722 in webRTC
If implementers want to provide it that's fine but it should not be in the standard.
Even if it is available it always be at a lower preference than Opus

I agree it should be lower preference by default, but the application developer can change this if needed.

How? by dipping into the SDP or with an API ? - see my point 4) 

 
1) The spec for g722 contains a historical error, so it's sample rate gets
declared as 8khz even though it is actually 16khz - this means that the rtp/audio processing code is littered with if( codec == CODEC_G722) {} else {} clauses to try and implement this mistake. I've seen g722 mis-implemented more often than any other codec.

I've seen more G722 implementations then of any other wide band codec. In fact this is the most commonly implemented and used wideband codec right now, may be with an exception of SILK. 

And almost every one of them got this wrong the first time, and then had a regression 6 months later. Lets admit it - it's a mess.

 
2) g722 is a fixed rate codec - it uses 64kbits/sec irrespective of what is available - it won't play nice with any congestion management that is specified with webRTC

So does G.711, but it still supported for interop reasons. In most cases 64kbps is little enough not to worry about it.

Ah. now there we disagree. We can run opus over lossy Edge but not g722 - many people's only internet connection is Edge at best.
On the other side if I'm on a 50Mbps fibre I'll still only get 64kb/s 722 quality even though I could have been in CELT stereo. Non adaptable codecs
aren't fit for the modern internet (IMHO). (- I also voted against 711 being mandatory for exactly that reason).

 
3) g722 sounds ok  (despite using 14 or the available 16 bits)
- provided there is no packet loss - it has no built in FEC or PLC modes, so falls apart at quite low loss levels (especially compared to opus).

That is simply not true. PLC for G.722 is defined in Appendixes III and IV. It is not as good as OPUS but it is acceptable. 

I sorry, I forgot that - do all those legacy endpoints actually implement that?

 
4) if we mandate g722 then we need to make some  methods  in the constraints API to ensure that 2 browser endpoints that say they want wideband don't get g722 when they could both be doing opus in full CELT mode for the same bandwidth.

This should be up to the application developers, not a standard comity.  By default OPUS should have higher preference.

Agreed. I'm not saying implementors cant add it. I just say the standard shouldn't even recommend something that isn't even close to the best we can do.

 
The often stated advantage is that there are many existing g722 endpoints out there. This is irrelevant - there is only 1 platform I know of that implements ICE+DTLS-SRTP and g722 but not opus (asterisk for the curious and there's an opus patch available).
 
It is not irrelevant. If SRTP is supported there are a lot of end points that support ICE+SRTP+G.722.

Interesting - I can't think of many full ICE clients that do SRTP and g722 and not opus - Jitsi perhaps - but that couldn't swallow chrome's SDP last 
I tried. My experience with legacy interop is that you _always_ need a gateway.

If the consensus is to make (non-dtls) SRTP support mandatory I might change my mind I suppose.



P.S. A saner, more conservative approach would have been to make G.722 a MUST and OPUS a SHOULD. Unfortunately, this ship has sailed together with such things like support of plain RTP, due to worrying about political appearences first and stable product later.

I can't agree that the reasons were about political appearance. Speaking purely for myself they were about security and quality. 
Phonefromhere was a start-up that built webrtc-like functionality into browsers (using a java applet). So we have quite a bit of experience of
what worked and what didn't - my views are shaped by that experience and that of running a security startup westpoint.ltd.uk .  

What works for the deskphone on a managed secure LAN does not necessarily work for someone in a cafe in India on the wi[l]der internet.

T.
--Apple-Mail=_2B55E4F4-7282-4C74-B1F8-364442A00130-- From adam@nostrum.com Mon Dec 24 07:44:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50B721F8673 for ; Mon, 24 Dec 2012 07:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.204 X-Spam-Level: X-Spam-Status: No, score=-101.204 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 oRv9i4BPnzKj for ; Mon, 24 Dec 2012 07:44:13 -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 3EA1121F85E0 for ; Mon, 24 Dec 2012 07:44:13 -0800 (PST) Received: from [10.25.25.24] (c-75-65-254-104.hsd1.la.comcast.net [75.65.254.104]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qBOFi3RI062012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Dec 2012 09:44:10 -0600 (CST) (envelope-from adam@nostrum.com) References: <50D6C2C9.80004@omnitor.se> <8A68C6DA-B603-4450-A4B8-A72E99996AA5@phonefromhere.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6C10C9B4-1524-4DA8-9B08-FE82F798BC03@nostrum.com> X-Mailer: iPad Mail (10A403) From: Adam Roach Date: Mon, 24 Dec 2012 09:46:34 -0600 To: Tim Panton Received-SPF: pass (nostrum.com: 75.65.254.104 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: Mon, 24 Dec 2012 15:44:14 -0000 On Dec 24, 2012, at 5:28, Tim Panton wrote: > Interesting - I can't think of many full ICE clients that do SRTP and g722= and not opus - Jitsi perhaps - but that couldn't swallow chrome's SDP last=20= > I tried. My experience with legacy interop is that you _always_ need a gat= eway. Well, there's a huge difference in both quality and latency between de-encap= sulation and transcoding. I think there are good reasons for implementations= to support G.722 -- I just think specifying its use at RFC 2119 SHOULD leve= l is beyond the spirit of what RFC 2119 intends.=20 /a=20= From emil@sip-communicator.org Mon Dec 24 09:00:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD79121F88B0 for ; Mon, 24 Dec 2012 09:00:26 -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 ayH2663+4MBl for ; Mon, 24 Dec 2012 09:00:25 -0800 (PST) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) by ietfa.amsl.com (Postfix) with ESMTP id C808A21F88A3 for ; Mon, 24 Dec 2012 09:00:24 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id r5so3316518wey.7 for ; Mon, 24 Dec 2012 09:00:23 -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=mLVaQwlt2REr0U2i2nZRC11e3fTgjONEAusr5N6R0vo=; b=AWGjeyW5Vxj5WaxTnVU37s0kfgGYImkaScfBLDipaM5fGkKNhkbpZRnuzEwqnJYtsw XzGBZx7h2yEO4Gat5j6kvL/37Sm1zxj+BOqbghsV0vTV2sxSW65omEjG84VHycP5Q+Ka f+cRXfRem0Zj35TJadddePUlPWK4vXoFruuZ8t3R1qQE/Z3FaTncSuo8UVPzng93M0+l gPfJtosIUM7/pEWad7cdVaO9BaiU6GTKdEuLO8opRlo8OUVh27B3nOQsqyEZHCBnZb6y B2XJRcFEU24AHr8wW90U67J7tdMC5zQP61SEAIiv58X8AsFsxQq4CXCKcCFptR73b/OR DcrA== X-Received: by 10.180.106.34 with SMTP id gr2mr35248564wib.18.1356368423400; Mon, 24 Dec 2012 09:00:23 -0800 (PST) Received: from camionet.local ([2a01:e35:8a55:abc0:e1b5:f39a:3adc:bac0]) by mx.google.com with ESMTPS id bz12sm34077629wib.5.2012.12.24.09.00.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Dec 2012 09:00:22 -0800 (PST) Message-ID: <50D88A23.9020108@jitsi.org> Date: Mon, 24 Dec 2012 18:00:19 +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: Tim Panton References: <50D6C2C9.80004@omnitor.se> <8A68C6DA-B603-4450-A4B8-A72E99996AA5@phonefromhere.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlqcB87YxmaP2iKgiksb574qahbTDJz40tWesuLbYagZ/7K6FxV+mpmbXq2zQBTD1WzvtLv 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, 24 Dec 2012 17:00:27 -0000 On 24.12.12, 12:28, Tim Panton wrote: > Interesting - I can't think of many full ICE clients that do SRTP and > g722 and not opus - Jitsi perhaps - but that couldn't swallow chrome's > SDP last I tried. FWIW, it's on our roadmap but we probably won't start implementing it before MMUSIC is done solving the bundle (or alternative) issue and ready with an official version. Cheers, Emil -- https://jitsi.org From eburger@cs.georgetown.edu Tue Dec 25 04:24:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F9121F862D for ; Tue, 25 Dec 2012 04:24:09 -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 8Xe4MEE1+7hS for ; Tue, 25 Dec 2012 04:24:05 -0800 (PST) Received: from karma.cs.georgetown.edu (karma.cs.georgetown.edu [141.161.20.3]) by ietfa.amsl.com (Postfix) with ESMTP id 2861221F8460 for ; Tue, 25 Dec 2012 04:24:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by karma.cs.georgetown.edu (Postfix) with ESMTP id 30F1142733 for ; Tue, 25 Dec 2012 07:24:04 -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 C8PQqdOgu3aB for ; Tue, 25 Dec 2012 07:24:02 -0500 (EST) Received: from [192.168.0.191] (cpe-74-76-86-197.nycap.res.rr.com [74.76.86.197]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by karma.cs.georgetown.edu (Postfix) with ESMTP id 5252740F43 for ; Tue, 25 Dec 2012 07:24:02 -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: <50D2CC6A.4090500@ericsson.com> Date: Tue, 25 Dec 2012 07:24:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3AF3BBD3-6C3A-4FF0-AF72-EBB9DBF4C1E0@cs.georgetown.edu> References: <50D2CC6A.4090500@ericsson.com> To: rtcweb@ietf.org 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: Tue, 25 Dec 2012 12:24:09 -0000 I vote 2. Discussion in a separate thread. On Dec 20, 2012, at 3:29 AM, Magnus Westerlund = wrote: > 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 From eburger-l@standardstrack.com Tue Dec 25 04:29:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1834321F86F0 for ; Tue, 25 Dec 2012 04:29:56 -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 j7+mtvlVV51l for ; Tue, 25 Dec 2012 04:29:52 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0F81D21F86CB for ; Tue, 25 Dec 2012 04:29:52 -0800 (PST) Received: from cpe-74-76-86-197.nycap.res.rr.com ([74.76.86.197]:50431 helo=[192.168.0.191]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TnTdn-0004oc-2d for rtcweb@ietf.org; Tue, 25 Dec 2012 04:29:51 -0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric Burger In-Reply-To: <50D48DD8.3050702@nostrum.com> Date: Tue, 25 Dec 2012 07:29:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5BEDD27D-B359-4CD4-B01C-427E6BB1372A@standardstrack.com> References: <50D2CC6A.4090500@ericsson.com> <50D3E3BF.7070609@mozilla.com> <50D48DD8.3050702@nostrum.com> To: rtcweb@ietf.org 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: 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, 25 Dec 2012 12:29:56 -0000 Adam has got it in one. Listen to the arguments: "We want interop with 3G. No, we want interop = with SIP/PSTN. No, we want interop with SIP/WB. No, we want interop with = NGN. No, we want interop with Skype. No, we want interop with=85." Each of these networks seem to have their own preferred codec. Most of = the arguments on the list are of the form, "I want my favorite codec for = my favorite network as a SHOULD or as a RECOMMENDED." The major gastrointestinal objection I have here is every week we argue, = someone will come up with "we want to interop with Future Tech 1." What I would offer as a way forward is to mandate G.711, because we = could not agree to mandate opus, and mandate NOTHING ELSE. We then either have a nice big section in this present document = describing the current state of the art of various networks with various = codecs *OR* we have an Informational Implementor's Guide that describes = the current state of the art of various networks, as well as the = pitfalls of popular but hard codecs, like G.722. On Dec 21, 2012, at 11:27 AM, Adam Roach wrote: > On 12/20/12 22:21, Timothy B. Terriberry wrote: >> Markus.Isomaki@nokia.com wrote: >>> My proposal would be to recommend AMR, and perhaps AMR-WB. The = rationale is >>=20 >> I don't think we should list a set of RECOMMENDED codecs. If we were = talking just G.722, iLBC, etc., I might be persuaded. But this is a 2119 = RECOMMENDED, which is a bit stronger than "Gee, it would be nice," and = given the aforementioned IPR situation, Mozilla is not likely to be = deploying any of the AMR family anytime soon. >>=20 >> If the goal is interoperability with deployed systems, you're going = to implement what you need to implement to achieve that, and nothing we = write down in an RFC will change what that needs to be. >=20 > I'm going to have to agree with Tim -- very little would be served by = having normative SHOULD-strength requirements here. >=20 > What I think would be beneficial would be a section documenting codecs = in widespread use today, where they're used, and what is gained by = including them in WebRTC implementations (mostly transcoder-free interop = with those other implementations). Documenting that AMR is used in 3GPP = VoIP networks would allow implementors to make an educated decision = about the benefit of including that codec. A similar mention that many = modern VoIP phones support G.722 and/or AAC-LD would provide similar = guidance. >=20 > But I don't think there's much to be gained by readying the scarlet = letter of "conditionally compliant" that would result from a = SHOULD-strength normative statement about royalty-bearing codecs. >=20 > /a > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Wed Dec 26 09:18:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66C721F8CCA for ; Wed, 26 Dec 2012 09:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.103 X-Spam-Level: X-Spam-Status: No, score=-109.103 tagged_above=-999 required=5 tests=[AWL=1.496, 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 NJD6sCUkfDVv for ; Wed, 26 Dec 2012 09:18:06 -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 43C0921F8C78 for ; Wed, 26 Dec 2012 09:18:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=777; q=dns/txt; s=iport; t=1356542286; x=1357751886; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dzirntYhAmcfoz+LK92oslJr6tTuGyBIjP5vr1zuIlM=; b=jHJgfvS8aLrvWeAUWye3ypqfFV9OBaKFxtJAOJLPRIooydJ+ePd/7Hb7 UyTWsi3kf2n7vV7c40gJazCPVC6bXLJW6yeCJsoyVWEgOtLdV3D57F6Rb hIx/Ut6ovIFaIyyyAhPQlTzNWff6c22EOUqWNTSlbkklTILyNWAeZ69vj Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGUv21CtJXG+/2dsb2JhbABFhXO3dBZzgh4BAQEDAQEBARpcEAIBCA4UJDIlAgMBDgUIiAUGtgGMV4NiYQOmVIJ0giI X-IronPort-AV: E=Sophos;i="4.84,357,1355097600"; d="scan'208";a="156628200" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 26 Dec 2012 17:18:05 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBQHI5tB018659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Dec 2012 17:18:05 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 26 Dec 2012 11:18:05 -0600 From: "Cullen Jennings (fluffy)" To: Eric Burger Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN44z3l1dXGju5Z0WcFFYee41Pfg== Date: Wed, 26 Dec 2012 17:18:04 +0000 Message-ID: References: <50D2CC6A.4090500@ericsson.com> <50D3E3BF.7070609@mozilla.com> <50D48DD8.3050702@nostrum.com> <5BEDD27D-B359-4CD4-B01C-427E6BB1372A@standardstrack.com> In-Reply-To: <5BEDD27D-B359-4CD4-B01C-427E6BB1372A@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1613AE69A4275D40B3BC96785122F072@cisco.com> 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: Wed, 26 Dec 2012 17:18:07 -0000 On Dec 25, 2012, at 5:29 AM, Eric Burger wro= te: >=20 > We then either have a nice big section in this present document describin= g the current state of the art of various networks with various codecs *OR*= we have an Informational Implementor's Guide that describes the current st= ate of the art of various networks, as well as the pitfalls of popular but = hard codecs, like G.722. Would someone be willing to summarize a list of codecs that at some people = have argued strongly in favor of along with the main advantage of thawing t= hat codec. I'm thinking of a list that looks something like AMR-WB Gets you interop with existing 3GPP=20 Having a list like this would be a handy quick references to discussion. From fluffy@cisco.com Wed Dec 26 13:14:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8C621F8CFB for ; Wed, 26 Dec 2012 13:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.269 X-Spam-Level: X-Spam-Status: No, score=-109.269 tagged_above=-999 required=5 tests=[AWL=1.330, 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 2kkLvjP1z-61 for ; Wed, 26 Dec 2012 13:14:34 -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 E2D3A21F8CF3 for ; Wed, 26 Dec 2012 13:14:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=975; q=dns/txt; s=iport; t=1356556474; x=1357766074; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=amHfch7BLstN3NSFXj//f3hLu16Uh1mEw9zOark01eU=; b=CQF1WCTjCfbmHUUGotGpxMS7UTvtDbF4STTHfzsAL+S2ZBiMgGQUY5x2 Y+xpZTjeGpWlKrihHig4g6sFFaAvKZE//m7ebFRo8nww1rVFFix1T5vIz SchKx62qjiXMLu+WtIfBo3XJTks5gNvVt5rVyoXzasUdZkL0OIHK4/A+y 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFADRo21CtJXG9/2dsb2JhbABFhXO3bhZzgh4BAQEDAQEBARpsAgEIDgoKJDIlAgMBARIIiAUGtTmMV4NiYQOmVIJ0giI X-IronPort-AV: E=Sophos;i="4.84,359,1355097600"; d="scan'208";a="156683065" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 26 Dec 2012 21:14:33 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBQLEXGX022266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Dec 2012 21:14:33 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Wed, 26 Dec 2012 15:14:33 -0600 From: "Cullen Jennings (fluffy)" To: Eric Burger , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN463/CbeSbDi/ukOQqVVSt4Wdzw== Date: Wed, 26 Dec 2012 21:14:32 +0000 Message-ID: References: <50D2CC6A.4090500@ericsson.com> <50D3E3BF.7070609@mozilla.com> <50D48DD8.3050702@nostrum.com> <5BEDD27D-B359-4CD4-B01C-427E6BB1372A@standardstrack.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] Content-Type: text/plain; charset="Windows-1252" Content-ID: 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: Wed, 26 Dec 2012 21:14:34 -0000 On Dec 26, 2012, at 10:18 AM, Cullen Jennings wrote: >=20 > On Dec 25, 2012, at 5:29 AM, Eric Burger w= rote: >=20 >>=20 >> We then either have a nice big section in this present document describi= ng the current state of the art of various networks with various codecs *OR= * we have an Informational Implementor's Guide that describes the current s= tate of the art of various networks, as well as the pitfalls of popular but= hard codecs, like G.722. >=20 > Would someone be willing to summarize a list of codecs that at some peopl= e have argued strongly in favor of along with the main advantage of thawing= that codec. I'm thinking of a list that looks something like >=20 > AMR-WB Gets you interop with existing 3GPP=20 >=20 > Having a list like this would be a handy quick references to discussion. >=20 >=20 Change "thawing" to "having" in above (Curse you autocorrect) =20 From bernard_aboba@hotmail.com Wed Dec 26 15:52:15 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3535A21F8CD8 for ; Wed, 26 Dec 2012 15:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.025, 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 T+gxKIC-Yzx4 for ; Wed, 26 Dec 2012 15:52:11 -0800 (PST) Received: from blu0-omc4-s14.blu0.hotmail.com (blu0-omc4-s14.blu0.hotmail.com [65.55.111.153]) by ietfa.amsl.com (Postfix) with ESMTP id 16B9621F8C6C for ; Wed, 26 Dec 2012 15:52:11 -0800 (PST) Received: from BLU405-EAS49 ([65.55.111.137]) by blu0-omc4-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Dec 2012 15:52:10 -0800 X-EIP: [jlqLBBQr9C4M/PWt+1SSsHDSK84rfZEb] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_f2694c02-b8bc-40ca-bdfa-babc27dcb291_" MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" , "rtcweb@ietf.org" From: Bernard Aboba Date: Wed, 26 Dec 2012 15:52:01 -0800 X-OriginalArrivalTime: 26 Dec 2012 23:52:10.0215 (UTC) FILETIME=[0517BF70:01CDE3C4] 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, 26 Dec 2012 23:52:15 -0000 --_f2694c02-b8bc-40ca-bdfa-babc27dcb291_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I quite liked "thawing" actually - since the audio codecs in question are f= rozen from a distant era :) ________________________________ From: Cullen Jennings (fluffy) Sent: =E2=80=8E12/=E2=80=8E26/=E2=80=8E2012 1:14 PM To: Eric Burger=3B rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Au= dio Codecs On Dec 26=2C 2012=2C at 10:18 AM=2C Cullen Jennings wrot= e: > > On Dec 25=2C 2012=2C at 5:29 AM=2C Eric Burger wrote: > >> >> We then either have a nice big section in this present document describi= ng the current state of the art of various networks with various codecs *OR= * we have an Informational Implementor's Guide that describes the current s= tate of the art of various networks=2C as well as the pitfalls of popular b= ut hard codecs=2C like G.722. > > Would someone be willing to summarize a list of codecs that at some peopl= e have argued strongly in favor of along with the main advantage of thawing= that codec. I'm thinking of a list that looks something like > > AMR-WB Gets you interop with existing 3GPP > > Having a list like this would be a handy quick references to discussion. > > Change "thawing" to "having" in above (Curse you autocorrect) _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_f2694c02-b8bc-40ca-bdfa-babc27dcb291_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
I quite= liked "=3Bthawing"=3B actually - since the audio codecs in questio= n are frozen from a distant era :)
From: Cullen Jennings (fluffy) Sent: =E2=80=8E12/=E2=80=8E26/=E2=80=8E2012 1:14 PM
To: Eric Burger=3B rtcweb@ietf.org
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Code= cs


On Dec 26=2C 2012=2C at 10:18 AM=2C Cullen Jennings <=3Bfluffy@cisco.com&= gt=3B wrote:

>=3B
>=3B On Dec 25=2C 2012=2C at 5:29 AM=2C Eric Burger <=3Beburger-l@stand= ardstrack.com>=3B wrote:
>=3B
>=3B>=3B
>=3B>=3B We then either have a nice big section in this present documen= t describing the current state of the art of various networks with various = codecs *OR* we have an Informational Implementor's Guide that describes the= current state of the art of various networks=2C as well as the pitfalls of popular but hard codecs=2C like G.722.
>=3B
>=3B Would someone be willing to summarize a list of codecs that at some = people have argued strongly in favor of along with the main advantage of th= awing that codec. I'm thinking of a list that looks something like
>=3B
>=3B AMR-WB =3B =3B Gets you interop with existing 3GPP
>=3B
>=3B Having a list like this would be a handy quick references to discuss= ion.
>=3B
>=3B

Change =3B "=3Bthawing"=3B =3B to "=3Bhaving"=3B in= above

(Curse you autocorrect)


 =3B

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb
--_f2694c02-b8bc-40ca-bdfa-babc27dcb291_-- From tim@phonefromhere.com Thu Dec 27 04:14:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0746D21F8C87 for ; Thu, 27 Dec 2012 04:14:37 -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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKVLUQDctr+3 for ; Thu, 27 Dec 2012 04:14:36 -0800 (PST) Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by ietfa.amsl.com (Postfix) with ESMTP id 18C6921F8C8D for ; Thu, 27 Dec 2012 04:14:35 -0800 (PST) Received: (qmail 19194 invoked from network); 27 Dec 2012 12:14:32 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp004.apm-internet.net with SMTP; 27 Dec 2012 12:14:32 -0000 Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id BE0A818A0AA5; Thu, 27 Dec 2012 12:14:32 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Panton In-Reply-To: <5BEDD27D-B359-4CD4-B01C-427E6BB1372A@standardstrack.com> Date: Thu, 27 Dec 2012 12:14:23 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6E10EE20-524E-46F0-B4A7-0B039EBF34BD@phonefromhere.com> References: <50D2CC6A.4090500@ericsson.com> <50D3E3BF.7070609@mozilla.com> <50D48DD8.3050702@nostrum.com> <5BEDD27D-B359-4CD4-B01C-427E6BB1372A@standardstrack.com> To: Eric Burger 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: Thu, 27 Dec 2012 12:14:37 -0000 On 25 Dec 2012, at 12:29, Eric Burger wrote: > Adam has got it in one. >=20 > Listen to the arguments: "We want interop with 3G. No, we want interop = with SIP/PSTN. No, we want interop with SIP/WB. No, we want interop with = NGN. No, we want interop with Skype. No, we want interop with=85." >=20 > Each of these networks seem to have their own preferred codec. Most of = the arguments on the list are of the form, "I want my favorite codec for = my favorite network as a SHOULD or as a RECOMMENDED." When in fact (based on my experience at protothon and elsewhere) the = _huge_ _predominant_ usage will be browser to browser, peer-to-peer. We need to be _very_ sure that nothing we do here for the sake of legacy = interop makes that user-experience worse. >=20 > The major gastrointestinal objection I have here is every week we = argue, someone will come up with "we want to interop with Future Tech = 1." >=20 > What I would offer as a way forward is to mandate G.711, because we = could not agree to mandate opus, and mandate NOTHING ELSE. >=20 I thought the current status was that we had agreed to mandate G.711 and = Opus already? > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From tim@phonefromhere.com Thu Dec 27 04:22:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF23421F88A9 for ; Thu, 27 Dec 2012 04:22:01 -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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09bbhMDA7Sk2 for ; Thu, 27 Dec 2012 04:22:01 -0800 (PST) Received: from smtp003.apm-internet.net (smtp003.apm-internet.net [85.119.248.52]) by ietfa.amsl.com (Postfix) with ESMTP id ADF3621F8884 for ; Thu, 27 Dec 2012 04:22:00 -0800 (PST) Received: (qmail 60356 invoked from network); 27 Dec 2012 12:21:59 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp003.apm-internet.net with SMTP; 27 Dec 2012 12:21:59 -0000 Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id D466618A0ACA; Thu, 27 Dec 2012 12:21:58 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: Date: Thu, 27 Dec 2012 12:21:58 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <30CCEF02-8AB3-49DE-AF6D-C03B1005F9CC@phonefromhere.com> References: <50D2CC6A.4090500@ericsson.com> <50D3E3BF.7070609@mozilla.com> <50D48DD8.3050702@nostrum.com> <5BEDD27D-B359-4CD4-B01C-427E6BB1372A@standardstrack.com> To: Cullen Jennings (fluffy) X-Mailer: Apple Mail (2.1283) Cc: Eric Burger , "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, 27 Dec 2012 12:22:02 -0000 On 26 Dec 2012, at 17:18, Cullen Jennings (fluffy) wrote: >=20 > On Dec 25, 2012, at 5:29 AM, Eric Burger = wrote: >=20 >>=20 >> We then either have a nice big section in this present document = describing the current state of the art of various networks with various = codecs *OR* we have an Informational Implementor's Guide that describes = the current state of the art of various networks, as well as the = pitfalls of popular but hard codecs, like G.722. >=20 > Would someone be willing to summarize a list of codecs that at some = people have argued strongly in favor of along with the main advantage of = thawing that codec. I'm thinking of a list that looks something like >=20 > AMR-WB Gets you interop with existing 3GPP=20 Haha. As if just having the code was going to allow you to interop with = existing 3gpp ! How about:=20 AMR-WB Might slightly help your interop struggles with 3gpp - will = definitely land you with a license bill and a user counting problem. >=20 > Having a list like this would be a handy quick references to = discussion. Have we agreed to have a discussion ?=20 I thought this was talks about talks to overthrow an existing decision. If we are in the mood to throw out existing decisions, I've a few I'd = like to revisit ..... T. >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From eburger-l@standardstrack.com Thu Dec 27 06:31:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F8621F8BEA for ; Thu, 27 Dec 2012 06:31:48 -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 s0FGXA9yYtRC for ; Thu, 27 Dec 2012 06:31:47 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id EB47A21F890D for ; Thu, 27 Dec 2012 06:31:45 -0800 (PST) Received: from cpe-74-76-86-197.nycap.res.rr.com ([74.76.86.197]:53534 helo=[192.168.0.191]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1ToEUq-00062Y-RT for rtcweb@ietf.org; Thu, 27 Dec 2012 06:31:44 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric Burger In-Reply-To: Date: Thu, 27 Dec 2012 09:31:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <095DB9F1-E82E-471E-95F9-1472FFAC68E2@standardstrack.com> References: To: "rtcweb@ietf.org" 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: 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, 27 Dec 2012 14:31:48 -0000 Bernard said this as a joke, but as many think there is some truth = behind every joke, this *is* the issue. By the time we finish the work = group, ideally in 2015 (Cullen - thanks for the CDN 100!), *all* of the = codecs that someone thinks is really important to have implemented OR = ELSE will be pass=C3=A9, obsolete, or their patents expired. That is why I do not see the value of publishing a long list of SHOULD = codecs to implement. It would be much more useful to implementers to = explain which codecs go to what and why. Now, if we can agree on some good codecs that MUST be implemented, I can = get behind that. Happy Holidays, Eric On Dec 26, 2012, at 6:52 PM, Bernard Aboba = wrote: > I quite liked "thawing" actually - since the audio codecs in question = are frozen from a distant era :) > From: Cullen Jennings (fluffy) > Sent: =E2=80=8E12/=E2=80=8E26/=E2=80=8E2012 1:14 PM > To: Eric Burger; rtcweb@ietf.org > Subject: Re: [rtcweb] Call for Consensus Regarding Selecting = Recommended Audio Codecs >=20 >=20 > On Dec 26, 2012, at 10:18 AM, Cullen Jennings = wrote: >=20 > >=20 > > On Dec 25, 2012, at 5:29 AM, Eric Burger = wrote: > >=20 > >>=20 > >> We then either have a nice big section in this present document = describing the current state of the art of various networks with various = codecs *OR* we have an Informational Implementor's Guide that describes = the current state of the art of various networks, as well as the = pitfalls of popular but hard codecs, like G.722. > >=20 > > Would someone be willing to summarize a list of codecs that at some = people have argued strongly in favor of along with the main advantage of = thawing that codec. I'm thinking of a list that looks something like > >=20 > > AMR-WB Gets you interop with existing 3GPP=20 > >=20 > > Having a list like this would be a handy quick references to = discussion. > >=20 > >=20 >=20 > Change "thawing" to "having" in above >=20 > (Curse you autocorrect) >=20 >=20 > =20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ietf@kenfischer.net Thu Dec 27 08:10:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C44F21F8D6E for ; Thu, 27 Dec 2012 08:10:09 -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 gSsd4kGGWZ2C for ; Thu, 27 Dec 2012 08:10:08 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 191F321F8D8D for ; Thu, 27 Dec 2012 08:10:05 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 8640E2AC06A for ; Thu, 27 Dec 2012 08:10:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=kenfischer.net; h=from:to :references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding; s=kenfischer.net; bh=G+ 4aCk9Sk0CLOiIu1JwEONcZzSk=; b=fzw9AoEt3HPnhZV+Y9+TrSe68+qbv2OOSi nQxI0HM/H8rBqLKzoiszSiECfP2N+kHfm7UihvbpqaIbUo64OVcWvSY5/nogrWW9 geoO+uQI+aHsUh3spX8q44GZBtYWQIw4D3+l7AssdubWaD3P9Hw6JGOfhc9uKl8R KOBmhJeJw= Received: from XPMACVM (c-67-176-36-142.hsd1.co.comcast.net [67.176.36.142]) (Authenticated sender: ietf@kenfischer.net) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPA id 55CF42AC05D for ; Thu, 27 Dec 2012 08:10:04 -0800 (PST) From: "Ken Fischer" To: References: <095DB9F1-E82E-471E-95F9-1472FFAC68E2@standardstrack.com> In-Reply-To: Date: Thu, 27 Dec 2012 09:10:03 -0700 Message-ID: <000001cde44c$a1a7f980$e4f7ec80$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-Index: Ac3kS6b5OI3BmCNqT5+E/yCRC2nCqQAAOnvg 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, 27 Dec 2012 16:10:09 -0000 +1 Ken On 12/27/12 7:31 AM, "Eric Burger" wrote: >Bernard said this as a joke, but as many think there is some truth=20 >behind every joke, this *is* the issue. By the time we finish the work=20 >group, ideally in 2015 (Cullen - thanks for the CDN 100!), *all* of the = >codecs that someone thinks is really important to have implemented OR=20 >ELSE will be pass=E9, obsolete, or their patents expired. > >That is why I do not see the value of publishing a long list of SHOULD=20 >codecs to implement. It would be much more useful to implementers to=20 >explain which codecs go to what and why. > >Now, if we can agree on some good codecs that MUST be implemented, I=20 >can get behind that. > >Happy Holidays, >Eric > >On Dec 26, 2012, at 6:52 PM, Bernard Aboba >wrote: > >> I quite liked "thawing" actually - since the audio codecs in question = >>are frozen from a distant era :) >> From: Cullen Jennings (fluffy) >> Sent: 12/26/2012 1:14 PM >> To: Eric Burger; rtcweb@ietf.org >> Subject: Re: [rtcweb] Call for Consensus Regarding Selecting=20 >>Recommended Audio Codecs >>=20 >>=20 >> On Dec 26, 2012, at 10:18 AM, Cullen Jennings = wrote: >>=20 >> >=20 >> > On Dec 25, 2012, at 5:29 AM, Eric Burger >> wrote: >> >=20 >> >>=20 >> >> We then either have a nice big section in this present document >>describing the current state of the art of various networks with=20 >>various codecs *OR* we have an Informational Implementor's Guide that=20 >>describes the current state of the art of various networks, as well as = >>the pitfalls of popular but hard codecs, like G.722. >> >=20 >> > Would someone be willing to summarize a list of codecs that at some >>people have argued strongly in favor of along with the main advantage=20 >>of thawing that codec. I'm thinking of a list that looks something=20 >>like >> >=20 >> > AMR-WB Gets you interop with existing 3GPP >> >=20 >> > Having a list like this would be a handy quick references to >>discussion. >> >=20 >> >=20 >>=20 >> Change "thawing" to "having" in above >>=20 >> (Curse you autocorrect) >>=20 >>=20 >> =20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Thu Dec 27 08:17:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693BE21F8D71 for ; Thu, 27 Dec 2012 08:17: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 ha9pZPIGgwmA for ; Thu, 27 Dec 2012 08:17:00 -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 8812C21F8D55 for ; Thu, 27 Dec 2012 08:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2115; q=dns/txt; s=iport; t=1356625020; x=1357834620; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ehrTgQCiNYErYnynYoDVreJxcVmRX3Lhkee+sdX4Tds=; b=dZZv5GusrTsrKedCODR/6uS3gyaVYzvU0OQvcPmw3kf31aKqTTmWZzET sCulHg6vX4V2gSHEhVx5ZiCXKkOGeovXjrG7xN1mxzHX3fCH2S3E6hyxb ykvFAivUjtLRhi0kWRI1NqkNRWryROWhkShe6Aq2BLN9bI+1fFEu/+tRD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABFz3FCtJV2a/2dsb2JhbABFvWMWc4IeAQEBAwEdHT8FCwIBCBgKFBAyJQIEDgUIiAUGti6MV4NiYQOmVIJ0giI X-IronPort-AV: E=Sophos;i="4.84,363,1355097600"; d="scan'208";a="156905531" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 27 Dec 2012 16:16:59 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBRGGxL8014160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Dec 2012 16:16:59 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Thu, 27 Dec 2012 10:16:59 -0600 From: "Cullen Jennings (fluffy)" To: Tim Panton Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN5CzDDpQPLzmK20mNPcVtrlHf1ZgtN2qA Date: Thu, 27 Dec 2012 16:16:58 +0000 Message-ID: References: <50D2CC6A.4090500@ericsson.com> <50D3E3BF.7070609@mozilla.com> <50D48DD8.3050702@nostrum.com> <5BEDD27D-B359-4CD4-B01C-427E6BB1372A@standardstrack.com> <30CCEF02-8AB3-49DE-AF6D-C03B1005F9CC@phonefromhere.com> In-Reply-To: <30CCEF02-8AB3-49DE-AF6D-C03B1005F9CC@phonefromhere.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] Content-Type: text/plain; charset="us-ascii" Content-ID: <3E93F65FF3E1E147A01226E726064BAA@cisco.com> 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: Thu, 27 Dec 2012 16:17:01 -0000 On Dec 27, 2012, at 5:21 AM, Tim Panton wrote: >=20 > On 26 Dec 2012, at 17:18, Cullen Jennings (fluffy) wrote: >=20 >>=20 >> On Dec 25, 2012, at 5:29 AM, Eric Burger = wrote: >>=20 >>>=20 >>> We then either have a nice big section in this present document describ= ing the current state of the art of various networks with various codecs *O= R* we have an Informational Implementor's Guide that describes the current = state of the art of various networks, as well as the pitfalls of popular bu= t hard codecs, like G.722. >>=20 >> Would someone be willing to summarize a list of codecs that at some peop= le have argued strongly in favor of along with the main advantage of thawin= g that codec. I'm thinking of a list that looks something like >>=20 >> AMR-WB Gets you interop with existing 3GPP=20 >=20 > Haha. As if just having the code was going to allow you to interop with e= xisting 3gpp ! ok - point take than more that is needed but what I'm look info for is the = one line bumper sticker style summary of why people feel they want some giv= en codec.=20 > How about:=20 >=20 > AMR-WB Might slightly help your interop struggles with 3gpp - will def= initely land you with a license bill and a user counting problem. >=20 >>=20 >> Having a list like this would be a handy quick references to discussion. >=20 > Have we agreed to have a discussion ?=20 > I thought this was talks about talks to overthrow an existing decision. >=20 > If we are in the mood to throw out existing decisions, I've a few I'd lik= e to revisit ..... Just to be clear, we are not talking about tossing out previous decisions. = When we decided to make OPUS MTI, we at the same time agreed to not rule ou= t other codecs in the future. That was part of how we got to consensus on O= PUS. We are in the middle of a consensus call on that topic of looking and= other codecs and reading the messages on that consensus call, it's a bit h= ard to figure out what codecs people might want to talk about and why.=20 From harald@alvestrand.no Thu Dec 27 08:32:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F6321F8CBF for ; Thu, 27 Dec 2012 08:32:54 -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 7prM3-7F48es for ; Thu, 27 Dec 2012 08:32:53 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B1BAD21F8C9F for ; Thu, 27 Dec 2012 08:32:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3141739E0F0 for ; Thu, 27 Dec 2012 17:32:50 +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 AP8JnhlrfHyY for ; Thu, 27 Dec 2012 17:32:49 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:80a9:14ab:c6e3:d22d] (unknown [IPv6:2001:470:de0a:27:80a9:14ab:c6e3:d22d]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0817539E056 for ; Thu, 27 Dec 2012 17:32:48 +0100 (CET) Message-ID: <50DC7830.1010206@alvestrand.no> Date: Thu, 27 Dec 2012 17:32:48 +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> In-Reply-To: <50D2CC6A.4090500@ericsson.com> 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: Thu, 27 Dec 2012 16:32:54 -0000 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ä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 fluffy@cisco.com Thu Dec 27 08:40:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D149E21F8D52 for ; Thu, 27 Dec 2012 08:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.252 X-Spam-Level: X-Spam-Status: No, score=-109.252 tagged_above=-999 required=5 tests=[AWL=1.047, 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 MjcvkLS6NyEd for ; Thu, 27 Dec 2012 08:40:08 -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 294CC21F8D40 for ; Thu, 27 Dec 2012 08:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=892; q=dns/txt; s=iport; t=1356626408; x=1357836008; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=k6trSn4SEYT3BeHGOu8J2EwSEp5KBxFAq8mYER1oA1A=; b=HQbuhIUsiQGxKrcHJ9kWZdAGRtTeczO4As0wbDSLmFbpwCaSUSLBTMG/ 9U+9orpeZUkzFVcpqwhdjDOseYMwkipEdeRPZdWdpMNTmjx1IKPE3gZ6l GKORwDwACZE0SnS8jlVxhE9h1ty9L+S/g46jsX2Uca632rbacHwYFVhqB Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFABN43FCtJV2a/2dsb2JhbABFhXO3cBZzgh4BAQEDAXkFCwIBCCIkMiUCBA4FCIgFBrYpjFeDYmEDiC2eJ4J0giI X-IronPort-AV: E=Sophos;i="4.84,363,1355097600"; d="scan'208";a="156881614" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 27 Dec 2012 16:40:07 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBRGe7Jj011231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Dec 2012 16:40:07 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Thu, 27 Dec 2012 10:40:07 -0600 From: "Cullen Jennings (fluffy)" To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= Thread-Topic: [rtcweb] Support of video with different resolutions Thread-Index: AQHN5FDTddf37wH3QkWZB9XnuPWRdg== Date: Thu, 27 Dec 2012 16:40:07 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B06E211@ESESSMB209.ericsson.se> <50D4F06D.3020602@omnitor.se> In-Reply-To: <50D4F06D.3020602@omnitor.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] 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] 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: Thu, 27 Dec 2012 16:40:08 -0000 On Dec 21, 2012, at 4:27 PM, Gunnar Hellstr=F6m wrote: > This is sad. For good usability of video, maintained frame rate is usuall= y much more important than maintained spatial resolution. E.g. for sign lan= guage or lip reading usage with a single person in image, a frame rate unde= r 20 fps introduces loss of language contents, and requires the users to tr= y to fill in the gaps by imagination, while spatial resolution reduction do= wn to QCIF causes much less harm to language perception possibilities. Hmm - I think the trade off is a bit more complicated. The is both a minimu= m number of pixels for the hand + a minimum frame rate - if you get under e= ither of theses , SL does not work real well. Does anyone have pointers to = research that shows what theses are? I've see this type of study in the pa= st but can't find it. From ssokol@digium.com Thu Dec 27 09:05:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11C721F8D53 for ; Thu, 27 Dec 2012 09:05:37 -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 51HdOZO9FYe0 for ; Thu, 27 Dec 2012 09:05:37 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id F301421F8D47 for ; Thu, 27 Dec 2012 09:05:36 -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 1ToGti-0002Fd-VL; Thu, 27 Dec 2012 11:05:34 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id DF700D887B; Thu, 27 Dec 2012 11:05:34 -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 MQl9itexPgeT; Thu, 27 Dec 2012 11:05:34 -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 7CCC9D8002; Thu, 27 Dec 2012 11:05:34 -0600 (CST) Date: Thu, 27 Dec 2012 11:05:34 -0600 (CST) From: Steve Sokol To: "Cullen Jennings (fluffy)" Message-ID: <7daabbec-07cc-421e-b6d4-5292b9c063b5@zimbra> In-Reply-To: Content-Type: multipart/alternative; boundary="=_87123264-dcb7-483c-bb7c-fc6ffdef67c5" MIME-Version: 1.0 X-Mailer: Zimbra 7.1.3_GA_3346 (ZimbraWebClient - GC23 (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, 27 Dec 2012 17:05:37 -0000 --=_87123264-dcb7-483c-bb7c-fc6ffdef67c5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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. --=_87123264-dcb7-483c-bb7c-fc6ffdef67c5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 12pt; colo= r: #000000'>
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 depl= oyment in both hard and soft endpoints. G.722 has no known IPR issues. It c= onsumes 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,&nb= sp;AMR-WB - The official standa= rds for mobile telephony. Adding support for the AMR codecs would arguably = simplify the process of interoperation with mobile endpoints. Licenses woul= d be required as both include patented technology.

None - Several group members have argued that the standard s= hould not include SHOULD or RECOMMENDED codecs for various reasons.

Speaking for myself, I don't see much reason to include a= ny of these. With mandatory encryption, media stream bundling and various o= ther divergences from the way most legacy endpoints operate, I don't see un= mediated legacy interoperability as likely to happen -- you will always nee= d 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 t= o re-build the PSTN on yet another IP platform. Keep is simple. 
=
--=_87123264-dcb7-483c-bb7c-fc6ffdef67c5-- From adam@nostrum.com Thu Dec 27 10:21:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E1721F8D60 for ; Thu, 27 Dec 2012 10:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.605 X-Spam-Level: X-Spam-Status: No, score=-102.605 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 zKmBfj2TSn5v for ; Thu, 27 Dec 2012 10:21:12 -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 75F5721F8D5F for ; Thu, 27 Dec 2012 10:21:12 -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 qBRIKt13037212 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 27 Dec 2012 12:20:58 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50DC9187.6010300@nostrum.com> Date: Thu, 27 Dec 2012 12:20: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: Steve Sokol References: <7daabbec-07cc-421e-b6d4-5292b9c063b5@zimbra> In-Reply-To: <7daabbec-07cc-421e-b6d4-5292b9c063b5@zimbra> 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: "Cullen Jennings \(fluffy\)" , 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, 27 Dec 2012 18:21:13 -0000 On 12/27/12 11:05, Steve Sokol wrote: > I don't see unmediated legacy interoperability as likely to happen Ugh. I hate repeating this, but there is a radical difference between dealing with computationally cheap things like bundling, ICE, SCTP and even (from a relative perspective) encryption and dealing with re-encoding media. Transcoding perceptibly increases end-to-end latency. Transcoding perceptibly degrades the final audio stream. All other gatewaying functions can be done cheaply enough that the user cannot tell a difference. Which is why I think there is *utility* to listing commonly used codecs and explaining where/how they are used. I really do want to see this as part of a guidance section for implementors. However, I don't think any of those reasons rise to the level of an RFC 2119 "SHOULD" level statement. /a From koen.vos@skype.net Thu Dec 27 10:34:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF89A21F87D1 for ; Thu, 27 Dec 2012 10:34:20 -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.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 TSIslxw2GDdl for ; Thu, 27 Dec 2012 10:34:20 -0800 (PST) Received: from NA01-BY1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.88]) by ietfa.amsl.com (Postfix) with ESMTP id C8BB621F83EF for ; Thu, 27 Dec 2012 10:34:19 -0800 (PST) Received: from CH1SR01CA105.namsdf01.sdf.exchangelabs.com (10.255.157.22) by CH1SR01MB610.namsdf01.sdf.exchangelabs.com (10.255.157.38) with Microsoft SMTP Server (TLS) id 15.0.601.0; Thu, 27 Dec 2012 18:34:14 +0000 Received: from BY1FFOFD002.ffo.gbl (64.4.22.87) by CH1SR01CA105.outlook.com (10.255.157.22) with Microsoft SMTP Server (TLS) id 15.0.596.2 via Frontend Transport; Thu, 27 Dec 2012 18:34:12 +0000 Received: from hybrid.exchange.microsoft.com (131.107.1.17) by BY1FFOFD002.mail.o365filtering.com (10.1.16.84) with Microsoft SMTP Server (TLS) id 15.0.596.1 via Frontend Transport; Thu, 27 Dec 2012 18:34:11 +0000 Received: from DFM-TK5MBX15-03.exchange.corp.microsoft.com (157.54.110.22) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.3.118.0; Thu, 27 Dec 2012 10:33:46 -0800 Received: from DFM-CO1MBX15-02.exchange.corp.microsoft.com (157.59.247.79) by DFM-TK5MBX15-03.exchange.corp.microsoft.com (157.54.110.22) with Microsoft SMTP Server (TLS) id 15.0.516.32; Thu, 27 Dec 2012 10:33:45 -0800 Received: from DFM-CO1MBX15-04.exchange.corp.microsoft.com (157.59.247.11) by DFM-CO1MBX15-02.exchange.corp.microsoft.com (157.59.247.79) with Microsoft SMTP Server (TLS) id 15.0.516.32; Thu, 27 Dec 2012 10:33:45 -0800 Received: from DFM-CO1MBX15-04.exchange.corp.microsoft.com ([157.59.247.11]) by DFM-CO1MBX15-04.exchange.corp.microsoft.com ([169.254.5.92]) with mapi id 15.00.0516.029; Thu, 27 Dec 2012 10:33:44 -0800 From: Koen Vos To: Steve Sokol , "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN5FRugqIzVKzRI02UvNc3NraaMZgs7z6m Date: Thu, 27 Dec 2012 18:33:44 +0000 Message-ID: <720e6883d7994faf9b3d415fcc88eca5@DFM-CO1MBX15-04.exchange.corp.microsoft.com> References: , <7daabbec-07cc-421e-b6d4-5292b9c063b5@zimbra> In-Reply-To: <7daabbec-07cc-421e-b6d4-5292b9c063b5@zimbra> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.13] Content-Type: multipart/alternative; boundary="_000_720e6883d7994faf9b3d415fcc88eca5DFMCO1MBX1504exchangeco_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.1.17; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(377454001)(52084001)(512954001)(47736001)(46102001)(51856001)(50986001)(47976001)(49866001)(16236675001)(876001)(4396001)(53806001)(76482001)(5343655001)(54356001)(44976002)(47446002)(33646001)(54316002)(74662001)(74502001)(16406001)(56816002)(56776001)(77982001)(31966008)(59766001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CH1SR01MB610; H:hybrid.exchange.microsoft.com; LANG:en; X-Forefront-PRVS: 07083FF734 X-OriginatorOrg: msft.ccsctp.net 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, 27 Dec 2012 18:34:20 -0000 --_000_720e6883d7994faf9b3d415fcc88eca5DFMCO1MBX1504exchangeco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 Concealme= nt methods that were later added to the standard are patented. This matter= s because G.722 uses ADPCM and is unusually sensitive to packet loss. For = instance, without PLC the codec will sometimes generate a full-scale oscill= ating output after a loss. Since a traditional PLC doesn't work for this k= ind 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, AMR-WB - The official standards for mobile telephony. Adding support f= or the AMR codecs would arguably simplify the process of interoperation wit= h mobile endpoints. Licenses would be required as both include patented tec= hnology. 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. That being the case, why clutter up the standard with "SHOU= LD" 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. --_000_720e6883d7994faf9b3d415fcc88eca5DFMCO1MBX1504exchangeco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
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 Recomme= nded 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 includin= g them in the standard:

G.722 - The de facto standard for "HD audio", G.722 h= as 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 cove= rs most use cases (though not Edge). Inclusion of G.722 would arguably simplify interoperability with HD-capable legacy e= ndpoints and gateways.

AMR, AMR-WB - The of= ficial standards for mobile telephony. Adding support for the AMR codecs wo= uld 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 shou= ld 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 divergen= ces from the way most legacy endpoints operate, I don't see unmediated lega= cy interoperability as likely to happen -- you will always need something to act as a gateway.  That b= eing 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. 
--_000_720e6883d7994faf9b3d415fcc88eca5DFMCO1MBX1504exchangeco_-- From Markus.Isomaki@nokia.com Mon Dec 31 03:28:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C9C21F8756 for ; Mon, 31 Dec 2012 03:28:45 -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 6Z55vQBkRmTF for ; Mon, 31 Dec 2012 03:28:45 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id E446F21F867B for ; Mon, 31 Dec 2012 03:28:44 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qBVBSfjn005441; Mon, 31 Dec 2012 13:28:42 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Dec 2012 13:28:41 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.146]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0318.003; Mon, 31 Dec 2012 11:28:40 +0000 From: To: , Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN35gKKGER8UnZokqrcUx5QDpaGJgyzYjw Date: Mon, 31 Dec 2012 11:28:40 +0000 Message-ID: References: <50D2CC6A.4090500@ericsson.com> <50D3E3BF.7070609@mozilla.com> <50D48DD8.3050702@nostrum.com> In-Reply-To: <50D48DD8.3050702@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.81.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Dec 2012 11:28:41.0612 (UTC) FILETIME=[FC5BDCC0:01CDE749] X-Nokia-AV: Clean 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, 31 Dec 2012 11:28:45 -0000 Hi, Actually, I think both Tim and Adam have good points below. RFC 2119 style = RECOMMENDED or SHOULD is perhaps too strong. I don't have a problem if we j= ust list the most relevant non-MTI codecs and give guidance why it would be= beneficial to support them. So far a few people have brought up AMR/AMR-WB and G.722 with relatively cl= ear arguments. iLBC and AAC-LD have been mentioned too, but I think their b= enefits have not been as well clarified so far. Markus >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of ext Adam Roach >Sent: 21 December, 2012 18:27 >To: Timothy B. Terriberry >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended >Audio Codecs > >On 12/20/12 22:21, Timothy B. Terriberry wrote: >> Markus.Isomaki@nokia.com wrote: >>> My proposal would be to recommend AMR, and perhaps AMR-WB. The >>> rationale is >> >> I don't think we should list a set of RECOMMENDED codecs. If we were >> talking just G.722, iLBC, etc., I might be persuaded. But this is a >> 2119 RECOMMENDED, which is a bit stronger than "Gee, it would be >> nice," and given the aforementioned IPR situation, Mozilla is not >> likely to be deploying any of the AMR family anytime soon. >> >> If the goal is interoperability with deployed systems, you're going to >> implement what you need to implement to achieve that, and nothing we >> write down in an RFC will change what that needs to be. > >I'm going to have to agree with Tim -- very little would be served by havi= ng >normative SHOULD-strength requirements here. > >What I think would be beneficial would be a section documenting codecs in >widespread use today, where they're used, and what is gained by including >them in WebRTC implementations (mostly transcoder-free interop with those >other implementations). Documenting that AMR is used in 3GPP VoIP >networks would allow implementors to make an educated decision about the >benefit of including that codec. A similar mention that many modern VoIP >phones support G.722 and/or AAC-LD would provide similar guidance. > >But I don't think there's much to be gained by readying the scarlet letter= of >"conditionally compliant" that would result from a SHOULD-strength >normative statement about royalty-bearing codecs. > >/a >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From Markus.Isomaki@nokia.com Mon Dec 31 03:33:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D194921F8799 for ; Mon, 31 Dec 2012 03:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.724 X-Spam-Level: X-Spam-Status: No, score=-6.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 gosYpC8o9sdO for ; Mon, 31 Dec 2012 03:33:31 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1F28821F8694 for ; Mon, 31 Dec 2012 03:33:31 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qBVBWfFA013210; Mon, 31 Dec 2012 13:33:25 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.49]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Dec 2012 13:33:24 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.146]) by 008-AM1MMR2-015.mgdnok.nokia.com ([65.54.30.49]) with mapi id 14.02.0318.003; Mon, 31 Dec 2012 11:33:23 +0000 From: To: , Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN5F75KGER8UnZokqrcUx5QDpaGJgyy3Bw Date: Mon, 31 Dec 2012 11:33:23 +0000 Message-ID: References: <7daabbec-07cc-421e-b6d4-5292b9c063b5@zimbra> <50DC9187.6010300@nostrum.com> In-Reply-To: <50DC9187.6010300@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.81.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Dec 2012 11:33:24.0583 (UTC) FILETIME=[A505CF70:01CDE74A] X-Nokia-AV: Clean Cc: fluffy@cisco.com, 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, 31 Dec 2012 11:33:32 -0000 Hi, Yes, I agree Adam's proposal would be the best approach. A codec alone will= not solve the interop issues with IMS or other external VoIP systems, but = as Adam says, transcode-free operation at the (media) gateway would be an i= mportant consideration.=20 Markus >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of ext Adam Roach >Sent: 27 December, 2012 20:21 >To: Steve Sokol >Cc: Cullen Jennings (fluffy); rtcweb@ietf.org >Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended >Audio Codecs > >On 12/27/12 11:05, Steve Sokol wrote: >> I don't see unmediated legacy interoperability as likely to happen > >Ugh. I hate repeating this, but there is a radical difference between deal= ing >with computationally cheap things like bundling, ICE, SCTP and even (from = a >relative perspective) encryption and dealing with re-encoding media. > >Transcoding perceptibly increases end-to-end latency. Transcoding >perceptibly degrades the final audio stream. All other gatewaying function= s >can be done cheaply enough that the user cannot tell a difference. > >Which is why I think there is *utility* to listing commonly used codecs an= d >explaining where/how they are used. I really do want to see this as part o= f a >guidance section for implementors. > >However, I don't think any of those reasons rise to the level of an RFC >2119 "SHOULD" level statement. > >/a >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Mon Dec 31 08:50:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A13F21F88A6 for ; Mon, 31 Dec 2012 08:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.285 X-Spam-Level: X-Spam-Status: No, score=-1.285 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPIuU2Fcy3og for ; Mon, 31 Dec 2012 08:50:40 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0464A21F8734 for ; Mon, 31 Dec 2012 08:50:39 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:2773 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TpiZT-00010y-8y for rtcweb@ietf.org; Mon, 31 Dec 2012 10:50:39 -0600 Message-ID: <50E1C238.1080408@jesup.org> Date: Mon, 31 Dec 2012 11:50:00 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50D2CC6A.4090500@ericsson.com> <50DC7830.1010206@alvestrand.no> In-Reply-To: <50DC7830.1010206@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] 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, 31 Dec 2012 16:50:41 -0000 On 12/27/2012 11:32 AM, Harald Alvestrand wrote: > Speaking as an individual: > > I am putting my name on 2), because I believe RECOMMENDED is too > strong for secondary codecs. I am also voting for 2) for similar reasons (and in fact I'd probably vote against a "SHOULD" also). -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Mon Dec 31 08:55:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A3221F88C3 for ; Mon, 31 Dec 2012 08:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 kvOwu034uMBW for ; Mon, 31 Dec 2012 08:55:45 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A050B21F88A6 for ; Mon, 31 Dec 2012 08:55:45 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:2785 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TpieP-00026H-A8 for rtcweb@ietf.org; Mon, 31 Dec 2012 10:55:45 -0600 Message-ID: <50E1C36A.8000300@jesup.org> Date: Mon, 31 Dec 2012 11:55:06 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B06E211@ESESSMB209.ericsson.se> <50D4F06D.3020602@omnitor.se> In-Reply-To: <50D4F06D.3020602@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] 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: Mon, 31 Dec 2012 16:55:46 -0000 On 12/21/2012 6:27 PM, Gunnar Hellström wrote: > On 2012-12-21 16:40, Bernard Aboba wrote: >> 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. >> > This is sad. For good usability of video, maintained frame rate is > usually much more important than maintained spatial resolution. E.g. > for sign language or lip reading usage with a single person in image, > a frame rate under 20 fps introduces loss of language contents, and > requires the users to try to fill in the gaps by imagination, while > spatial resolution reduction down to QCIF causes much less harm to > language perception possibilities. Strong agreement. High (and consistent!) frame rate is critical to VRS and sign-language - and for hearing people, it 'feels' much more like talking to someone if the video framerate is kept >20 (and preferably >25), with perfect lip-sync. This is based on the experience I and Maire Reavy had at Worldgate, where we provided videophones for VRS usage. 30FPS QCIF works pretty well for sign-language, and better generally than 20FPS CIF, even though CIF is 4x the number of pixels. Note that there's no reason a browser in a mobile device couldn't maintain 30fps, and if congestion indicates it needs to reduce bandwidth too much for 'good quality' 30FPS, it can instead reduce the resolution. The only time I'd value resolution over framerate is when viewing graphics or the equivalent. SVC certainly isn't needed here for 1-1 communication; a main advantage of SVC is to allow a node in the network (i.e. conf. server/MCU) to subset down a stream for one recipient while providing higher-resolution streams to others while avoiding decode/re-encode on the server. Of course, this was the use-case that started this. In a corollary, frame rate should not drop when there's a lot of movement, or should only drop momentarily. (And I mean very momentarily, like dropping a single frame when there's a big jump in motion from the last frame, then resuming 30FPS at higher quantization or higher bitrate.) However, Christer's original question said: "However, the “local transcoding” alternative will consume lots of resources, and as far as I know none of the proposed MTI video codecs support SVC. " This is I believe is at least partially incorrect. From blog.webmproject.com, 1/27/2012, "VP8 Codec SDK "Duclair" Released": This release introduces substantial new VP8 encoder features that are especially useful for real-time use cases such as live streaming and videoconferencing. * Temporal scalability produces a video stream that can be decimated to different frame rates, with independent rate targeting for each substream. * Multiframe postprocessing can make visual quality more consistent in the presence of frames that are of substantially different quality than the surrounding frames, as in the temporal scalability case and in some forced keyframe scenarios. * Multiple-resolution encoding enables simultaneous encoding of the same content at different resolutions, resulting in much faster encoding than processing them separately. This is both multicast and temporal scalability. -- Randell Jesup randell-ietf@jesup.org From adam@nostrum.com Mon Dec 31 09:04:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F3021F84DB for ; Mon, 31 Dec 2012 09:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 tqlqqnKu9iI3 for ; Mon, 31 Dec 2012 09:04:58 -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 854BB21F8738 for ; Mon, 31 Dec 2012 09:04:51 -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 qBVH4nNL048267 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 31 Dec 2012 11:04:49 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50E1C5B1.3010603@nostrum.com> Date: Mon, 31 Dec 2012 11:04:49 -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: Randell Jesup References: <50D2CC6A.4090500@ericsson.com> <50DC7830.1010206@alvestrand.no> <50E1C238.1080408@jesup.org> In-Reply-To: <50E1C238.1080408@jesup.org> 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: Mon, 31 Dec 2012 17:04:59 -0000 On 12/31/12 10:50, Randell Jesup wrote: > On 12/27/2012 11:32 AM, Harald Alvestrand wrote: >> Speaking as an individual: >> >> I am putting my name on 2), because I believe RECOMMENDED is too >> strong for secondary codecs. > > I am also voting for 2) for similar reasons (and in fact I'd probably > vote against a "SHOULD" also). > FWIW, RFC 2119 defines these terms to mean exactly the same thing: 3. SHOULD This word, or the adjective "RECOMMENDED", mean... /a From bernard_aboba@hotmail.com Mon Dec 31 10:51:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A2721F8734 for ; Mon, 31 Dec 2012 10:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.022, 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 FZR0TXtvbF+M for ; Mon, 31 Dec 2012 10:51:39 -0800 (PST) Received: from blu0-omc4-s18.blu0.hotmail.com (blu0-omc4-s18.blu0.hotmail.com [65.55.111.157]) by ietfa.amsl.com (Postfix) with ESMTP id C620A21F8432 for ; Mon, 31 Dec 2012 10:51:39 -0800 (PST) Received: from BLU002-W228 ([65.55.111.137]) by blu0-omc4-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Dec 2012 10:51:38 -0800 X-EIP: [G1zHtAZYDXxDTSHFQuI8lQwPtnQxKRS4] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_1c536fad-6d03-4077-a5bc-8a2deeb4440b_" From: Bernard Aboba To: Randell Jesup , "rtcweb@ietf.org" Date: Mon, 31 Dec 2012 10:51:38 -0800 Importance: Normal In-Reply-To: <50E1C36A.8000300@jesup.org> References: <7594FB04B1934943A5C02806D1A2204B06E211@ESESSMB209.ericsson.se>, , <50D4F06D.3020602@omnitor.se>, <50E1C36A.8000300@jesup.org> MIME-Version: 1.0 X-OriginalArrivalTime: 31 Dec 2012 18:51:38.0714 (UTC) FILETIME=[DD8BCBA0:01CDE787] 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: Mon, 31 Dec 2012 18:51:40 -0000 --_1c536fad-6d03-4077-a5bc-8a2deeb4440b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Randell said:=20 > * Temporal scalability produces a video stream that can be > decimated to different frame rates=2C with independent rate > targeting for each substream. > * Multiframe postprocessing can make visual quality more > consistent in the presence of frames that are of substantially > different quality than the surrounding frames=2C as in the > temporal scalability case and in some forced keyframe scenarios. > * Multiple-resolution encoding enables simultaneous encoding of > the same content at different resolutions=2C resulting in much > faster encoding than processing them separately. >=20 > This is both multicast and temporal scalability. [BA] The above seems to suggest support for temporal=2C quality and spatial= scalability.=20 Did you really mean "multicast" (since that's out of scope of WebRTC)?=20 = --_1c536fad-6d03-4077-a5bc-8a2deeb4440b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Randell said:

>= =3B * Temporal scalability produces a video stream that can be
>= =3B decimated to different frame rates=2C with independent rate
= >=3B targeting for each substream.
>=3B * Multiframe p= ostprocessing can make visual quality more
>=3B consistent in = the presence of frames that are of substantially
>=3B differen= t quality than the surrounding frames=2C as in the
>=3B tempor= al scalability case and in some forced keyframe scenarios.
>=3B = * Multiple-resolution encoding enables simultaneous encoding of
>=3B = the same content at different resolutions=2C resulting in much
&g= t=3B faster encoding than processing them separately.
>=3B >=3B This is both multicast and temporal scalability.

[BA] The ab= ove seems to suggest support for temporal=2C quality and spatial scalabilit= y.
Did you really mean "multicast" (since that's out of scope of WebRTC= )?
= --_1c536fad-6d03-4077-a5bc-8a2deeb4440b_-- From randell-ietf@jesup.org Mon Dec 31 13:51:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C4A21F8737 for ; Mon, 31 Dec 2012 13:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 8vBSEk8jR002 for ; Mon, 31 Dec 2012 13:51:24 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4B721F8731 for ; Mon, 31 Dec 2012 13:51:19 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:3873 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TpnGM-000AGd-3b for rtcweb@ietf.org; Mon, 31 Dec 2012 15:51:14 -0600 Message-ID: <50E208AA.4090406@jesup.org> Date: Mon, 31 Dec 2012 16:50:34 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B06E211@ESESSMB209.ericsson.se>, , <50D4F06D.3020602@omnitor.se>, <50E1C36A.8000300@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] 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: Mon, 31 Dec 2012 21:51:34 -0000 On 12/31/2012 1:51 PM, Bernard Aboba wrote: > Randell said: > > > * Temporal scalability produces a video stream that can be > > decimated to different frame rates, with independent rate > > targeting for each substream. > > * Multiframe postprocessing can make visual quality more > > consistent in the presence of frames that are of substantially > > different quality than the surrounding frames, as in the > > temporal scalability case and in some forced keyframe scenarios. > > * Multiple-resolution encoding enables simultaneous encoding of > > the same content at different resolutions, resulting in much > > faster encoding than processing them separately. > > > > This is both multicast and temporal scalability. > > [BA] The above seems to suggest support for temporal, quality and > spatial scalability. > Did you really mean "multicast" (since that's out of scope of WebRTC)? I meant sending multiple streams at different resolutions at the same time (as opposed to SVC spacial enhancement layers). Overloaded terms. -- Randell Jesup randell-ietf@jesup.org From martin.thomson@gmail.com Mon Dec 31 15:20:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B0121F8455 for ; Mon, 31 Dec 2012 15:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.858 X-Spam-Level: X-Spam-Status: No, score=-4.858 tagged_above=-999 required=5 tests=[AWL=-1.260, 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 VlOAsG3ZoaVH for ; Mon, 31 Dec 2012 15:20:09 -0800 (PST) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0E05721F8443 for ; Mon, 31 Dec 2012 15:20:08 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id fk20so4447115lab.36 for ; Mon, 31 Dec 2012 15:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:importance:date:message-id:subject:to :content-type; bh=pXdbXRi8/h+zDpLa2zdj/txTkkUcpyDFmuYoIVRjSMU=; b=DYcueUCEPy1WfzSfRN2AbN9QJYZLCCegKwUkZa55lzKjdPx/UY4qrPZdKl3h155Cpg cK7n9OC9zZt9IOPTRAgcObnSy/TviYmvXOeBn/XRAc2eG2O8nted+ryz5DFgWNhJLMcV RtCJKE4sx1jLrw3r4KZhjdyV/dAP3XvehICtzzH/pompLI9hHNnaFAeij9XPPdlPvd7U OkjVRE+Ol+793jwgRDq1hHJPY3vfWshlAbzC+AuwUwvdP/k4D5As373hhLJMbIWxI40A AKQljAVuAL5B8yWpVPOAYTUsTOB6/DiSJFYR9X5Gq66p8Q464m4W44y2hwRHNkiY7Fjb DwNg== Received: by 10.112.44.161 with SMTP id f1mr16735655lbm.29.1356996007920; Mon, 31 Dec 2012 15:20:07 -0800 (PST) MIME-Version: 1.0 From: Martin Thomson Importance: Normal Date: Mon, 31 Dec 2012 23:20:05 +0000 Message-ID: <-3846863114415000908@unknownmsgid> To: "rtcweb@ietf.org" , Randell Jesup Content-Type: multipart/alternative; boundary=bcaec554d1fe0384c104d22e4102 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: Mon, 31 Dec 2012 23:20:09 -0000 --bcaec554d1fe0384c104d22e4102 Content-Type: text/plain; charset=UTF-8 Oh. Simulcast. *From:* Randell Jesup randell-ietf@jesup.org I meant sending multiple streams at different resolutions at the same time (as opposed to SVC spacial enhancement layers). Overloaded terms. --bcaec554d1fe0384c104d22e4102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oh. Simulcast.
=C2=A0
From= :=C2=A0Randell Jesup ran= dell-ietf@jesup.org

I meant sending multiple streams at different resolutions at the same time = (as opposed to SVC spacial enhancement layers).

Overloaded terms.

--bcaec554d1fe0384c104d22e4102-- From bernard_aboba@hotmail.com Mon Dec 31 15:44:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9B021F8737 for ; Mon, 31 Dec 2012 15:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.881 X-Spam-Level: X-Spam-Status: No, score=-101.881 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG0iMSIOe4Lp for ; Mon, 31 Dec 2012 15:44:46 -0800 (PST) Received: from blu0-omc3-s13.blu0.hotmail.com (blu0-omc3-s13.blu0.hotmail.com [65.55.116.88]) by ietfa.amsl.com (Postfix) with ESMTP id 6099B21F8964 for ; Mon, 31 Dec 2012 15:44:46 -0800 (PST) Received: from BLU404-EAS292 ([65.55.116.72]) by blu0-omc3-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Dec 2012 15:44:31 -0800 X-EIP: [mzrqpasibVJvxJugO9IQ59QjGW3jUMOb] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/related; boundary="_752d70a9-7116-4541-80f2-46e4a8a89564_" References: <-3846863114415000908@unknownmsgid> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <-3846863114415000908@unknownmsgid> Date: Mon, 31 Dec 2012 15:45:22 -0800 To: Randell Jesup X-OriginalArrivalTime: 31 Dec 2012 23:44:31.0388 (UTC) FILETIME=[C7AD0DC0:01CDE7B0] 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: Mon, 31 Dec 2012 23:44:47 -0000 --_752d70a9-7116-4541-80f2-46e4a8a89564_ Content-Type: multipart/alternative; boundary="Apple-Mail-9EAF9910-7426-4B28-A244-A04B1B9D2455" Content-Transfer-Encoding: 7bit --Apple-Mail-9EAF9910-7426-4B28-A244-A04B1B9D2455 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Out of curiosity, is there a proposal for how to signal this in VP8? (E.g. R= FC 5888 + something akin to draft-westerlund-avtcore-multistream-and-simulca= st) On Dec 31, 2012, at 15:20, "Martin Thomson" wrote= : > Oh. Simulcast. > =20 > From: Randell Jesup randell-ietf@jesup.org >=20 > I meant sending multiple streams at different resolutions at the same time= (as opposed to SVC spacial enhancement layers). >=20 > Overloaded terms. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-9EAF9910-7426-4B28-A244-A04B1B9D2455 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit
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)

On Dec 31, 2012, at 15:20, "Martin Thomson" <martin.thomson@gmail.com> wrote:

Oh. Simulcast.
 
From: Randell Jesup randell-ietf@jesup.org

I meant sending multiple streams at different resolutions at the same time (as opposed to SVC spacial enhancement layers).

Overloaded terms.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--Apple-Mail-9EAF9910-7426-4B28-A244-A04B1B9D2455-- --_752d70a9-7116-4541-80f2-46e4a8a89564_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_752d70a9-7116-4541-80f2-46e4a8a89564_--