From wwwrun@core3.amsl.com Mon Apr 4 08:47:41 2011 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id DF7BE3A681F; Mon, 4 Apr 2011 08:47:40 -0700 (PDT) From: IETF Secretariat To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110404154740.DF7BE3A681F@core3.amsl.com> Date: Mon, 4 Apr 2011 08:47:40 -0700 (PDT) Cc: rtcweb@ietf.org Subject: [rtcweb] New Non-WG Mailing List: rtcweb -- Real-Time Communication in WEB-browsers (proposed) working group list X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-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, 04 Apr 2011 15:47:41 -0000 A new IETF non-working group email list has been created. List address: rtcweb@ietf.org Archive: http://www.ietf.org/mail-archive/web/rtcweb/ To subscribe: https://www.ietf.org/mailman/listinfo/rtcweb Description: This proposed RTCWeb working group is discussing direct interactive rich communication between two peers' web-browsers, enabling audio, video, collaboration, games, etc. For additional information, please contact the list administrators. From ietf@meetecho.com Tue Apr 5 09:36:34 2011 Return-Path: X-Original-To: rtcweb@core3.amsl.com Delivered-To: rtcweb@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5EB63A6969 for ; Tue, 5 Apr 2011 09:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZC-B14gzALzx for ; Tue, 5 Apr 2011 09:36:34 -0700 (PDT) Received: from smtpw1.aruba.it (smtpa1.aruba.it [62.149.128.210]) by core3.amsl.com (Postfix) with SMTP id 70DC33A6965 for ; Tue, 5 Apr 2011 09:36:33 -0700 (PDT) Received: (qmail 16161 invoked by uid 89); 5 Apr 2011 16:38:15 -0000 Received: from unknown (HELO aruba.it) (62.149.158.91) by smtpw1.ad.aruba.it with SMTP; 5 Apr 2011 16:38:15 -0000 Date: Tue, 5 Apr 2011 18:38:15 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: multipart/alternative; boundary="_=__=_XaM3_.1302021495.2A.350528.42.28319.52.42.007.1707768203" From: "ietf@meetecho.com" To: rtcweb@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 143.225.229.199 X-Spam-Rating: smtpw1.ad.aruba.it 1.6.2 0/1000/N Subject: [rtcweb] RTCWEB recording available -- update X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 16:36:34 -0000 --_=__=_XaM3_.1302021495.2A.350528.42.28319.52.42.007.1707768203 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all,the full recording (synchronized video, audio, slides and jabber= room) of the RTCWEB BOF at IETF80 is available at the following URL:http= ://ietf.conf.meetecho.comYou can either choose to watch it online (two di= fferent approaches are available) or download and replay it whenever you = want.In case of problems with the playout, just drop an e-mail to ietf-su= pport@meetecho.com.For the chair(s): please feel free to put the link to = the recording in the minutes, if you think this might be useful.Cheers,th= e Meetecho Team --_=__=_XaM3_.1302021495.2A.350528.42.28319.52.42.007.1707768203 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A
=0A
Dear all,

the full recording (synchronized v= ideo, audio, slides and jabber room) of the RTCWEB BOF at IETF80 is avail= able at the following URL:
http://ietf.conf.meetecho.com

You ca= n either choose to watch it online (two different approaches are availabl= e) or download and replay it whenever you want.

In case of problem= s with the playout, just drop an e-mail to ietf-support@meetecho.com.
=
For the chair(s): please feel free to put the link to the recording i= n the minutes, if you think this might be useful.

Cheers,
the M= eetecho Team
=0A
=0A --_=__=_XaM3_.1302021495.2A.350528.42.28319.52.42.007.1707768203-- From harald@alvestrand.no Fri Apr 8 04:54:21 2011 Return-Path: X-Original-To: rtcweb@core3.amsl.com Delivered-To: rtcweb@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DFE53A6953 for ; Fri, 8 Apr 2011 04:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSuX1QXQZ0w1 for ; Fri, 8 Apr 2011 04:54:21 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id CFB013A6903 for ; Fri, 8 Apr 2011 04:54:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3FABF39E08B for ; Fri, 8 Apr 2011 13:55:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOq8KAs8xzNz for ; Fri, 8 Apr 2011 13:55:23 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id AA15139E082 for ; Fri, 8 Apr 2011 13:55:23 +0200 (CEST) Message-ID: <4D9EF7D3.1040806@alvestrand.no> Date: Fri, 08 Apr 2011 13:56:03 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Welcome to a new mailing list X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-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, 08 Apr 2011 11:54:21 -0000 There's always a quiet period when changing mailing lists. Therefore, someone should send out a message that's provocative enough to get a few responses, so that everyone's filters get tuned.... here's my try. Controversial things that need more discussions, culled from Friday's notes: - Non-media data: RTP, UDP-without-RTP, TCP, or "something else"? Congestion control is obviously needed - both for this and for media, naturally. - Mandatory to implement codecs: How can we figure out how to get the arguments documented, and make the call on whether to have them or not? - Interim meeting: When, with whom, and using what technology? Enough ... that should set a few tongues wagging.... From tim@phonefromhere.com Fri Apr 8 05:57:10 2011 Return-Path: X-Original-To: rtcweb@core3.amsl.com Delivered-To: rtcweb@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BF7128C0F6 for ; Fri, 8 Apr 2011 05:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzSYMzZPQpDj for ; Fri, 8 Apr 2011 05:57:09 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by core3.amsl.com (Postfix) with ESMTP id C18B228C0D9 for ; Fri, 8 Apr 2011 05:57:08 -0700 (PDT) Received: from [192.168.0.16] (87-194-8-115.bethere.co.uk [87.194.8.115]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 6CA2537A8FC for ; Fri, 8 Apr 2011 14:08:53 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Tim Panton In-Reply-To: <4D9EF7D3.1040806@alvestrand.no> Date: Fri, 8 Apr 2011 13:58:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <85818664-860D-4B9F-90BD-334ACBADF6B6@phonefromhere.com> References: <4D9EF7D3.1040806@alvestrand.no> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [rtcweb] Welcome to a new mailing list X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-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, 08 Apr 2011 12:57:10 -0000 On 8 Apr 2011, at 12:56, Harald Alvestrand wrote: > There's always a quiet period when changing mailing lists. > Therefore, someone should send out a message that's provocative enough = to get a few responses, so that everyone's filters get tuned.... here's = my try. >=20 > Controversial things that need more discussions, culled from Friday's = notes: >=20 > - Non-media data: RTP, UDP-without-RTP, TCP, or "something else"? > Congestion control is obviously needed - both for this and for media, = naturally. >=20 > - Mandatory to implement codecs: How can we figure out how to get the = arguments documented, and make the call on whether to have them or not? >=20 > - Interim meeting: > When, with whom, and using what technology? >=20 > Enough ... that should set a few tongues wagging.... >=20 > ________ Ok, I'll bite :-) On the non-media data, I think it is somewhere between essential and = _very_ useful. Our experience of this is running a small java applet softphone that = implements IAX. We've been using the TEXT frame type to send data between the pbx and = the browser. IAX's TEXT (and in general non-media) frames are small (optionally = encrypted), sequenced=20 and reliable, but carried over UDP. Typically it is notification of who is speaking in a conference call, a = slide change, transcription text or IVR prompts in text form. So the fact that it is sent directly and = not polled is essential. Mostly we send JSON objects, and have the page's javascript interpret = them as it sees fit. I'm not saying we should use IAX, but these properties of the TEXT frame = are very useful=20 in this context, so we could aim to reproduce those properties in any = solution. There are mechanisms for passing messages from one browser context to = another, see = http://www.ajaxlines.com/ajax/stuff/article/using_html_postmessage.php - = we should probably be adopting that as an interface. On the codec front, we've found SILK's adaptive nature really valuable = in situations where a TDM codec might fail - (e.g. user on the edge of a wifi network with high packet = loss and variable bandwidth), so we should aim to include a codec of that kind. Tim. From mary.ietf.barnes@gmail.com Fri Apr 8 06:22:40 2011 Return-Path: X-Original-To: rtcweb@core3.amsl.com Delivered-To: rtcweb@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E1B28C11C for ; Fri, 8 Apr 2011 06:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.365 X-Spam-Level: X-Spam-Status: No, score=-103.365 tagged_above=-999 required=5 tests=[AWL=0.232, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dycrFjUTGpEm for ; Fri, 8 Apr 2011 06:22:36 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id AE02C28C106 for ; Fri, 8 Apr 2011 06:22:36 -0700 (PDT) Received: by vws12 with SMTP id 12so3310311vws.31 for ; Fri, 08 Apr 2011 06:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9b9rfr4hqQdCKNxsdjq95+sOsDuaj2qBsU6hKVU8e7A=; b=fyzFwJI7pnwZhUQ1krXW+MEtXw6TtpT+bZaWcfVxX6tJ/EpIpOJ0o/zqT/JLRJAwYe f2h2K8CulNWHa/giWUt/eFk/zGWyO+FtBV394T+e0MSKbmmrqRNPyaTB1zgfrAeB7sDF 2XCpkh9C6KbBwPjFJ6jtLVnwcgEh6Yu7APO/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qRC9i/YymfMo/cXcOqhBXTaWp8/eIQNAH/8bU5yqBlstkesU/U15Vrt8wMAkU4Z59k 6N8/fLcwjZT6NELVKGNakyAEZPWvezumj93IrRWtkN5UFtjpBZaWysP6pIS41eNL4XV3 mrQq0KtyfErf8jQGTT5VUbrIa84FUyMVLxYME= MIME-Version: 1.0 Received: by 10.52.90.10 with SMTP id bs10mr3168730vdb.23.1302269061715; Fri, 08 Apr 2011 06:24:21 -0700 (PDT) Received: by 10.52.167.137 with HTTP; Fri, 8 Apr 2011 06:24:21 -0700 (PDT) In-Reply-To: <4D9EF7D3.1040806@alvestrand.no> References: <4D9EF7D3.1040806@alvestrand.no> Date: Fri, 8 Apr 2011 08:24:21 -0500 Message-ID: From: Mary Barnes To: Harald Alvestrand Content-Type: multipart/alternative; boundary=bcaec50165b1d3575b04a068241a Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Welcome to a new mailing list X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-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, 08 Apr 2011 13:22:40 -0000 --bcaec50165b1d3575b04a068241a Content-Type: text/plain; charset=ISO-8859-1 One suggestion I have for the group is to please start separate threads on each of the items as that will make it MUCH easier to track the discussion. In the spirit of this suggestion, I'll post my comments on the codec issue separately. Regards, Mary. On Fri, Apr 8, 2011 at 6:56 AM, Harald Alvestrand wrote: > There's always a quiet period when changing mailing lists. > Therefore, someone should send out a message that's provocative enough to > get a few responses, so that everyone's filters get tuned.... here's my try. > > Controversial things that need more discussions, culled from Friday's > notes: > > - Non-media data: RTP, UDP-without-RTP, TCP, or "something else"? > Congestion control is obviously needed - both for this and for media, > naturally. > > - Mandatory to implement codecs: How can we figure out how to get the > arguments documented, and make the call on whether to have them or not? > > - Interim meeting: > When, with whom, and using what technology? > > Enough ... that should set a few tongues wagging.... > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec50165b1d3575b04a068241a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One suggestion I have for the group is to please start separate threads on = each of the items as that will make it MUCH easier to track the discussion.= =A0

In the spirit of this suggestion, I'll post my c= omments on the codec issue separately.=A0

Regards,
Mary.


On Fri, Apr 8, 2011 at 6:56 AM,= Harald Alvestrand <harald@alvestrand.no> wrote:
There's always a quiet period when chan= ging mailing lists.
Therefore, someone should send out a message that's provocative enough = to get a few responses, so that everyone's filters get tuned.... here&#= 39;s my try.

Controversial things that need more discussions, culled from Friday's n= otes:

- Non-media data: RTP, UDP-without-RTP, TCP, or "something else"?=
=A0Congestion control is obviously needed - both for this and for media, n= aturally.

- Mandatory to implement codecs: How can we figure out how to get the argum= ents documented, and make the call on whether to have them or not?

- Interim meeting:
When, with whom, and using what technology?

Enough ... that should set a few tongues wagging....

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

--bcaec50165b1d3575b04a068241a-- From mary.ietf.barnes@gmail.com Fri Apr 8 06:24:52 2011 Return-Path: X-Original-To: rtcweb@core3.amsl.com Delivered-To: rtcweb@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2E9028C11C for ; Fri, 8 Apr 2011 06:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[AWL=0.227, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rczhToH5pu-Y for ; Fri, 8 Apr 2011 06:24:52 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 0E27128C106 for ; Fri, 8 Apr 2011 06:24:51 -0700 (PDT) Received: by vws12 with SMTP id 12so3312190vws.31 for ; Fri, 08 Apr 2011 06:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=XZ83dZRLYIgX9HCcGKKioa8yi0+aWLm/y8059/8thO4=; b=w/ICF1fJj+CqzkmB3OE6CJ11HuoOICH6nM5lupFcBxj1PGOXZSb+jhAYY6ncIVPXgD zw6b31KdAP1lY8jwHnB/tdWCCZZ1ykRWrJTPf0jtUlrBP2U6q72ssG3s7apxxw1gu1L/ EZ+qDHshxqQyojFTpabdCKOMDX0T6aKOK+5qQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=i7CCptafyA0n1n9KYIOIw6MuYH4kcxT9MAELzDlRWM7vXavGHpHCA9z65vy+35GfGz Zag604AK6Kp0FzamIrMc0vwCiuE07dtqg1CaCxm0/kT8Fc/Irzn8goptZOqX7hGFXXWV RmOWPOt3S2zeNMUDyixCvoX0mD0t8l0CV0nc4= MIME-Version: 1.0 Received: by 10.52.0.236 with SMTP id 12mr497236vdh.223.1302269197215; Fri, 08 Apr 2011 06:26:37 -0700 (PDT) Received: by 10.52.167.137 with HTTP; Fri, 8 Apr 2011 06:26:37 -0700 (PDT) Date: Fri, 8 Apr 2011 08:26:37 -0500 Message-ID: From: Mary Barnes To: Harald Alvestrand Content-Type: multipart/alternative; boundary=20cf30434702e6e9c204a0682c12 Cc: rtcweb@ietf.org Subject: [rtcweb] Mandatory to implement codecs? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-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, 08 Apr 2011 13:24:53 -0000 --20cf30434702e6e9c204a0682c12 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 8, 2011 at 6:56 AM, Harald Alvestrand wrote: > - Mandatory to implement codecs: How can we figure out how to get the > arguments documented, and make the call on whether to have them or not? > [MB] Given the amount of time spent discussing codecs in the adhoc, I would suggest that the group focus on the other issues for the time being, so that some progress can be made initially and then revisit the codec issue once some of the other decisions are more firm. [/MB] Regards, Mary. --20cf30434702e6e9c204a0682c12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Apr 8, 2011 at 6:56 AM, Harald Alvestrand <harald@alvestrand.no> wr= ote:
=A0
- Mandatory to implement codecs: How can we figure out how to get the argum= ents documented, and make the call on whether to have them or not?

[MB] Given the amount of time spent discussing = codecs in the adhoc, I would suggest that the group focus on the other issu= es for the time being, so that some progress can be made initially and then= revisit the codec issue once some of the other decisions are more firm. [/= MB]

Regards,
Mary.=A0
--20cf30434702e6e9c204a0682c12-- From lorenzo@meetecho.com Fri Apr 8 06:27:05 2011 Return-Path: X-Original-To: rtcweb@core3.amsl.com Delivered-To: rtcweb@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 245CC28C11C for ; Fri, 8 Apr 2011 06:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.448 X-Spam-Level: X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxDQV391po1a for ; Fri, 8 Apr 2011 06:27:04 -0700 (PDT) Received: from smtplq02.aruba.it (smtplq-out15.aruba.it [62.149.158.35]) by core3.amsl.com (Postfix) with SMTP id 7368228C106 for ; Fri, 8 Apr 2011 06:27:03 -0700 (PDT) Received: (qmail 30097 invoked by uid 89); 8 Apr 2011 13:28:45 -0000 Received: from unknown (HELO smtp2.aruba.it) (62.149.158.222) by smtplq02.aruba.it with SMTP; 8 Apr 2011 13:28:45 -0000 Received: (qmail 2271 invoked by uid 89); 8 Apr 2011 13:28:45 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.166) by smtp2.ad.aruba.it with SMTP; 8 Apr 2011 13:28:45 -0000 Date: Fri, 8 Apr 2011 15:24:01 +0200 From: Lorenzo Miniero To: Harald Alvestrand Message-ID: <20110408152401.0aff9e54@lminiero-acer> In-Reply-To: <4D9EF7D3.1040806@alvestrand.no> References: <4D9EF7D3.1040806@alvestrand.no> Organization: Meetecho X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp2.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Welcome to a new mailing list X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-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, 08 Apr 2011 13:27:05 -0000 Hi Harald and all, a few comments inline. Il giorno Fri, 08 Apr 2011 13:56:03 +0200 Harald Alvestrand ha scritto: > There's always a quiet period when changing mailing lists. > Therefore, someone should send out a message that's provocative > enough to get a few responses, so that everyone's filters get > tuned.... here's my try. > > Controversial things that need more discussions, culled from Friday's > notes: > > - Non-media data: RTP, UDP-without-RTP, TCP, or "something else"? > Congestion control is obviously needed - both for this and for > media, naturally. > I guess that depends on what non-media is. During the RTCWEB BOF we shared the session using a web-based interface (some in this list may even have tried it), and it involved both media (audio and video) and what we may call non-media (the jabber room, the slides). All this non-media interaction, which was mostly based on XMPP and a bit of HTTP, was just made available as a JavaScript API for the webpage to exploit: asynchronous interaction was achieved the usual way (one or more AJAX channels to send data, a long poll AJAX channel to get updates) which I guess is the simpliest approach, from a functional point of view, with respect to this kind of non-media. Meaning I wouldn't go for a new protocol/solution or force RTP for that as well, if avoidable. For media itself, the approach we used so far was using another JavaScript API to handle the SIP negotiation (masking all the SIP details), and then relying on a Java applet to handle the RTP frames and the encoding: I guess that the ability to handle also this last frame of the picture within the browser would be the most important outcome of the WG. What may also be interesting would be debating whether or not an HTTP fallback (or something similar) should be considered for RTP in constrained scenarios, as I seem to recall having been mentioned during the BOF as well. > - Mandatory to implement codecs: How can we figure out how to get the > arguments documented, and make the call on whether to have them or > not? > This is likely to become a hot debate: HTML5 video has thought us there's no easy way out. As someone already told during the BOF, I'd go for a very simple (even if not optimal) common ground as mandatory, and leave advanced codec choices up to developers, rather than saying "this is how you can negotiate stuff, which stuff is up to you". I have no strong sentiment towards any specific choice, but I'd go for something that's not (too?) closed. Forcing AMR and H.264 as mandatory, for example, would very likely cut a lot of people out of the loop, which I don't think is what anybody wants. > - Interim meeting: > When, with whom, and using what technology? > If a virtual interim meeting is to be setup, you may count on us to host and support it should you think it could be useful. > Enough ... that should set a few tongues wagging.... > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb L. -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From mary.ietf.barnes@gmail.com Fri Apr 8 06:39:17 2011 Return-Path: X-Original-To: rtcweb@core3.amsl.com Delivered-To: rtcweb@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ADF328C120 for ; Fri, 8 Apr 2011 06:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.877 X-Spam-Level: X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFDx5S81fHRP for ; Fri, 8 Apr 2011 06:39:16 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 2FF8528C118 for ; Fri, 8 Apr 2011 06:39:16 -0700 (PDT) Received: by vxg33 with SMTP id 33so3298535vxg.31 for ; Fri, 08 Apr 2011 06:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=014dNs9MVswYml4tcWC+i4B1aX8h4Az6c9WqqqL4Izs=; b=FX+Rn9ef0fdCX26kXsKrbQf+0u3ZVfygV7KY1TCryO3C8MQg8P89Rphf8r06mfeJXZ XdvyqWkCzLDdvO7v3KmB8GAvr+AAyaMLQxfNZ7qma2GIG+D6JxD1YTtxHB2bOcmbbGu3 044UT1X7poq+61EXCpSM9OWzwtwsGyWGpvGy0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=QLcuauYGPfUxjA4axct8uN5j3z0KiFvP+a2QUwosWU1Ab+uKVp52BxFEaLLj+QhcC7 vNBiiW5rsNEeyuNDWRmf7KR3RNryRptCv6a7ddvVvgpeNryeLd0on7SBYPpI0CFSPVs/ 1GXq4l/jVO+ra3y+VjfNEhbVIBA/ud+sA3wGw= MIME-Version: 1.0 Received: by 10.52.172.34 with SMTP id az2mr3265390vdc.143.1302270061309; Fri, 08 Apr 2011 06:41:01 -0700 (PDT) Received: by 10.52.167.137 with HTTP; Fri, 8 Apr 2011 06:41:01 -0700 (PDT) Date: Fri, 8 Apr 2011 08:41:01 -0500 Message-ID: From: Mary Barnes To: Harald Alvestrand Content-Type: multipart/alternative; boundary=bcaec53f95ef67f20e04a0686028 Cc: rtcweb@ietf.org Subject: [rtcweb] Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-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, 08 Apr 2011 13:39:17 -0000 --bcaec53f95ef67f20e04a0686028 Content-Type: text/plain; charset=ISO-8859-1 > > > > - Interim meeting: > When, with whom, and using what technology? > [MB] I would suggest late May or early June would be a good time. I had suggested to the RAI area that folks provide the details for the Interims on the RAI area wiki as I know there are several groups planning interims and many of us need to participate in almost all of those: http://trac.tools.ietf.org/area/rai/trac/wiki I will note that not all the WG chairs have been adding the information, but it is really helpful. I add it for the WGs that I'm subscribed to when I happen to notice (which is why I suggested the RAI area do this in the first place because I was having difficulty keeping track of all the meetings - there were at least 6 interim meetings in the RAI area between IETF-79 and IETF-80). As far as technology, I thought Meetecho worked extremely well at IETF-80, although I'm not sure how well it would work with alot of geographic separation. The alternative of course is Webex. And, as usual, I suggest setting up a doodle poll to find the best date/time - it's good to include a link to that with a deadline in the wiki, as well. [/MB] Regards, Mary. --bcaec53f95ef67f20e04a0686028 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


- Interim meeting:
When, with whom, and using what technology?
[MB] I wou= ld suggest late May or early June would be a good time. =A0I had suggested = to the RAI area that folks provide the details for the Interims on the RAI = area wiki as I know there are several groups planning interims and many of = us need to participate in almost all of those: =A0

I will note = that not all the WG chairs have been adding the information, but it is real= ly helpful. =A0I add it for the WGs that I'm subscribed to when I happe= n to notice (which is why I suggested the RAI area do this in the first pla= ce because I was having difficulty keeping track of all the meetings - ther= e were at least 6 interim meetings in the RAI area between IETF-79 and IETF= -80). =A0

As far as technology, I thought Meetecho worked extreme= ly well at IETF-80, although I'm not sure how well it would work with a= lot of geographic separation. =A0The alternative of course is Webex.=A0

And, as usual, I suggest setting up a doodle poll to fi= nd the best date/time - it's good to include a link to that with a dead= line in the wiki, as well.=A0
[/MB]

Rega= rds,
Mary.
--bcaec53f95ef67f20e04a0686028-- From singer@apple.com Fri Apr 8 11:17:18 2011 Return-Path: X-Original-To: rtcweb@core3.amsl.com Delivered-To: rtcweb@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F45E3A6A17 for ; Fri, 8 Apr 2011 11:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPuKSv+RQtki for ; Fri, 8 Apr 2011 11:17:18 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by core3.amsl.com (Postfix) with ESMTP id 2329B3A6A07 for ; Fri, 8 Apr 2011 11:17:18 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJC003VZIOT6K61@mail-out.apple.com> for rtcweb@ietf.org; Fri, 08 Apr 2011 11:19:03 -0700 (PDT) X-AuditID: 11807134-b7c8cae000005108-0d-4d9f5197d73f Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by relay14.apple.com (Apple SCV relay) with SMTP id D5.23.20744.7915F9D4; Fri, 08 Apr 2011 11:19:03 -0700 (PDT) From: David Singer In-reply-to: <4D9EF7D3.1040806@alvestrand.no> Date: Fri, 08 Apr 2011 11:19:02 -0700 Message-id: References: <4D9EF7D3.1040806@alvestrand.no> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] non-media data X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-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, 08 Apr 2011 18:17:18 -0000 On Apr 8, 2011, at 4:56 , Harald Alvestrand wrote: > > - Non-media data: RTP, UDP-without-RTP, TCP, or "something else"? > Congestion control is obviously needed - both for this and for media, naturally. > My feeling is that we should not forget we're designing something to sit in a browser or browser-like context. We *have* text chat tools, file upload and download tools, and so on, today, working in browsers. Yes, they typically go through a server, and going point to point might be an optimization. But that's the rub; I don't think we should spend a lot of time optimizing tools that are ancillary to the core problem of doing real-time a/v between two users. If someone wants to start a group looking at real-time point-to-point text chat, well, OK, but I think it's a distraction for us, at least initially. David Singer Multimedia and Software Standards, Apple Inc. From john.elwell@siemens-enterprise.com Tue Apr 12 00:19:56 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 359D1E077A for ; Tue, 12 Apr 2011 00:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.631 X-Spam-Level: X-Spam-Status: No, score=-104.631 tagged_above=-999 required=5 tests=[AWL=1.968, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxF+ayP47gdR for ; Tue, 12 Apr 2011 00:19:55 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfc.amsl.com (Postfix) with SMTP id 48D45E0768 for ; Tue, 12 Apr 2011 00:19:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1302592791!4890808!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 1525 invoked from network); 12 Apr 2011 07:19:51 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-9.tower-182.messagelabs.com with SMTP; 12 Apr 2011 07:19:51 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 7B07223F03DB; Tue, 12 Apr 2011 09:19:51 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 12 Apr 2011 09:19:51 +0200 From: "Elwell, John" To: David Singer , "rtcweb@ietf.org" Date: Tue, 12 Apr 2011 09:19:49 +0200 Thread-Topic: [rtcweb] non-media data Thread-Index: Acv2GXME7jnL7kTyS92/G7n3ZU+lVACyE2sg Message-ID: References: <4D9EF7D3.1040806@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] non-media data X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 07:19:56 -0000 It is always good to try to limit scope, and I think this is indeed a case = where we can useful limit scope to RTP-based media (audio, video, real-time= text...). John =20 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of David Singer > Sent: 08 April 2011 19:19 > To: rtcweb@ietf.org > Subject: [rtcweb] non-media data >=20 >=20 > On Apr 8, 2011, at 4:56 , Harald Alvestrand wrote: >=20 > >=20 > > - Non-media data: RTP, UDP-without-RTP, TCP, or "something else"? > > Congestion control is obviously needed - both for this and=20 > for media, naturally. > >=20 >=20 > My feeling is that we should not forget we're designing=20 > something to sit in a browser or browser-like context. We=20 > *have* text chat tools, file upload and download tools, and=20 > so on, today, working in browsers. Yes, they typically go=20 > through a server, and going point to point might be an=20 > optimization. But that's the rub; I don't think we should=20 > spend a lot of time optimizing tools that are ancillary to=20 > the core problem of doing real-time a/v between two users. If=20 > someone wants to start a group looking at real-time=20 > point-to-point text chat, well, OK, but I think it's a=20 > distraction for us, at least initially. >=20 > David Singer > Multimedia and Software Standards, Apple Inc. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From tim@phonefromhere.com Tue Apr 12 01:40:23 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EFBAFE0663 for ; Tue, 12 Apr 2011 01:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRm0Tst2JoK6 for ; Tue, 12 Apr 2011 01:40:22 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfc.amsl.com (Postfix) with ESMTP id 0F20BE0613 for ; Tue, 12 Apr 2011 01:40:22 -0700 (PDT) Received: from [192.168.0.16] (87-194-8-115.bethere.co.uk [87.194.8.115]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id A979537A8FC; Tue, 12 Apr 2011 09:50:20 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: Date: Tue, 12 Apr 2011 09:40:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1D64F821-8D2B-4983-9989-F3EE076583E3@phonefromhere.com> References: <4D9EF7D3.1040806@alvestrand.no> To: "Elwell, John" X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] non-media data X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 08:40:23 -0000 Although we should aim to limit scope, it is also a good plan to listen = to experience in the field. Our experience is that direct, reliable, sequenced transmission of small = messages between=20 endpoints hugely adds to the value of a web-embedded RTC component. Typically these messages are intimately tied to events in the media = engine (change of speaker, end of message playback, transcription or recording available). (dynamic = media meta-data if you like) They are used to change the visual state of the web page (via = javascript) so that (for example) the=20 web displayed IVR prompts stay in sync with the audio. Whilst all of these are achievable via a more circuitous route = (mediaserver->signalingserver->webserver->long poll-> browser) the added latency will make the visual changes lag the audio which = undermines the user experience. The value in RTC-web isn't the realtime audio/video itself, it's the = fact that it is an integral part of the web-page, that integration is aided by non-media data. Tim. On 12 Apr 2011, at 08:19, Elwell, John wrote: > It is always good to try to limit scope, and I think this is indeed a = case where we can useful limit scope to RTP-based media (audio, video, = real-time text...). >=20 > John >=20 >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org=20 >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of David Singer >> Sent: 08 April 2011 19:19 >> To: rtcweb@ietf.org >> Subject: [rtcweb] non-media data >>=20 >>=20 >> On Apr 8, 2011, at 4:56 , Harald Alvestrand wrote: >>=20 >>>=20 >>> - Non-media data: RTP, UDP-without-RTP, TCP, or "something else"? >>> Congestion control is obviously needed - both for this and=20 >> for media, naturally. >>>=20 >>=20 >> My feeling is that we should not forget we're designing=20 >> something to sit in a browser or browser-like context. We=20 >> *have* text chat tools, file upload and download tools, and=20 >> so on, today, working in browsers. Yes, they typically go=20 >> through a server, and going point to point might be an=20 >> optimization. But that's the rub; I don't think we should=20 >> spend a lot of time optimizing tools that are ancillary to=20 >> the core problem of doing real-time a/v between two users. If=20 >> someone wants to start a group looking at real-time=20 >> point-to-point text chat, well, OK, but I think it's a=20 >> distraction for us, at least initially. >>=20 >> David Singer >> Multimedia and Software Standards, Apple Inc. >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Tue Apr 12 05:29:16 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0D8C5E07BB for ; Tue, 12 Apr 2011 05:29:16 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci3eDx4YyDsj for ; Tue, 12 Apr 2011 05:29:14 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfc.amsl.com (Postfix) with ESMTP id 408BFE066B for ; Tue, 12 Apr 2011 05:29:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C104239E15D; Tue, 12 Apr 2011 14:28:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zACE+lvSnBRq; Tue, 12 Apr 2011 14:28:30 +0200 (CEST) Received: from [172.16.49.75] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 7202039E113; Tue, 12 Apr 2011 14:28:29 +0200 (CEST) Message-ID: <4DA44596.3@alvestrand.no> Date: Tue, 12 Apr 2011 14:29:10 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: "rtc-web@alvestrand.no" , rtcweb@ietf.org Content-Type: multipart/alternative; boundary="------------080005070907060009030808" Subject: [rtcweb] Fwd: W3C mailing-list [was Re: Updated W3C draft charter for Web RTC WG] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 12:29:16 -0000 This is a multi-part message in MIME format. --------------080005070907060009030808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is to be the official public list of the (still in-formation) W3C WG for WebRTC. Welcome! Harald -------- Original Message -------- Subject: W3C mailing-list [was Re: Updated W3C draft charter for Web RTC WG] Date: Tue, 12 Apr 2011 08:48:09 +0200 From: Francois Daoust To: Harald Alvestrand Hi Harald, The public-webrtc@w3.org mailing-list is up and running. To subscribe to the mailing-list, one needs to send an email to public-webrtc-request@w3.org with subject "subscribe", or click on the "subscribe to this list" option on the archives page. The archives are available at: http://lists.w3.org/Archives/Public/public-webrtc/ Francois. On 04/07/2011 11:27 AM, Francois Daoust wrote: > On 04/07/2011 10:50 AM, Harald Alvestrand wrote: >> Francios, >> >> a) waiting for anything from me? > > No, I'm waiting for replies from reviewers to my own replies [1] before I can get back to W3C management with a disposition of comments to ask for their formal approval of the changes and chairs nomination. > > David Baron's already replied that he's ok with the proposed changes, so I'm waiting for Chaals feedback in particular. Not a big deal if we don't hear back from other reviewers. > > >> b) are things firm enough that we can create a public-webrtc-whatever@w3.org mailing list and start using it for API discussions? > > That's usually done when the group gets created, but we can certainly do that before, yes. I've just requested the creation of a public-webrtc@w3.org mailing-list. It may take a few days for this request to be processed by the systems team. > > Francois. > > [1] http://www.w3.org/Search/Mail/Member/search?keywords=daoust&hdr-1-name=subject&hdr-1-query=real-time&index-grp=Member__FULL+Public__FULL&index-type=t&type-index=w3c-archive > >> >> Harald >> >> On 04/04/11 11:11, Francois Daoust wrote: >>> Hi Harald, >>> >>> It took some time for lack of time and connection last week, but I've eventually made a few changes to the W3C draft charter for Web RTC. See latest version at: >>> http://www.w3.org/2010/12/webrtc-charter.html >>> >>> The diff is available at: >>> http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2F2010%2F12%2Fwebrtc-charter-initial.html&doc2=http%3A%2F%2Fwww.w3.org%2F2010%2F12%2Fwebrtc-charter.html >>> >>> List of changes: >>> - liaison with Web and TV IG (for home networking scenarios) added >>> - "any new" added to the mention that audio and video codecs are out of scope to respond to Art Barstow's comment, as that seemed benign enough. >>> - milestones section completed. Let me know if you have comments on this initial roadmap. I've merged all functions into one single row to keep things simple. >>> - decision policy copied from HTML charter >>> - deliverables section completed to put more emphasis on collaboration with IETF without mandating any specific text, using similar wording as that of the latest IETF RTCWeb group's charter. >>> >>> (Note the diff tool loses itself near the end: only the decision policy section has been changed) >>> >>> I stayed silent on the relation with WHATWG, and also did not introduce any change in the charter to address Stefan's detailed comments (e.g. "There must be support for media format negotiation and selection in the solution") to leave that as discussion for the group. >>> >>> Could you review the changes and let me know whether that looks good for you? >>> I've read the BoF notes taken by Christer Holmberg. Any other input from the IETF BoF meeting that would trigger additional changes in the charter? >>> >>> If you're fine with the changes, I'll get back to reviewers to get their approval, and to W3C Management with a disposition of comments to have them approve the charter and the WG chairs. Depending on the time it take to get reviewers approval, the decision could be taken this week, next week or the week after that (on Wednesday, each time). The group's creation can be officially announced shortly after that. >>> >>> Do you have a timeline for the creation of the IETF group? Having both groups created at the same time might be good if that's not too much of a pain to do. >>> >>> Dan Burnett proposed himself as co-chair for the Web RTC group. Dan has a good experience of W3C groups and is already chair of the Voice Browser working group and of the HTML Speech Incubator Group. On the minus side, he already has quite a few W3C activities on his plate. I do not know well Dan and Stefan. It doesn't make sense to have 3 chairs for the group. Do you have a strong preference? >>> >>> Who would be the chairs of the IETF working group? >>> >>> Thanks, >>> Francois. >>> >> >> --------------080005070907060009030808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is to be the official public list of the (still in-formation) W3C WG for WebRTC.
Welcome!

                          Harald

-------- Original Message --------
Subject: W3C mailing-list [was Re: Updated W3C draft charter for Web RTC WG]
Date: Tue, 12 Apr 2011 08:48:09 +0200
From: Francois Daoust <fd@w3.org>
To: Harald Alvestrand <harald@alvestrand.no> 


Hi Harald,

The public-webrtc@w3.org mailing-list is up and running.

To subscribe to the mailing-list, one needs to send an email to public-webrtc-request@w3.org with subject "subscribe", or click on the "subscribe to this list" option on the archives page.

The archives are available at:
 http://lists.w3.org/Archives/Public/public-webrtc/

Francois.





On 04/07/2011 11:27 AM, Francois Daoust wrote:
> On 04/07/2011 10:50 AM, Harald Alvestrand wrote:
>> Francios,
>>
>> a) waiting for anything from me?
>
> No, I'm waiting for replies from reviewers to my own replies [1] before I can get back to W3C management with a disposition of comments to ask for their formal approval of the changes and chairs nomination.
>
> David Baron's already replied that he's ok with the proposed changes, so I'm waiting for Chaals feedback in particular. Not a big deal if we don't hear back from other reviewers.
>
>
>> b) are things firm enough that we can create a public-webrtc-whatever@w3.org mailing list and start using it for API discussions?
>
> That's usually done when the group gets created, but we can certainly do that before, yes. I've just requested the creation of a public-webrtc@w3.org mailing-list. It may take a few days for this request to be processed by the systems team.
>
> Francois.
>
> [1] http://www.w3.org/Search/Mail/Member/search?keywords=daoust&hdr-1-name=subject&hdr-1-query=real-time&index-grp=Member__FULL+Public__FULL&index-type=t&type-index=w3c-archive
>
>>
>> Harald
>>
>> On 04/04/11 11:11, Francois Daoust wrote:
>>> Hi Harald,
>>>
>>> It took some time for lack of time and connection last week, but I've eventually made a few changes to the W3C draft charter for Web RTC. See latest version at:
>>> http://www.w3.org/2010/12/webrtc-charter.html
>>>
>>> The diff is available at:
>>> http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2F2010%2F12%2Fwebrtc-charter-initial.html&doc2=http%3A%2F%2Fwww.w3.org%2F2010%2F12%2Fwebrtc-charter.html
>>>
>>> List of changes:
>>> - liaison with Web and TV IG (for home networking scenarios) added
>>> - "any new" added to the mention that audio and video codecs are out of scope to respond to Art Barstow's comment, as that seemed benign enough.
>>> - milestones section completed. Let me know if you have comments on this initial roadmap. I've merged all functions into one single row to keep things simple.
>>> - decision policy copied from HTML charter
>>> - deliverables section completed to put more emphasis on collaboration with IETF without mandating any specific text, using similar wording as that of the latest IETF RTCWeb group's charter.
>>>
>>> (Note the diff tool loses itself near the end: only the decision policy section has been changed)
>>>
>>> I stayed silent on the relation with WHATWG, and also did not introduce any change in the charter to address Stefan's detailed comments (e.g. "There must be support for media format negotiation and selection in the solution") to leave that as discussion for the group.
>>>
>>> Could you review the changes and let me know whether that looks good for you?
>>> I've read the BoF notes taken by Christer Holmberg. Any other input from the IETF BoF meeting that would trigger additional changes in the charter?
>>>
>>> If you're fine with the changes, I'll get back to reviewers to get their approval, and to W3C Management with a disposition of comments to have them approve the charter and the WG chairs. Depending on the time it take to get reviewers approval, the decision could be taken this week, next week or the week after that (on Wednesday, each time). The group's creation can be officially announced shortly after that.
>>>
>>> Do you have a timeline for the creation of the IETF group? Having both groups created at the same time might be good if that's not too much of a pain to do.
>>>
>>> Dan Burnett proposed himself as co-chair for the Web RTC group. Dan has a good experience of W3C groups and is already chair of the Voice Browser working group and of the HTML Speech Incubator Group. On the minus side, he already has quite a few W3C activities on his plate. I do not know well Dan and Stefan. It doesn't make sense to have 3 chairs for the group. Do you have a strong preference?
>>>
>>> Who would be the chairs of the IETF working group?
>>>
>>> Thanks,
>>> Francois.
>>>
>>
>>
--------------080005070907060009030808-- From dyork@voxeo.com Tue Apr 12 05:46:24 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CBD23E0761 for ; Tue, 12 Apr 2011 05:46:24 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXP6FVN0LckS for ; Tue, 12 Apr 2011 05:46:23 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by ietfc.amsl.com (Postfix) with ESMTP id CC819E07B7 for ; Tue, 12 Apr 2011 05:46:23 -0700 (PDT) Received: from [66.65.244.241] (account dyork@voxeo.com HELO pc-00148.lodestar2.local) by voxeo.com (CommuniGate Pro SMTP 5.3.8) with ESMTPSA id 84015897; Tue, 12 Apr 2011 12:46:23 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-7-35150390 From: Dan York In-Reply-To: <4DA44596.3@alvestrand.no> Date: Tue, 12 Apr 2011 08:46:21 -0400 Message-Id: <19F5C26C-7EE3-47F8-A5BB-0D537D1B5444@voxeo.com> References: <4DA44596.3@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1084) Cc: "rtc-web@alvestrand.no" , rtcweb@ietf.org Subject: [rtcweb] Mailing list sanity check - Re: [RTW] Fwd: W3C mailing-list [was Re: Updated W3C draft charter for Web RTC WG] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 12:46:24 -0000 --Apple-Mail-7-35150390 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Harald, With 3 "RTCWEB" mailing lists now in existence (the original "rtc-web", = IETF "rtcweb" and now W3C "webrtc"), I get the sense that those of us = who want to monitor what's going on and participate as we can should = join ALL three of the lists, correct? =20 This "rtc-web" list will continue to be for the overall effort, with the = IETF and W3C lists being used for work within those bodies. =20 Or do you see this "rtc-web" list fading away in preference to the IETF = and W3C lists? Just trying to figure how many different lists I need to be on. Thanks, Dan On Apr 12, 2011, at 8:29 AM, Harald Alvestrand wrote: > This is to be the official public list of the (still in-formation) W3C = WG for WebRTC. > Welcome! >=20 > Harald >=20 > -------- Original Message -------- > Subject: W3C mailing-list [was Re: Updated W3C draft charter for = Web RTC WG] > Date: Tue, 12 Apr 2011 08:48:09 +0200 > From: Francois Daoust > To: Harald Alvestrand >=20 > Hi Harald, >=20 > The public-webrtc@w3.org mailing-list is up and running. >=20 > To subscribe to the mailing-list, one needs to send an email to = public-webrtc-request@w3.org with subject "subscribe", or click on the = "subscribe to this list" option on the archives page. >=20 > The archives are available at: > http://lists.w3.org/Archives/Public/public-webrtc/ >=20 > Francois. --=20 Dan York, Director of Conversations Voxeo Corporation http://www.voxeo.com dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork =20 Join the Voxeo conversation: Blogs: http://blogs.voxeo.com Twitter: http://twitter.com/voxeo http://twitter.com/danyork Facebook: http://www.facebook.com/voxeo --Apple-Mail-7-35150390 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

This "rtc-web" list will continue = to be for the overall effort, with the IETF and W3C lists being used for = work within those bodies.  

Or do you see = this "rtc-web" list fading away in preference to the IETF and W3C = lists?

Just trying to figure how many different = lists I need to be = on.

Thanks,
Dan


On Apr 12, 2011, at 8:29 AM, Harald Alvestrand = wrote:

This is to be the official public list of the (still in-formation) W3C WG for WebRTC.
Welcome!

=             &n= bsp;           &nbs= p; Harald

-------- Original Message -------- =
Subject: W3C mailing-list [was Re: Updated W3C draft charter for Web RTC WG]
Date: = Tue, 12 Apr 2011 08:48:09 +0200
From: = Francois Daoust <fd@w3.org>
To: = Harald Alvestrand <harald@alvestrand.no>
 


Hi Harald,

The public-webrtc@w3.org =
mailing-list is up and running.

To subscribe to the mailing-list, one needs to send an email to public-webrtc-request@w3.org<=
/a> with subject "subscribe", or click on the "subscribe to this list" =
option on the archives page.

The archives are available at:
 http://lists.w=
3.org/Archives/Public/public-webrtc/

Francois.

Dan York, = Director of Conversations
Voxeo Corporation   http://www.voxeo.com  dyork@voxeo.com
Phone: = +1-407-455-5859    Skype: = danyork  
<= /span>

= --Apple-Mail-7-35150390-- From harald@alvestrand.no Tue Apr 12 05:53:37 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 76D5DE06F5 for ; Tue, 12 Apr 2011 05:53:37 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 192NrgBcLGt1 for ; Tue, 12 Apr 2011 05:53:36 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfc.amsl.com (Postfix) with ESMTP id E6A14E07B6 for ; Tue, 12 Apr 2011 05:53:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D56DA39E15D; Tue, 12 Apr 2011 14:52:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mmD868ezcuv; Tue, 12 Apr 2011 14:52:51 +0200 (CEST) Received: from [172.16.49.75] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id F325539E113; Tue, 12 Apr 2011 14:52:50 +0200 (CEST) Message-ID: <4DA44B4B.8060607@alvestrand.no> Date: Tue, 12 Apr 2011 14:53:31 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Dan York References: <4DA44596.3@alvestrand.no> <19F5C26C-7EE3-47F8-A5BB-0D537D1B5444@voxeo.com> In-Reply-To: <19F5C26C-7EE3-47F8-A5BB-0D537D1B5444@voxeo.com> Content-Type: multipart/alternative; boundary="------------000807010607010706080206" Cc: "rtc-web@alvestrand.no" , rtcweb@ietf.org Subject: Re: [rtcweb] Mailing list sanity check - Re: [RTW] Fwd: W3C mailing-list [was Re: Updated W3C draft charter for Web RTC WG] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 12:53:37 -0000 This is a multi-part message in MIME format. --------------000807010607010706080206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 04/12/11 14:46, Dan York wrote: > Harald, > > With 3 "RTCWEB" mailing lists now in existence (the original > "rtc-web", IETF "rtcweb" and now W3C "webrtc"), I get the sense that > those of us who want to monitor what's going on and participate as we > can should join ALL three of the lists, correct? > > This "rtc-web" list will continue to be for the overall effort, with > the IETF and W3C lists being used for work within those bodies. > > Or do you see this "rtc-web" list fading away in preference to the > IETF and W3C lists? The ADs in the IETF have stated a preference for using the IETF list rather than this private list; it's somewhat clearer that this list's mail is an official IETF activity and operates under IETF IPR rules, and we don't have to worry about the quality of management at my private server. Somewhat similar considerations apply to the W3C. I would also prefer to not have to run this list on my private box forever, so I'm in favour of the "rtc-web" list fading out of use as the permanent homes for the work get set up. So I'm hoping to get down to two: rtcweb@ietf.org and public-webrtc@w3.org. Some people might have interests that are specialized enough to want to be on only one of those. (We also have a thread about an RTCWeb-related API running on the whatwg mailing list - that's a high traffic list, some might not want to sign up on that one for that reason.) > > Just trying to figure how many different lists I need to be on. > > Thanks, > Dan > > > On Apr 12, 2011, at 8:29 AM, Harald Alvestrand wrote: > >> This is to be the official public list of the (still in-formation) >> W3C WG for WebRTC. >> Welcome! >> >> Harald >> >> -------- Original Message -------- >> Subject: W3C mailing-list [was Re: Updated W3C draft charter for Web >> RTC WG] >> Date: Tue, 12 Apr 2011 08:48:09 +0200 >> From: Francois Daoust >> To: Harald Alvestrand >> >> >> >> Hi Harald, >> >> Thepublic-webrtc@w3.org mailing-list is up and running. >> >> To subscribe to the mailing-list, one needs to send an email topublic-webrtc-request@w3.org with subject "subscribe", or click on the "subscribe to this list" option on the archives page. >> >> The archives are available at: >> http://lists.w3.org/Archives/Public/public-webrtc/ >> >> Francois. > > -- > Dan York, Director of Conversations > Voxeo Corporation http://www.voxeo.com dyork@voxeo.com > > Phone: +1-407-455-5859 Skype: danyork > > *Join the Voxeo conversation:* > *Blogs: http://blogs.voxeo.com* > *Twitter: http://twitter.com/voxeo http://twitter.com/danyork* > *Facebook: http://www.facebook.com/voxeo* > --------------000807010607010706080206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 04/12/11 14:46, Dan York wrote:
Harald,

With 3 "RTCWEB" mailing lists now in existence (the original "rtc-web", IETF "rtcweb" and now W3C "webrtc"), I get the sense that those of us who want to monitor what's going on and participate as we can should join ALL three of the lists, correct?   

This "rtc-web" list will continue to be for the overall effort, with the IETF and W3C lists being used for work within those bodies.  

Or do you see this "rtc-web" list fading away in preference to the IETF and W3C lists?
The ADs in the IETF have stated a preference for using the IETF list rather than this private list; it's somewhat clearer that this list's mail is an official IETF activity and operates under IETF IPR rules, and we don't have to worry about the quality of management at my private server.

Somewhat similar considerations apply to the W3C.

I would also prefer to not have to run this list on my private box forever, so I'm in favour of the "rtc-web" list fading out of use as the permanent homes for the work get set up.

So I'm hoping to get down to two: rtcweb@ietf.org and public-webrtc@w3.org. Some people might have interests that are specialized enough to want to be on only one of those.

(We also have a thread about an RTCWeb-related API running on the whatwg mailing list - that's a high traffic list, some might not want to sign up on that one for that reason.)

Just trying to figure how many different lists I need to be on.

Thanks,
Dan


On Apr 12, 2011, at 8:29 AM, Harald Alvestrand wrote:

This is to be the official public list of the (still in-formation) W3C WG for WebRTC.
Welcome!

                          Harald

-------- Original Message --------
Subject: W3C mailing-list [was Re: Updated W3C draft charter for Web RTC WG]
Date: Tue, 12 Apr 2011 08:48:09 +0200
From: Francois Daoust <fd@w3.org>
To: Harald Alvestrand <harald@alvestrand.no> 


Hi Harald,

The public-webrtc@w3.org mailing-list is up and running.

To subscribe to the mailing-list, one needs to send an email to public-webrtc-request@w3.org with subject "subscribe", or click on the "subscribe to this list" option on the archives page.

The archives are available at:
 http://lists.w3.org/Archives/Public/public-webrtc/

Francois.

-- 
Dan York, Director of Conversations
Voxeo Corporation   http://www.voxeo.com  dyork@voxeo.com
Phone: +1-407-455-5859    Skype: danyork  


--------------000807010607010706080206-- From singer@apple.com Tue Apr 12 11:28:55 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A0786E07E4 for ; Tue, 12 Apr 2011 11:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYM-KV5D8e2a for ; Tue, 12 Apr 2011 11:28:54 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfc.amsl.com (Postfix) with ESMTP id 9BD65E065C for ; Tue, 12 Apr 2011 11:28:54 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJJ00CINXZOAUF0@mail-out.apple.com> for rtcweb@ietf.org; Tue, 12 Apr 2011 11:28:53 -0700 (PDT) X-AuditID: 11807130-b7c15ae000005aca-30-4da499e51737 Received: from [17.153.54.227] (Unknown_Domain [17.153.54.227]) by relay11.apple.com (Apple SCV relay) with SMTP id CB.18.23242.5E994AD4; Tue, 12 Apr 2011 11:28:53 -0700 (PDT) From: David Singer In-reply-to: <1D64F821-8D2B-4983-9989-F3EE076583E3@phonefromhere.com> Date: Tue, 12 Apr 2011 11:28:53 -0700 Message-id: <215B243F-B6F6-4A52-9770-B276157E4860@apple.com> References: <4D9EF7D3.1040806@alvestrand.no> <1D64F821-8D2B-4983-9989-F3EE076583E3@phonefromhere.com> To: Tim Panton X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] non-media data X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 18:28:55 -0000 On Apr 12, 2011, at 1:40 , Tim Panton wrote: > Although we should aim to limit scope, it is also a good plan to listen to experience in the field. > Our experience is that direct, reliable, sequenced transmission of small messages between > endpoints hugely adds to the value of a web-embedded RTC component. > > Typically these messages are intimately tied to events in the media engine (change of speaker, > end of message playback, transcription or recording available). (dynamic media meta-data if you like) > > They are used to change the visual state of the web page (via javascript) so that (for example) the > web displayed IVR prompts stay in sync with the audio. > > Whilst all of these are achievable via a more circuitous route (mediaserver->signalingserver->webserver->long poll-> browser) > the added latency will make the visual changes lag the audio which undermines the user experience. > > The value in RTC-web isn't the realtime audio/video itself, it's the fact that it is an integral part of > the web-page, that integration is aided by non-media data. > Tim. > OK, this is fine, but having arbitrary numbers of streams of arbitrary media types is different from designing chat sessions or file transfer as 'part of' the tool. > > On 12 Apr 2011, at 08:19, Elwell, John wrote: > >> It is always good to try to limit scope, and I think this is indeed a case where we can useful limit scope to RTP-based media (audio, video, real-time text...). >> >> John >> >> >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org >>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of David Singer >>> Sent: 08 April 2011 19:19 >>> To: rtcweb@ietf.org >>> Subject: [rtcweb] non-media data >>> >>> >>> On Apr 8, 2011, at 4:56 , Harald Alvestrand wrote: >>> >>>> >>>> - Non-media data: RTP, UDP-without-RTP, TCP, or "something else"? >>>> Congestion control is obviously needed - both for this and >>> for media, naturally. >>>> >>> >>> My feeling is that we should not forget we're designing >>> something to sit in a browser or browser-like context. We >>> *have* text chat tools, file upload and download tools, and >>> so on, today, working in browsers. Yes, they typically go >>> through a server, and going point to point might be an >>> optimization. But that's the rub; I don't think we should >>> spend a lot of time optimizing tools that are ancillary to >>> the core problem of doing real-time a/v between two users. If >>> someone wants to start a group looking at real-time >>> point-to-point text chat, well, OK, but I think it's a >>> distraction for us, at least initially. >>> >>> David Singer >>> Multimedia and Software Standards, Apple Inc. >>> >>> _______________________________________________ >>> 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 > David Singer Multimedia and Software Standards, Apple Inc. From blizzard@mozilla.com Tue Apr 12 11:51:40 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 534E7E0857 for ; Tue, 12 Apr 2011 11:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoSkJkSyyfVL for ; Tue, 12 Apr 2011 11:51:39 -0700 (PDT) Received: from mail.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by ietfc.amsl.com (Postfix) with ESMTP id 754BBE067F for ; Tue, 12 Apr 2011 11:51:39 -0700 (PDT) Received: from [192.168.0.86] (h-66-134-142-19.snvacaid.static.covad.net [66.134.142.19]) by mail.mozilla.com (Postfix) with ESMTPSA id 379C317FC7DA; Tue, 12 Apr 2011 11:51:34 -0700 (PDT) Message-ID: <4DA49F3E.7050008@mozilla.com> Date: Tue, 12 Apr 2011 11:51:42 -0700 From: Christopher Blizzard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: David Singer References: <4D9EF7D3.1040806@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080404080107090500080008" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] non-media data X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 18:51:40 -0000 This is a multi-part message in MIME format. --------------080404080107090500080008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 4/8/2011 11:19 AM, David Singer wrote: > My feeling is that we should not forget we're designing something to sit in a browser or browser-like context. We*have* text chat tools, file upload and download tools, and so on, today, working in browsers. Yes, they typically go through a server, and going point to point might be an optimization. But that's the rub; I don't think we should spend a lot of time optimizing tools that are ancillary to the core problem of doing real-time a/v between two users. If someone wants to start a group looking at real-time point-to-point text chat, well, OK, but I think it's a distraction for us, at least initially. > I'd also like to point out that at Mozilla we want to see the browser change. What you're describing is the way that browsers work today, but I think we're ready to move beyond that model to something that's app-driven, including point to point connections for data as well as media. Latency isn't just an excuse to do point to point, but is an end unto itself. John Elwell points out that limiting scope is important, and I agree. But I want to make sure that any APIs or protocols that get designed can handle this case as well. --Chris --------------080404080107090500080008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 4/8/2011 11:19 AM, David Singer wrote: 
My feeling is that we should not forget we're designing something to sit in a browser or browser-like context.  We *have* text chat tools, file upload and download tools, and so on, today, working in browsers.  Yes, they typically go through a server, and going point to point might be an optimization.  But that's the rub; I don't think we should spend a lot of time optimizing tools that are ancillary to the core problem of doing real-time a/v between two users. If someone wants to start a group looking at real-time point-to-point text chat, well, OK, but I think it's a distraction for us, at least initially.

I'd also like to point out that at Mozilla we want to see the browser change.  What you're describing is the way that browsers work today, but I think we're ready to move beyond that model to something that's app-driven, including point to point connections for data as well as media.  Latency isn't just an excuse to do point to point, but is an end unto itself.

John Elwell points out that limiting scope is important, and I agree.  But I want to make sure that any APIs or protocols that get designed can handle this case as well.

--Chris
--------------080404080107090500080008-- From harald@alvestrand.no Wed Apr 13 01:43:51 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9B305E06A0 for ; Wed, 13 Apr 2011 01:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPd9nWElmExD for ; Wed, 13 Apr 2011 01:43:50 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfc.amsl.com (Postfix) with ESMTP id 7FA33E0684 for ; Wed, 13 Apr 2011 01:43:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B09B039E11A; Wed, 13 Apr 2011 10:43:07 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zY9rLvLEn4qK; Wed, 13 Apr 2011 10:43:06 +0200 (CEST) Received: from [172.16.40.101] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 7D1D539E089; Wed, 13 Apr 2011 10:43:06 +0200 (CEST) Message-ID: <4DA56243.70604@alvestrand.no> Date: Wed, 13 Apr 2011 10:43:47 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: David Singer References: <4D9EF7D3.1040806@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] non-media data X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Apr 2011 08:43:51 -0000 On 04/08/11 20:19, David Singer wrote: > On Apr 8, 2011, at 4:56 , Harald Alvestrand wrote: > >> - Non-media data: RTP, UDP-without-RTP, TCP, or "something else"? >> Congestion control is obviously needed - both for this and for media, naturally. >> > My feeling is that we should not forget we're designing something to sit in a browser or browser-like context. We *have* text chat tools, file upload and download tools, and so on, today, working in browsers. Yes, they typically go through a server, and going point to point might be an optimization. But that's the rub; I don't think we should spend a lot of time optimizing tools that are ancillary to the core problem of doing real-time a/v between two users. If someone wants to start a group looking at real-time point-to-point text chat, well, OK, but I think it's a distraction for us, at least initially. One reason it's somewhat urgent, organizationally, is that there is an effort being pursued by some participants in WHATWG to define a protocol for data transfer in the RTCWeb context. http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#the-data-stream is the link. I'd like to make sure we don't end up in a situation where there's a thought-through protocol defined by the IETF and a non-thought-through protocol that "everyone" implements "just because the spec was there". Ideally, I'd like one protocol referenced by both contexts that is well designed. Harald From stefan.lk.hakansson@ericsson.com Thu Apr 14 06:37:05 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 76378E0771 for ; Thu, 14 Apr 2011 06:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBajZlkgsz5q for ; Thu, 14 Apr 2011 06:37:04 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfc.amsl.com (Postfix) with ESMTP id 5B96AE076B for ; Thu, 14 Apr 2011 06:37:03 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-1a-4da6f87ecde1 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 85.97.11171.E78F6AD4; Thu, 14 Apr 2011 15:37:02 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.2.57]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 14 Apr 2011 15:37:02 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Tim Panton , "Elwell, John" Date: Thu, 14 Apr 2011 15:37:01 +0200 Thread-Topic: [rtcweb] non-media data Thread-Index: Acv47UYxkSVXBMu6RjiUdLc80vRq1wBuuZvQ Message-ID: References: <4D9EF7D3.1040806@alvestrand.no> <1D64F821-8D2B-4983-9989-F3EE076583E3@phonefromhere.com> In-Reply-To: <1D64F821-8D2B-4983-9989-F3EE076583E3@phonefromhere.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] non-media data X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Apr 2011 13:37:05 -0000 I also think a direct "small message" channel would be very useful: for enh= ancing conferencing-like services as discussed below as well as for gaming = (where latency can be extremely important). And once it is available I'm su= re developers will find other, more innovative, ways to use it! Stefan -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Tim Panton Sent: den 12 april 2011 10:40 To: Elwell, John Cc: rtcweb@ietf.org Subject: Re: [rtcweb] non-media data Although we should aim to limit scope, it is also a good plan to listen to = experience in the field. Our experience is that direct, reliable, sequenced transmission of small me= ssages between endpoints hugely adds to the value of a web-embedded RTC com= ponent. Typically these messages are intimately tied to events in the media engine = (change of speaker, end of message playback, transcription or recording ava= ilable). (dynamic media meta-data if you like) They are used to change the visual state of the web page (via javascript) s= o that (for example) the web displayed IVR prompts stay in sync with the au= dio. Whilst all of these are achievable via a more circuitous route (mediaserver= ->signalingserver->webserver->long poll-> browser) the added latency will m= ake the visual changes lag the audio which undermines the user experience. The value in RTC-web isn't the realtime audio/video itself, it's the fact t= hat it is an integral part of the web-page, that integration is aided by no= n-media data. Tim. On 12 Apr 2011, at 08:19, Elwell, John wrote: > It is always good to try to limit scope, and I think this is indeed a cas= e where we can useful limit scope to RTP-based media (audio, video, real-ti= me text...). >=20 > John >=20 >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of David Singer >> Sent: 08 April 2011 19:19 >> To: rtcweb@ietf.org >> Subject: [rtcweb] non-media data >>=20 >>=20 >> On Apr 8, 2011, at 4:56 , Harald Alvestrand wrote: >>=20 >>>=20 >>> - Non-media data: RTP, UDP-without-RTP, TCP, or "something else"? >>> Congestion control is obviously needed - both for this and >> for media, naturally. >>>=20 >>=20 >> My feeling is that we should not forget we're designing something to=20 >> sit in a browser or browser-like context. We >> *have* text chat tools, file upload and download tools, and so on,=20 >> today, working in browsers. Yes, they typically go through a server,=20 >> and going point to point might be an optimization. But that's the=20 >> rub; I don't think we should spend a lot of time optimizing tools=20 >> that are ancillary to the core problem of doing real-time a/v between=20 >> two users. If someone wants to start a group looking at real-time=20 >> point-to-point text chat, well, OK, but I think it's a distraction=20 >> for us, at least initially. >>=20 >> David Singer >> Multimedia and Software Standards, Apple Inc. >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From hoene@uni-tuebingen.de Thu Apr 14 07:00:10 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1AB26E087F for ; Thu, 14 Apr 2011 07:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.835 X-Spam-Level: X-Spam-Status: No, score=-3.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YA0FIRTPxvh for ; Thu, 14 Apr 2011 07:00:09 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by ietfc.amsl.com (Postfix) with ESMTP id 03234E0765 for ; Thu, 14 Apr 2011 07:00:08 -0700 (PDT) Received: from hoeneT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id p3EE06Ip027116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 14 Apr 2011 16:00:07 +0200 From: "Christian Hoene" To: Date: Thu, 14 Apr 2011 16:00:09 +0200 Organization: =?us-ascii?Q?Universitat_Tubingen?= Message-ID: <009301cbfaac$44353e10$cc9fba30$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acv6q49wKsuT3k+/Tba1Y+Use3poiw== Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.1.2; host: mx05) Subject: [rtcweb] 3D Plugin? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Apr 2011 14:00:10 -0000 Hi, I was wondering whether somebody plan to add a 3D rendering plugin into the RTC-web browser? Any plan about this or is it out of scope? With best regards, Christian Hoene From magnus.westerlund@ericsson.com Thu Apr 14 07:02:14 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 85C98E066B for ; Thu, 14 Apr 2011 07:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOEOTniNmMnv for ; Thu, 14 Apr 2011 07:02:13 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id A28F9E077E for ; Thu, 14 Apr 2011 07:02:13 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-3a-4da6fe64fc8b Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C1.F7.09202.46EF6AD4; Thu, 14 Apr 2011 16:02:13 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Thu, 14 Apr 2011 16:02:12 +0200 Message-ID: <4DA6FE64.3010603@ericsson.com> Date: Thu, 14 Apr 2011 16:02:12 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Christian Hoene References: <009301cbfaac$44353e10$cc9fba30$@uni-tuebingen.de> In-Reply-To: <009301cbfaac$44353e10$cc9fba30$@uni-tuebingen.de> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] 3D Plugin? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Apr 2011 14:02:14 -0000 Christian Hoene skrev 2011-04-14 16:00: > Hi, > > I was wondering whether somebody plan to add a 3D rendering plugin into the > RTC-web browser? > Any plan about this or is it out of scope? Are there any additional requirements on RTCWEB than seeing it as an media type with some media type specific signalling, most likely as part of the RTP payload type used to carry the data between the peers? 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 singer@apple.com Thu Apr 14 08:35:05 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 45649E089E for ; Thu, 14 Apr 2011 08:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xCGYROYgLoT for ; Thu, 14 Apr 2011 08:35:04 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfc.amsl.com (Postfix) with ESMTP id 36934E089A for ; Thu, 14 Apr 2011 08:35:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJN006LWFAE57K1@mail-out.apple.com> for rtcweb@ietf.org; Thu, 14 Apr 2011 08:35:03 -0700 (PDT) X-AuditID: 11807130-b7c15ae000005aca-07-4da71427ed10 Received: from [17.153.34.13] (Unknown_Domain [17.153.34.13]) by relay11.apple.com (Apple SCV relay) with SMTP id 91.EB.23242.72417AD4; Thu, 14 Apr 2011 08:35:03 -0700 (PDT) From: David Singer In-reply-to: <4DA6FE64.3010603@ericsson.com> Date: Thu, 14 Apr 2011 08:35:02 -0700 Message-id: References: <009301cbfaac$44353e10$cc9fba30$@uni-tuebingen.de> <4DA6FE64.3010603@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] 3D Plugin? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Apr 2011 15:35:05 -0000 On Apr 14, 2011, at 7:02 , Magnus Westerlund wrote: > Christian Hoene skrev 2011-04-14 16:00: >> Hi, >> >> I was wondering whether somebody plan to add a 3D rendering plugin into the >> RTC-web browser? >> Any plan about this or is it out of scope? > > Are there any additional requirements on RTCWEB than seeing it as an > media type with some media type specific signalling, most likely as part > of the RTP payload type used to carry the data between the peers? It's hard to tell from such a brief message, alas. But perhaps we are in agreement. I am envisaging markup/DOM that makes the camera and microphone visible, the ability to connect them and the audio/video elements to modules that do real-time communication, javascript APIs control the markup and those modules. I expect that the modules will instantiate discovery, signalling/connectivity, actual real-time streaming, encode/decode, and monitoring. Within that, I am expecting there to be initial modules defined and probably mandated to do an initial set of protocols, probably the classic RTP/SIP for signalling and flows, and that those modules will be spec'd with 'enough' NAT/firewall handling to work most of the time. Connection to TURN servers should probably be possible. Other modules are possible; explore, refine, develop, prototype, etc. So, on the subject of 3D: if your browser supports a stereo video media type for rendering in the video element, and for capture by a camera, and your codecs can encode/decode that type, and RTP encapsulate it, and your protocol modules carry it (and it should be transparent)...why not? Quite a few use-cases do not need arbitrary discovery. * I bring up a web page from an organization that offers to connect me to a department at that organization (e.g. customer support), in an integrated context. The 'server cloud' at that corporation does not need to 'discover' a customer support rep's IP address, it can know it. * I am on a cloud-service based portal page (like a yahoo, google, etc. page), which has frames for email, chat, news, and video-phone. The page indicates that someone in my (cloudbased) address book is online and call-able. It already knows that and where they are, and has put a 'green phone' icon next to them. No discovery is needed. Indeed, what makes the browser attractive is that it offers an integrating service environment, and doing a classic 'blind call' to an address in my address book, where full discovery is needed ('is fred online', 'what is his IP address?' etc.) is not obviously benefiting much from this. Videophone applications already do this (quite well). David Singer Multimedia and Software Standards, Apple Inc. From juberti@google.com Thu Apr 14 23:37:54 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BEAAEE067D for ; Thu, 14 Apr 2011 23:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.676 X-Spam-Level: X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaHMblSP7pjP for ; Thu, 14 Apr 2011 23:37:53 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfc.amsl.com (Postfix) with ESMTP id 7815DE0693 for ; Thu, 14 Apr 2011 23:37:53 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p3F6bqYu028382 for ; Thu, 14 Apr 2011 23:37:52 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302849472; bh=Yj4we0AO+/+6uMiEYW4whnrTsMQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=d2LI3HqGxQH0j2Fbk0R3GxWYFkdumSp8cVUJsqT8xwtHrN4h4LfEogdACWNL5nuDG duq5kKEpZYXUH8NpU3JGw== Received: from qwb8 (qwb8.prod.google.com [10.241.193.72]) by wpaz5.hot.corp.google.com with ESMTP id p3F6bp5E019733 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 14 Apr 2011 23:37:51 -0700 Received: by qwb8 with SMTP id 8so2016381qwb.39 for ; Thu, 14 Apr 2011 23:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TV0S3xqqvYiIy2ufwF1xRVpY/EjO/JIP/4zao4IFQhk=; b=slOE250eYxDVuE+CptnuKMeOkDpheOVY6G/4j/8H2aa7I3b5vJovrhwIY/L0yCNodw xC4PS85HF7EpwfUild6A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=p62lpsBNaV8p0Wc7XDUwRFzj8b8CK91Itvic9kkO/noOTlZIS/nGsquIde6RHqipPS NeL/7f0iKns1ai46rmdg== Received: by 10.229.35.212 with SMTP id q20mr1224986qcd.205.1302849470372; Thu, 14 Apr 2011 23:37:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.15.72 with HTTP; Thu, 14 Apr 2011 23:37:30 -0700 (PDT) In-Reply-To: References: <4D9EF7D3.1040806@alvestrand.no> <1D64F821-8D2B-4983-9989-F3EE076583E3@phonefromhere.com> From: Justin Uberti Date: Thu, 14 Apr 2011 23:37:30 -0700 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: multipart/alternative; boundary=001636418125e09d6e04a0ef47e7 X-System-Of-Record: true Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] non-media data X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Apr 2011 06:37:54 -0000 --001636418125e09d6e04a0ef47e7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I tend to think we should separate "RTP session" (i.e. PeerConnection) from "network transport"; a RTP session will run over network transports, but I don't know if we want to add generic transport facility to the RTP session API. As in, if reliable message delivery is desired, do we want to go down the road of TCP-over-RTP? If we expose raw transport as a lower-level API, then RTP sessions and generic sessions can make use of this transport service. On Thu, Apr 14, 2011 at 6:37 AM, Stefan H=C3=A5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > I also think a direct "small message" channel would be very useful: for > enhancing conferencing-like services as discussed below as well as for > gaming (where latency can be extremely important). And once it is availab= le > I'm sure developers will find other, more innovative, ways to use it! > > Stefan > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Tim Panton > Sent: den 12 april 2011 10:40 > To: Elwell, John > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] non-media data > > Although we should aim to limit scope, it is also a good plan to listen t= o > experience in the field. > Our experience is that direct, reliable, sequenced transmission of small > messages between endpoints hugely adds to the value of a web-embedded RTC > component. > > Typically these messages are intimately tied to events in the media engin= e > (change of speaker, end of message playback, transcription or recording > available). (dynamic media meta-data if you like) > > They are used to change the visual state of the web page (via javascript) > so that (for example) the web displayed IVR prompts stay in sync with the > audio. > > Whilst all of these are achievable via a more circuitous route > (mediaserver->signalingserver->webserver->long poll-> browser) the added > latency will make the visual changes lag the audio which undermines the u= ser > experience. > > The value in RTC-web isn't the realtime audio/video itself, it's the fact > that it is an integral part of the web-page, that integration is aided by > non-media data. > Tim. > > > On 12 Apr 2011, at 08:19, Elwell, John wrote: > > > It is always good to try to limit scope, and I think this is indeed a > case where we can useful limit scope to RTP-based media (audio, video, > real-time text...). > > > > John > > > > > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org > >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of David Singer > >> Sent: 08 April 2011 19:19 > >> To: rtcweb@ietf.org > >> Subject: [rtcweb] non-media data > >> > >> > >> On Apr 8, 2011, at 4:56 , Harald Alvestrand wrote: > >> > >>> > >>> - Non-media data: RTP, UDP-without-RTP, TCP, or "something else"? > >>> Congestion control is obviously needed - both for this and > >> for media, naturally. > >>> > >> > >> My feeling is that we should not forget we're designing something to > >> sit in a browser or browser-like context. We > >> *have* text chat tools, file upload and download tools, and so on, > >> today, working in browsers. Yes, they typically go through a server, > >> and going point to point might be an optimization. But that's the > >> rub; I don't think we should spend a lot of time optimizing tools > >> that are ancillary to the core problem of doing real-time a/v between > >> two users. If someone wants to start a group looking at real-time > >> point-to-point text chat, well, OK, but I think it's a distraction > >> for us, at least initially. > >> > >> David Singer > >> Multimedia and Software Standards, Apple Inc. > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001636418125e09d6e04a0ef47e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I tend to think we should separate "RTP session" (i.e. PeerConnec= tion) from "network transport"; a RTP session will run over netwo= rk transports, but I don't know if we want to add generic transport fac= ility to the RTP session API. As in, if reliable message delivery is desire= d, do we want to go down the road of TCP-over-RTP?

If we expose raw transport as a lower-level API, then RTP se= ssions and generic sessions can make use of this transport service.

=
On Thu, Apr 14, 2011 at 6:37 AM, Stefan H=C3=A5k= ansson LK <stefan.lk.hakansson@ericsson.com> wrote:
I also think a direct "small message&q= uot; channel would be very useful: for enhancing conferencing-like services= as discussed below as well as for gaming (where latency can be extremely i= mportant). And once it is available I'm sure developers will find other= , more innovative, ways to use it!

Stefan

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.or= g] On Behalf Of Tim Panton
Sent: den 12 april 2011 10:40
To: Elwell, John
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] non-media data

Although we should aim to limit scope, it is also a good plan to listen to = experience in the field.
Our experience is that direct, reliable, sequenced transmission of small me= ssages between endpoints hugely adds to the value of a web-embedded RTC com= ponent.

Typically these messages are intimately tied to events in the media engine = (change of speaker, end of message playback, transcription or recording ava= ilable). (dynamic media meta-data if you like)

They are used to change the visual state of the web page (via javascript) s= o that (for example) the web displayed IVR prompts stay in sync with the au= dio.

Whilst all of these are achievable via a more circuitous route (mediaserver= ->signalingserver->webserver->long poll-> browser) the added la= tency will make the visual changes lag the audio which undermines the user = experience.

The value in RTC-web isn't the realtime audio/video itself, it's th= e fact that it is an integral part of the web-page, that integration is aid= ed by non-media data.
Tim.


On 12 Apr 2011, at 08:19, Elwell, John wrote:

> It is always good to try to limit scope, and I think this is indeed a = case where we can useful limit scope to RTP-based media (audio, video, real= -time text...).
>
> John
>
>
>> -----Original Message-----
>> From: rtcweb-bounces@ie= tf.org
>> [mailto:rtcweb-bounces@= ietf.org] On Behalf Of David Singer
>> Sent: 08 April 2011 19:19
>> To: rtcweb@ietf.org
>> Subject: [rtcweb] non-media data
>>
>>
>> On Apr 8, 2011, at 4:56 , Harald Alvestran= d wrote:
>>
>>>
>>> - Non-media data: RTP, UDP-without-RTP, TCP, or "somethin= g else"?
>>> Congestion control is obviously needed - both for this and
>> for media, naturally.
>>>
>>
>> My feeling is that we should not forget we're designing someth= ing to
>> sit in a browser or browser-like context. =C2=A0We
>> *have* text chat tools, file upload and download tools, and so on,=
>> today, working in browsers. =C2=A0Yes, they typically go through a= server,
>> and going point to point might be an optimization. =C2=A0But that&= #39;s the
>> rub; I don't think we should spend a lot of time optimizing to= ols
>> that are ancillary to the core problem of doing real-time a/v betw= een
>> two users. If someone wants to start a group looking at real-time<= br> >> point-to-point text chat, well, OK, but I think it's a distrac= tion
>> for us, at least initially.
>>
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

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

--001636418125e09d6e04a0ef47e7-- From magnus.westerlund@ericsson.com Fri Apr 15 00:42:30 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 54281E067D for ; Fri, 15 Apr 2011 00:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.55 X-Spam-Level: X-Spam-Status: No, score=-106.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rv26Z2SMlEee for ; Fri, 15 Apr 2011 00:42:29 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfc.amsl.com (Postfix) with ESMTP id EC069E0675 for ; Fri, 15 Apr 2011 00:42:28 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-ed-4da7f6e45b53 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 39.A8.11171.4E6F7AD4; Fri, 15 Apr 2011 09:42:28 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Fri, 15 Apr 2011 09:42:27 +0200 Message-ID: <4DA7F6E3.6010100@ericsson.com> Date: Fri, 15 Apr 2011 09:42:27 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Justin Uberti References: <4D9EF7D3.1040806@alvestrand.no> <1D64F821-8D2B-4983-9989-F3EE076583E3@phonefromhere.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] non-media data X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Apr 2011 07:42:30 -0000 Justin Uberti skrev 2011-04-15 08:37: > I tend to think we should separate "RTP session" (i.e. PeerConnection) > from "network transport"; a RTP session will run over network > transports, but I don't know if we want to add generic transport > facility to the RTP session API. As in, if reliable message delivery is > desired, do we want to go down the road of TCP-over-RTP? I don't like all this talk about data over RTP. Generic data over RTP isn't the most suitable model for a number of reasons which I will come back to below. From my perspective we do want data transport that provide a unreliable datagram based transport. That would in my view include make available to the web application through the API this. And let the WEBAPP decided what is put in each datagram. However, we clearly needs some requirements on that datagram service so that it remains safe and fair when it comes to transport. To me that means requirements such as: - Congestion Controlled - Confidentiality and Integrity Protected - Providing consent to receive data prior to allow transmission of substantial amounts of data - Some type of source authentication to prevent man in the middles There is a question of how much additional functionality one likes to offer around an unreliable datagram transport. I think we need to go through http://www.rfc-editor.org/rfc/rfc5405.txt and see what is desired to have as part of the browser implementation and what is left to the web application to implement. Then there is the question if we desire to provide additional transport properties, like reliable datagram, or reliable byte stream modes. There there exist several possible ways of doing that. Separate protocol stacks, reliability extension on top of an unreliable datagram transport etc. I also think it is important that we do discuss what requirements exist for each of the transport properties. I promised to return to why I think TCP over RTP or more general, generic data over RTP isn't the most suitable model. - RTP is a protocol built towards real-time media. Yes the definition of media can be pretty loose here. But carrying the individual datagrams of a TCP connection over RTP is plainly stupid, when TCP over UDP will get you all the desired functionality anyway with less overhead. - RTP requires RTP payload formats for anything it carries. That is to ensure that the application level framing ideas are as well captured for a particular media encoding as possible. That optimization is not possible for general data. - If one can't do general optimization one goes with more general transport solutions, thus why not use a more general data transport for the general data? - RTP and RTCP monitoring is also designed with more continous medias in mind. Here we don't know how much such properties will be true. Also the congestion controls available might actually have not the most suitable properties for certain type of data. > > If we expose raw transport as a lower-level API, then RTP sessions and > generic sessions can make use of this transport service. > I understand your thinking, but there is important to remember that the NAT/FW traversal solution is likely needing to operate on top of the bottom most transport protocol, most likely UDP. On top of that we have thus may ICE's STUN servers multiplexed with one RTP session on the same 5-tuple. Isn't it likely that one will from an API perspective request an RTP sessison to be established to the peer with a certain set of RTP payload types to carry a particular media type for a particular purpose. In the same way I see that a unreliable datagram transport will be requested and as part of that request indicate what particular data one wants to run on top, for example using media types like for the UDP and TCP protocol identifiers in SDP, or another label scheme. But the web application and perhaps the browser will have an understanding what a particular flow will be used to. When it comes to actually doing a data transport of any kind. I do think this is an individual module that can be negotiated for availability between two peers. However, I do think there are a number of use cases that are so interesting that at least unreliable datagram transport should be aimed at completing at the same time as setup and negotiation, NAT/FW traversal, and the real-time media modules. But more use cases and more opinions on this are desirable. At the same time I would like to hear if anyone has use cases for reliable data services that goes directly peer to peer, either message based or byte stream based. So far the arguments I have seen for this are reducing load on relays, and lower transport delay. Some views from someone actually needs such transport services as part of the solution would be great. 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 tim@phonefromhere.com Fri Apr 15 01:40:18 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B71F7E0693 for ; Fri, 15 Apr 2011 01:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHhmMXbcO6KQ for ; Fri, 15 Apr 2011 01:40:18 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfc.amsl.com (Postfix) with ESMTP id E7F98E065A for ; Fri, 15 Apr 2011 01:40:17 -0700 (PDT) Received: from [192.168.0.16] (87-194-8-115.bethere.co.uk [87.194.8.115]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 19E7F37A8FC; Fri, 15 Apr 2011 09:50:12 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <4DA7F6E3.6010100@ericsson.com> Date: Fri, 15 Apr 2011 09:40:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <78A7F416-F9F8-4BE8-92DB-101A3919AD9D@phonefromhere.com> References: <4D9EF7D3.1040806@alvestrand.no> <1D64F821-8D2B-4983-9989-F3EE076583E3@phonefromhere.com> <4DA7F6E3.6010100@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] non-media data X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Apr 2011 08:40:18 -0000 On 15 Apr 2011, at 08:42, Magnus Westerlund wrote: >=20 > At the same time I would like to hear if anyone has use cases for > reliable data services that goes directly peer to peer, either message > based or byte stream based. So far the arguments I have seen for this > are reducing load on relays, and lower transport delay. Some views = from > someone actually needs such transport services as part of the solution > would be great. It's true that there are always multiple routes to solve a problem, but=20= take my example of sending visible IVR prompts to a browserbased = softphone. (So if you call your bank from a web-embedded softphone you get a visual = menu to go with the spoken IVR, prompts can have more explanatory help text = and chosen faster as most people can read faster than an IVR can speak. The = prompts=20 change as you move through the IVR tree - at some point you may get = handed off to a real person) Ideally these messages are carried over reliable datagrams, in = reasonably close sync with the media. You don't want to miss them and you don't want them = to be delivered out of sequence. A TCP stream wouldn't be a good fit as these are = messages not streams. The case is much more like DTMF, except more generalised and hopefully = without the ugliness of the "send the same thing many times in the hope that one = will get through" that asymmetric RTP requires when doing DTMF. This is a near-term transitional example, I'm sure that in the future, = there will be more=20 extreme examples say involving lip-sync animation of locally drawn = (SVG?) avatars, again where the timing is critical. Sure you could define a new media-type for lip-sync animation, but which = web coder will do that if they can throw a JSON packet up the wire ? In this case a generalist = web-friendly mechanism is going to win out. Tim.= From harald@alvestrand.no Fri Apr 15 05:00:11 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7D7B8E0681 for ; Fri, 15 Apr 2011 05:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+b9luPT6pjV for ; Fri, 15 Apr 2011 05:00:10 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfc.amsl.com (Postfix) with ESMTP id 4563DE06CE for ; Fri, 15 Apr 2011 05:00:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C63C739E072 for ; Fri, 15 Apr 2011 13:59:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5ywnQzbdF-0 for ; Fri, 15 Apr 2011 13:59:24 +0200 (CEST) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id B359839E0FD for ; Fri, 15 Apr 2011 13:59:24 +0200 (CEST) Message-ID: <4DA83346.2060608@alvestrand.no> Date: Fri, 15 Apr 2011 14:00:06 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary="------------090605010207070609060502" Subject: [rtcweb] Fwd: RFC 6222 on Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Apr 2011 12:00:11 -0000 This is a multi-part message in MIME format. --------------090605010207070609060502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Since this RFC effectively tells us that we should abandon the "cname is user@host" convention, this RFC may be of interest to this WG. Of special interest is the explicit statement that a CNAME is used to identify streams that need to be synchronized between multiple RTP sessions; I take it that the inverse is also true - that streams that do not need to be synchronized do not need to have the same CNAME. Harald -------- Original Message -------- Subject: RFC 6222 on Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) Date: Thu, 14 Apr 2011 11:26:24 -0700 (PDT) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: avt@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 6222 Title: Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) Author: A. Begen, C. Perkins, D. Wing Status: Standards Track Stream: IETF Date: April 2011 Mailbox: abegen@cisco.com, csp@csperkins.org, dwing@cisco.com Pages: 9 Characters: 20393 Updates: RFC3550 I-D Tag: draft-ietf-avt-rtp-cnames-05.txt URL: http://www.rfc-editor.org/rfc/rfc6222.txt The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. This memo updates those guidelines to allow endpoints to choose unique RTCP CNAMEs. [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------090605010207070609060502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Since this RFC effectively tells us that we should abandon the "cname is user@host" convention, this RFC may be of interest to this WG.

Of special interest is the explicit statement that a CNAME is used to identify streams that need to be synchronized between multiple RTP sessions; I take it that the inverse is also true - that streams that do not need to be synchronized do not need to have the same CNAME.

               Harald

-------- Original Message --------
Subject: RFC 6222 on Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
Date: Thu, 14 Apr 2011 11:26:24 -0700 (PDT)
From: rfc-editor@rfc-editor.org
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
CC: avt@ietf.org, rfc-editor@rfc-editor.org 


A new Request for Comments is now available in online RFC libraries.

        
        RFC 6222

        Title:      Guidelines for Choosing RTP Control 
                    Protocol (RTCP) Canonical Names (CNAMEs) 
        Author:     A. Begen, C. Perkins,
                    D. Wing
        Status:     Standards Track
        Stream:     IETF
        Date:       April 2011
        Mailbox:    abegen@cisco.com, 
                    csp@csperkins.org, 
                    dwing@cisco.com
        Pages:      9
        Characters: 20393
        Updates:    RFC3550

        I-D Tag:    draft-ietf-avt-rtp-cnames-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6222.txt

The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a
persistent transport-level identifier for an RTP endpoint.  While the
Synchronization Source (SSRC) identifier of an RTP endpoint may
change if a collision is detected or when the RTP application is
restarted, its RTCP CNAME is meant to stay unchanged, so that RTP
endpoints can be uniquely identified and associated with their RTP
media streams.  For proper functionality, RTCP CNAMEs should be
unique within the participants of an RTP session.  However, the
existing guidelines for choosing the RTCP CNAME provided in the RTP
standard are insufficient to achieve this uniqueness.  This memo
updates those guidelines to allow endpoints to choose unique RTCP
CNAMEs.  [STANDARDS-TRACK]

This document is a product of the Audio/Video Transport Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
--------------090605010207070609060502-- From harald@alvestrand.no Fri Apr 15 05:53:28 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 747BEE07FD for ; Fri, 15 Apr 2011 05:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orVSl41cvL+K for ; Fri, 15 Apr 2011 05:53:27 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfc.amsl.com (Postfix) with ESMTP id 4D15AE07F3 for ; Fri, 15 Apr 2011 05:53:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 89C4E39E0FD; Fri, 15 Apr 2011 14:52:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZXam6yEVgEb; Fri, 15 Apr 2011 14:52:43 +0200 (CEST) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 365FE39E072; Fri, 15 Apr 2011 14:52:43 +0200 (CEST) Message-ID: <4DA83FC4.8020601@alvestrand.no> Date: Fri, 15 Apr 2011 14:53:24 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Tim Panton References: <4D9EF7D3.1040806@alvestrand.no> <1D64F821-8D2B-4983-9989-F3EE076583E3@phonefromhere.com> <4DA7F6E3.6010100@ericsson.com> <78A7F416-F9F8-4BE8-92DB-101A3919AD9D@phonefromhere.com> In-Reply-To: <78A7F416-F9F8-4BE8-92DB-101A3919AD9D@phonefromhere.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] non-media data X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Apr 2011 12:53:28 -0000 On 04/15/11 10:40, Tim Panton wrote: > On 15 Apr 2011, at 08:42, Magnus Westerlund wrote: > >> At the same time I would like to hear if anyone has use cases for >> reliable data services that goes directly peer to peer, either message >> based or byte stream based. So far the arguments I have seen for this >> are reducing load on relays, and lower transport delay. Some views from >> someone actually needs such transport services as part of the solution >> would be great. > It's true that there are always multiple routes to solve a problem, but > take my example of sending visible IVR prompts to a browserbased softphone. > > (So if you call your bank from a web-embedded softphone you get a visual menu > to go with the spoken IVR, prompts can have more explanatory help text and > chosen faster as most people can read faster than an IVR can speak. The prompts > change as you move through the IVR tree - at some point you may get handed off to > a real person) > > Ideally these messages are carried over reliable datagrams, in reasonably close > sync with the media. You don't want to miss them and you don't want them to be delivered > out of sequence. A TCP stream wouldn't be a good fit as these are messages not streams. Actually, this use case seem to me like an excellent fit with HTML-based menus with menu content carried over XDR. On a good day, the time required to replace menu content is ~100 msec; this is far faster than most humans can react. It does point out (to me) a need to insert syncpoints into media streams so that the HTML action can be synchronized with the spoken text; the syncpoints may be represented as specific timestamps that are part of HTML content with values pointing into the media streams, or they might be synchronized packets carried on a data channel that arrives in sync with the audio. > The case is much more like DTMF, except more generalised and hopefully without the > ugliness of the "send the same thing many times in the hope that one will get through" > that asymmetric RTP requires when doing DTMF. > > This is a near-term transitional example, I'm sure that in the future, there will be more > extreme examples say involving lip-sync animation of locally drawn (SVG?) avatars, again where > the timing is critical. > > Sure you could define a new media-type for lip-sync animation, but which web coder will do that > if they can throw a JSON packet up the wire ? In this case a generalist web-friendly mechanism > is going to win out. For a working example of stuff synchronized with media, check out WebVTT (subtitling). http://www.whatwg.org/specs/web-apps/current-work/webvtt.html From harald@alvestrand.no Fri Apr 15 05:55:38 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7440BE07FD for ; Fri, 15 Apr 2011 05:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub7vE7DzXDIR for ; Fri, 15 Apr 2011 05:55:36 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfc.amsl.com (Postfix) with ESMTP id 388C2E0801 for ; Fri, 15 Apr 2011 05:55:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6FFB139E0FD; Fri, 15 Apr 2011 14:54:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUJpMDGDv+qV; Fri, 15 Apr 2011 14:54:51 +0200 (CEST) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id E430C39E072; Fri, 15 Apr 2011 14:54:50 +0200 (CEST) Message-ID: <4DA84044.9090207@alvestrand.no> Date: Fri, 15 Apr 2011 14:55:32 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Justin Uberti References: <4D9EF7D3.1040806@alvestrand.no> <1D64F821-8D2B-4983-9989-F3EE076583E3@phonefromhere.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060107050103020406080307" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] non-media data X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Apr 2011 12:55:38 -0000 This is a multi-part message in MIME format. --------------060107050103020406080307 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit When I wrote draft-alvestrand-dispatch-rtcweb-01, I was trying to describe a datagram service with assured "permission to send", which could be used to underpin either RTP or a raw datagram service. It's received relatively little feedback; we might want to pursue it or not. On 04/15/11 08:37, Justin Uberti wrote: > I tend to think we should separate "RTP session" (i.e. PeerConnection) > from "network transport"; a RTP session will run over network > transports, but I don't know if we want to add generic transport > facility to the RTP session API. As in, if reliable message delivery > is desired, do we want to go down the road of TCP-over-RTP? > > If we expose raw transport as a lower-level API, then RTP sessions and > generic sessions can make use of this transport service. > > On Thu, Apr 14, 2011 at 6:37 AM, Stefan HÃ¥kansson LK > > wrote: > > I also think a direct "small message" channel would be very > useful: for enhancing conferencing-like services as discussed > below as well as for gaming (where latency can be extremely > important). And once it is available I'm sure developers will find > other, more innovative, ways to use it! > > Stefan > > -----Original Message----- > From: rtcweb-bounces@ietf.org > [mailto:rtcweb-bounces@ietf.org ] > On Behalf Of Tim Panton > Sent: den 12 april 2011 10:40 > To: Elwell, John > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] non-media data > > Although we should aim to limit scope, it is also a good plan to > listen to experience in the field. > Our experience is that direct, reliable, sequenced transmission of > small messages between endpoints hugely adds to the value of a > web-embedded RTC component. > > Typically these messages are intimately tied to events in the > media engine (change of speaker, end of message playback, > transcription or recording available). (dynamic media meta-data if > you like) > > They are used to change the visual state of the web page (via > javascript) so that (for example) the web displayed IVR prompts > stay in sync with the audio. > > Whilst all of these are achievable via a more circuitous route > (mediaserver->signalingserver->webserver->long poll-> browser) the > added latency will make the visual changes lag the audio which > undermines the user experience. > > The value in RTC-web isn't the realtime audio/video itself, it's > the fact that it is an integral part of the web-page, that > integration is aided by non-media data. > Tim. > > > On 12 Apr 2011, at 08:19, Elwell, John wrote: > > > It is always good to try to limit scope, and I think this is > indeed a case where we can useful limit scope to RTP-based media > (audio, video, real-time text...). > > > > John > > > > > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org > >> [mailto:rtcweb-bounces@ietf.org > ] On Behalf Of David Singer > >> Sent: 08 April 2011 19:19 > >> To: rtcweb@ietf.org > >> Subject: [rtcweb] non-media data > >> > >> > >> On Apr 8, 2011, at 4:56 , Harald Alvestrand wrote: > >> > >>> > >>> - Non-media data: RTP, UDP-without-RTP, TCP, or "something else"? > >>> Congestion control is obviously needed - both for this and > >> for media, naturally. > >>> > >> > >> My feeling is that we should not forget we're designing > something to > >> sit in a browser or browser-like context. We > >> *have* text chat tools, file upload and download tools, and so on, > >> today, working in browsers. Yes, they typically go through a > server, > >> and going point to point might be an optimization. But that's the > >> rub; I don't think we should spend a lot of time optimizing tools > >> that are ancillary to the core problem of doing real-time a/v > between > >> two users. If someone wants to start a group looking at real-time > >> point-to-point text chat, well, OK, but I think it's a distraction > >> for us, at least initially. > >> > >> David Singer > >> Multimedia and Software Standards, Apple Inc. > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------060107050103020406080307 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit When I wrote draft-alvestrand-dispatch-rtcweb-01, I was trying to describe a datagram service with assured "permission to send", which could be used to underpin either RTP or a raw datagram service.

It's received relatively little feedback; we might want to pursue it or not.

On 04/15/11 08:37, Justin Uberti wrote:
I tend to think we should separate "RTP session" (i.e. PeerConnection) from "network transport"; a RTP session will run over network transports, but I don't know if we want to add generic transport facility to the RTP session API. As in, if reliable message delivery is desired, do we want to go down the road of TCP-over-RTP?

If we expose raw transport as a lower-level API, then RTP sessions and generic sessions can make use of this transport service.

On Thu, Apr 14, 2011 at 6:37 AM, Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com> wrote:
I also think a direct "small message" channel would be very useful: for enhancing conferencing-like services as discussed below as well as for gaming (where latency can be extremely important). And once it is available I'm sure developers will find other, more innovative, ways to use it!

Stefan

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Tim Panton
Sent: den 12 april 2011 10:40
To: Elwell, John
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] non-media data

Although we should aim to limit scope, it is also a good plan to listen to experience in the field.
Our experience is that direct, reliable, sequenced transmission of small messages between endpoints hugely adds to the value of a web-embedded RTC component.

Typically these messages are intimately tied to events in the media engine (change of speaker, end of message playback, transcription or recording available). (dynamic media meta-data if you like)

They are used to change the visual state of the web page (via javascript) so that (for example) the web displayed IVR prompts stay in sync with the audio.

Whilst all of these are achievable via a more circuitous route (mediaserver->signalingserver->webserver->long poll-> browser) the added latency will make the visual changes lag the audio which undermines the user experience.

The value in RTC-web isn't the realtime audio/video itself, it's the fact that it is an integral part of the web-page, that integration is aided by non-media data.
Tim.


On 12 Apr 2011, at 08:19, Elwell, John wrote:

> It is always good to try to limit scope, and I think this is indeed a case where we can useful limit scope to RTP-based media (audio, video, real-time text...).
>
> John
>
>
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org
>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of David Singer
>> Sent: 08 April 2011 19:19
>> To: rtcweb@ietf.org
>> Subject: [rtcweb] non-media data
>>
>>
>> On Apr 8, 2011, at 4:56 , Harald Alvestrand wrote:
>>
>>>
>>> - Non-media data: RTP, UDP-without-RTP, TCP, or "something else"?
>>> Congestion control is obviously needed - both for this and
>> for media, naturally.
>>>
>>
>> My feeling is that we should not forget we're designing something to
>> sit in a browser or browser-like context.  We
>> *have* text chat tools, file upload and download tools, and so on,
>> today, working in browsers.  Yes, they typically go through a server,
>> and going point to point might be an optimization.  But that's the
>> rub; I don't think we should spend a lot of time optimizing tools
>> that are ancillary to the core problem of doing real-time a/v between
>> two users. If someone wants to start a group looking at real-time
>> point-to-point text chat, well, OK, but I think it's a distraction
>> for us, at least initially.
>>
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

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


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

--------------060107050103020406080307-- From harald@alvestrand.no Fri Apr 15 06:12:47 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E60B4E0843 for ; Fri, 15 Apr 2011 06:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvXMXYwgcYov for ; Fri, 15 Apr 2011 06:12:46 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfc.amsl.com (Postfix) with ESMTP id 8BF6FE0842 for ; Fri, 15 Apr 2011 06:12:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C0F1B39E0FD; Fri, 15 Apr 2011 15:12:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsDl8K7jORw4; Fri, 15 Apr 2011 15:12:02 +0200 (CEST) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 6AF0739E072; Fri, 15 Apr 2011 15:12:02 +0200 (CEST) Message-ID: <4DA84449.8090904@alvestrand.no> Date: Fri, 15 Apr 2011 15:12:41 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Magnus Westerlund References: <4D9EF7D3.1040806@alvestrand.no> <1D64F821-8D2B-4983-9989-F3EE076583E3@phonefromhere.com> <4DA7F6E3.6010100@ericsson.com> In-Reply-To: <4DA7F6E3.6010100@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: [rtcweb] data-over-RTP vs data-over-datagram (Re: non-media data) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Apr 2011 13:12:48 -0000 On 04/15/11 09:42, Magnus Westerlund wrote: > I don't like all this talk about data over RTP. Generic data over RTP > isn't the most suitable model for a number of reasons which I will come > back to below. From my perspective we do want data transport that > provide a unreliable datagram based transport. That would in my view > include make available to the web application through the API this. And > let the WEBAPP decided what is put in each datagram. However, we clearly > needs some requirements on that datagram service so that it remains safe > and fair when it comes to transport. To me that means requirements such as: > > - Congestion Controlled > - Confidentiality and Integrity Protected > - Providing consent to receive data prior to allow transmission of > substantial amounts of data > - Some type of source authentication to prevent man in the middles This is a good list to keep in mind. I'll return to it. > There is a question of how much additional functionality one likes to > offer around an unreliable datagram transport. I think we need to go > through http://www.rfc-editor.org/rfc/rfc5405.txt and see what is > desired to have as part of the browser implementation and what is left > to the web application to implement. > Then there is the question if we desire to provide additional transport > properties, like reliable datagram, or reliable byte stream modes. There > there exist several possible ways of doing that. Separate protocol > stacks, reliability extension on top of an unreliable datagram transport > etc. I also think it is important that we do discuss what requirements > exist for each of the transport properties. > > I promised to return to why I think TCP over RTP or more general, > generic data over RTP isn't the most suitable model. > - RTP is a protocol built towards real-time media. Yes the definition of > media can be pretty loose here. But carrying the individual datagrams of > a TCP connection over RTP is plainly stupid, when TCP over UDP will get > you all the desired functionality anyway with less overhead. RTP is, in the extreme view, a ~12-byte header and a set of handling rules. We should look at what it is, not so much what it was originally thought to be designed for (a component in a framework for multicast distribution of unidirectional media channels). > - RTP requires RTP payload formats for anything it carries. That is to > ensure that the application level framing ideas are as well captured for > a particular media encoding as possible. That optimization is not > possible for general data. I think "general data" is a red herring. We can define a few different data-carrying "modes" that have different properties; if some of these are useful, I think it makes sense to define them. > - If one can't do general optimization one goes with more general > transport solutions, thus why not use a more general data transport for > the general data? Pushing stuff towards a "more general data transport" requires one of two things: a) having an existing more general data transport that fulfils our requirements b) defining a new more general data transport that fulfils our requirements The second seems tough. The first ..... what's your preferred candidate? > - RTP and RTCP monitoring is also designed with more continous medias in > mind. Here we don't know how much such properties will be true. Also the > congestion controls available might actually have not the most suitable > properties for certain type of data. It's not clear to me that there *are* congestion controls available (other than media-specific ones). Which ones are you thinking of? Now, the flipside: What does RTP *have* that we will otherwise need to define? From your earlier list: - Congestion Controlled: eh... maybe not. - Confidentiality and Integrity Protected - done, we've got SRTP. - Providing consent to receive data prior to allow transmission of substantial amounts of data - done, we have ICE, and need it for media too. - Some type of source authentication to prevent man in the middles - done, we have SRTP So apart from congestion control, it seems that RTP's 12-byte header actually gives us a lot. >> If we expose raw transport as a lower-level API, then RTP sessions and >> generic sessions can make use of this transport service. >> > I understand your thinking, but there is important to remember that the > NAT/FW traversal solution is likely needing to operate on top of the > bottom most transport protocol, most likely UDP. On top of that we have > thus may ICE's STUN servers multiplexed with one RTP session on the same > 5-tuple. Isn't it likely that one will from an API perspective request > an RTP sessison to be established to the peer with a certain set of RTP > payload types to carry a particular media type for a particular purpose. If that's the API, we've got an RTP-level API (the RTP machinery is below the API). I believe Justin was talking about a lower-level API, where the RTP-level machinery would be above it. Dropping the rest of the message ... this note is already long enough. From magnus.westerlund@ericsson.com Fri Apr 15 07:28:43 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A291AE0670 for ; Fri, 15 Apr 2011 07:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.554 X-Spam-Level: X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGErpRIyu6gA for ; Fri, 15 Apr 2011 07:28:41 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id C279DE0745 for ; Fri, 15 Apr 2011 07:28:40 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-45-4da85617e997 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 11.C6.09202.71658AD4; Fri, 15 Apr 2011 16:28:39 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Fri, 15 Apr 2011 16:28:39 +0200 Message-ID: <4DA85617.1090506@ericsson.com> Date: Fri, 15 Apr 2011 16:28:39 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Harald Alvestrand References: <4D9EF7D3.1040806@alvestrand.no> <1D64F821-8D2B-4983-9989-F3EE076583E3@phonefromhere.com> <4DA7F6E3.6010100@ericsson.com> <4DA84449.8090904@alvestrand.no> In-Reply-To: <4DA84449.8090904@alvestrand.no> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] data-over-RTP vs data-over-datagram (Re: non-media data) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Apr 2011 14:28:43 -0000 Haralad and other interested Snipped out more parts as I added quite a lot around possible alternatives for you to think about. See below Harald Alvestrand skrev 2011-04-15 15:12: >> I promised to return to why I think TCP over RTP or more general, >> generic data over RTP isn't the most suitable model. >> - RTP is a protocol built towards real-time media. Yes the definition of >> media can be pretty loose here. But carrying the individual datagrams of >> a TCP connection over RTP is plainly stupid, when TCP over UDP will get >> you all the desired functionality anyway with less overhead. > RTP is, in the extreme view, a ~12-byte header and a set of handling > rules. We should look at what it is, not so much what it was originally > thought to be designed for (a component in a framework for multicast > distribution of unidirectional media channels). Well, the handling rules include RTCP and an intention to handle a number of different topologies with multi-party handling. There are also additional signalling issues, like how to configure the RTCP bandwidth value, which features to use and all these things. Things you may not need for your data transport. If you need them, you anyway should define an RTP payload format for your data format. And to be frank, the transport and RAI ADs has been very hesitant to allow any RTP payload format that is defined for just being a bit pipe over RTP. The two reasons for this has been Application level framing principle and the lack of congestion control for RTP. >> - RTP requires RTP payload formats for anything it carries. That is to >> ensure that the application level framing ideas are as well captured for >> a particular media encoding as possible. That optimization is not >> possible for general data. > I think "general data" is a red herring. We can define a few different > data-carrying "modes" that have different properties; if some of these > are useful, I think it makes sense to define them. I agree that different transport protocol provides different properties. And that you should chose the one most appropriate. However, one usually has to compromise on some aspects, either by needing to do specific solution for ones data or accept some other potential limitation. On a high level comparisons between our transport protocols I think can be summarized like this: TCP: unicast only, congestion controlled reliable byte stream SCTP: unicast, multihoming, congestion controlled, reliable and unreliable, message oriented. DCCP: unicast, unreliable, congestion controlled sequence numbered datagram RTP/UDP: unicast and multicast, unreliable, RTP payload of single MTU size, medium time scale transport feedback. UDP: unicast and multicast, unreliable, datagram >> - If one can't do general optimization one goes with more general >> transport solutions, thus why not use a more general data transport for >> the general data? > Pushing stuff towards a "more general data transport" requires one of > two things: > a) having an existing more general data transport that fulfils our > requirements > b) defining a new more general data transport that fulfils our requirements > The second seems tough. The first ..... what's your preferred candidate? Actually the one I think is easiest from a specification point of view and that does provide a reasonable service for unreliable datagrams are: DTLS/DCCP/UDP That would be the following references: https://datatracker.ietf.org/doc/rfc4340/ (Base Spec) https://datatracker.ietf.org/doc/rfc4341/ (TCP-Like CC) https://datatracker.ietf.org/doc/rfc4342/ (TFRC CC) https://datatracker.ietf.org/doc/rfc5238/ (DTLS for DCCP) https://datatracker.ietf.org/doc/draft-ietf-dccp-udpencap/ (DCCP over UDP) My main concern is the maturity of available implementations of DCCP. Otherwise it provides congestion control and can actually choose which congestion control algorithms we want supported, TCP-like or TFRC. It also have some additional features. One is that we get a second port space providing additional multiplexing points. Please note that this is just a friendly suggestion. At least check it out, and possible post some comments why it would be unsuitable. >> - RTP and RTCP monitoring is also designed with more continous medias in >> mind. Here we don't know how much such properties will be true. Also the >> congestion controls available might actually have not the most suitable >> properties for certain type of data. > It's not clear to me that there *are* congestion controls available > (other than media-specific ones). > Which ones are you thinking of? The one that is full defined is to run RTP over DCCP. https://datatracker.ietf.org/doc/rfc5762/ I guess the biggest issue is the lack of experience with this and especially how you interface the DCCP stack to work well between media encoding, RTP stack and the DCCP congestion control. The alternative, not standardized yet but closest available for RTP over UDP is TFRC for RTP. https://datatracker.ietf.org/doc/draft-gharai-avtcore-rtp-tfrc/ That was in reasonable shape prior to its abandonment due to lack of funding from the ones driving it. > Now, the flipside: What does RTP *have* that we will otherwise need > to define? From your earlier list: > > - Congestion Controlled: eh... maybe not. > - Confidentiality and Integrity Protected - done, we've got SRTP. > - Providing consent to receive data prior to allow transmission of > substantial amounts of data - done, we have ICE, > and need it for media too. > - Some type of source authentication to prevent man in the middles > - done, we have SRTP > > So apart from congestion control, it seems that RTP's 12-byte header > actually gives us a lot. Well, the security parts can be provided by ICE and DTLS over UDP also. we still are short the congestion control for such a thing plus all these things that the UDP guidelines (RFC5405) discuss. Using RTP over UDP does drag all the RTP baggage into something that may not needed it, but it will provide some parts of what you need. If a particular data format needs RTP functionality, it should define its own RTP payload format anyway. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Apr 18 02:57:24 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A796CE0707 for ; Mon, 18 Apr 2011 02:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGdr+Izp4yL2 for ; Mon, 18 Apr 2011 02:57:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id 7CB82E06C7 for ; Mon, 18 Apr 2011 02:57:20 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-af-4dac0affcd99 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 59.6A.09202.FFA0CAD4; Mon, 18 Apr 2011 11:57:19 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Mon, 18 Apr 2011 11:57:19 +0200 Message-ID: <4DAC0AFE.3000808@ericsson.com> Date: Mon, 18 Apr 2011 11:57:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Harald Alvestrand References: <4DA83346.2060608@alvestrand.no> In-Reply-To: <4DA83346.2060608@alvestrand.no> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: RFC 6222 on Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Apr 2011 09:57:24 -0000 Harald and others, This is just one of many things we recommend in our draft on how RTP should be used in the RTCWEB context. https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/ We do like to get feedback on our document. Harald Alvestrand skrev 2011-04-15 14:00: > Since this RFC effectively tells us that we should abandon the "cname is > user@host" convention, this RFC may be of interest to this WG. > > Of special interest is the explicit statement that a CNAME is used to > identify streams that need to be synchronized between multiple RTP > sessions; I take it that the inverse is also true - that streams that do > not need to be synchronized do not need to have the same CNAME. > Yes, it is mostly true. And if ones intention is to provide sources that you don't want to force synchronization with, then using different CNAMEs are necessary. However, there are a bit of overloading on the CNAME field that makes one have to be a bit careful when using different CNAMEs from the same end-point. And I would like to add that synchronization of SSRCs with the same CNAME is not only between RTP sessions, but also within the RTP session. 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 singer@apple.com Mon Apr 18 11:10:16 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E8E4FE0817 for ; Mon, 18 Apr 2011 11:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnC-dYlnWQOh for ; Mon, 18 Apr 2011 11:10:16 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfc.amsl.com (Postfix) with ESMTP id 1205EE0684 for ; Mon, 18 Apr 2011 11:10:16 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJV00MCP13Q6WO0@mail-out.apple.com> for rtcweb@ietf.org; Mon, 18 Apr 2011 11:10:15 -0700 (PDT) X-AuditID: 11807134-b7c8cae000005108-15-4dac7e87ecc9 Received: from [17.153.52.21] (Unknown_Domain [17.153.52.21]) by relay14.apple.com (Apple SCV relay) with SMTP id 1C.0C.20744.78E7CAD4; Mon, 18 Apr 2011 11:10:15 -0700 (PDT) From: David Singer In-reply-to: <4DAC0AFE.3000808@ericsson.com> Date: Mon, 18 Apr 2011 11:10:14 -0700 Message-id: <8C1CC234-E10B-456A-A85D-2F20CBE0EA89@apple.com> References: <4DA83346.2060608@alvestrand.no> <4DAC0AFE.3000808@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: RFC 6222 on Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Apr 2011 18:10:17 -0000 On Apr 18, 2011, at 2:57 , Magnus Westerlund wrote: > Harald and others, > > This is just one of many things we recommend in our draft on how RTP > should be used in the RTCWEB context. > https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/ > > We do like to get feedback on our document. > > Harald Alvestrand skrev 2011-04-15 14:00: >> Since this RFC effectively tells us that we should abandon the "cname is >> user@host" convention, this RFC may be of interest to this WG. >> >> Of special interest is the explicit statement that a CNAME is used to >> identify streams that need to be synchronized between multiple RTP >> sessions; I take it that the inverse is also true - that streams that do >> not need to be synchronized do not need to have the same CNAME. >> > > Yes, it is mostly true. And if ones intention is to provide sources that > you don't want to force synchronization with, then using different > CNAMEs are necessary. However, there are a bit of overloading on the > CNAME field that makes one have to be a bit careful when using different > CNAMEs from the same end-point. And I would like to add that > synchronization of SSRCs with the same CNAME is not only between RTP > sessions, but also within the RTP session. > > If I am doing a point-to-point call, and I have the connectivity established (i.e. IP addresses and the like), why should I trouble at all with CNAME? And, indeed, are there privacy concerns with it (well, there are with using @, I rather suspect). Can the CNAME problem be handled when aggregation happens? David Singer Multimedia and Software Standards, Apple Inc. From magnus.westerlund@ericsson.com Tue Apr 19 02:05:30 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 38EEBE06A5 for ; Tue, 19 Apr 2011 02:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIG7rwBslOij for ; Tue, 19 Apr 2011 02:05:29 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id 66EC3E06A0 for ; Tue, 19 Apr 2011 02:05:29 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-e3-4dad5058ae18 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E3.C0.09202.8505DAD4; Tue, 19 Apr 2011 11:05:28 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Tue, 19 Apr 2011 11:05:27 +0200 Message-ID: <4DAD5058.70202@ericsson.com> Date: Tue, 19 Apr 2011 11:05:28 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: David Singer References: <4DA83346.2060608@alvestrand.no> <4DAC0AFE.3000808@ericsson.com> <8C1CC234-E10B-456A-A85D-2F20CBE0EA89@apple.com> In-Reply-To: <8C1CC234-E10B-456A-A85D-2F20CBE0EA89@apple.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: RFC 6222 on Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Apr 2011 09:05:30 -0000 David Singer skrev 2011-04-18 20:10: > > If I am doing a point-to-point call, and I have the connectivity > established (i.e. IP addresses and the like), why should I trouble at > all with CNAME? And, indeed, are there privacy concerns with it > (well, there are with using @, I rather suspect). Can > the CNAME problem be handled when aggregation happens? Because you don't know when a peer is a single user, or a conference bridge. In the later case of you will need the cname. Also for point to point you might need it if you have multiple sources that should or should not be synchronized. The point of the new RFC is that the cname can be set session specific, by drawing a random number that is being used. Thus you can avoid the downsides of CNAME from privacy point of view, and the generation aspects. 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 wwwrun@ietfc.amsl.com Tue Apr 19 09:48:04 2011 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfc.amsl.com Received: by ietfc.amsl.com (Postfix, from userid 30) id 27A83E07A8; Tue, 19 Apr 2011 09:48:04 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110419164804.27A83E07A8@ietfc.amsl.com> Date: Tue, 19 Apr 2011 09:48:04 -0700 (PDT) Cc: rtcweb@ietf.org Subject: [rtcweb] WG Review: Real-Time Communication in WEB-browsers (rtcweb) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: iesg@ietf.org List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 16:48:04 -0000 A new IETF working group has been proposed in the Real-Time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, April 26, 2011. Real-Time Communication in WEB-browsers (rtcweb) ------------------------------------------------ Current Status: Proposed Working Group Last Updated: 2011-04-14 Chairs: TBD RAI Area Directors: Gonzalo Camarillo Robert Sparks RAI Area Advisor: Gonzalo Camarillo Mailing Lists: Address: rtcweb@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rtcweb Archive: http://www.ietf.org/mail-archive/web/rtcweb/ Description of Working Group: There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable data transfer directly between clients. This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identify state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components. We will reach out to the developer community for consultation and early feedback on implementation. The security and privacy goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly need extensions, additions or replacement, and thus some support for negotiation between clients is required. The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security and privacy goals and specifies the security protocol mechanisms necessary to achieve those goals. 3. Define the solution - protocols and API requirements - for firewall and NAT traversal. 4. Define which media functions and extensions shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non media data is transported between clients in a secure and congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution. 9. The group will consider options for interworking with legacy VoIP equipment. This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG: RTSP, RSVP, NSIS, Location services, Resource Priority, and IM & Presence specific features. The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers. Milestones: Aug 2011 Architecture, Security, Privacy and Threat Model sent to W3C Aug 2011 Use cases, Scenarios, and Requirements document (I-D) sent to W3C Sep 2011 Architecture and Security, Privacy, and Threat Model document(s) to IESG as Informational Sep 2011 Use cases, Scenarios, and Requirements for RTCWeb document sent to IESG as Informational Dec 2011 RTCWeb protocol profiles and Media format specification(s) to IESG as PS Dec 2011 Information elements and events APIs Input to W3C Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed) From ron.even.tlv@gmail.com Tue Apr 19 21:39:38 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 651C3E06C7; Tue, 19 Apr 2011 21:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVhS2+4U+Kcd; Tue, 19 Apr 2011 21:39:37 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id AE85BE0611; Tue, 19 Apr 2011 21:39:36 -0700 (PDT) Received: by wwa36 with SMTP id 36so284792wwa.13 for ; Tue, 19 Apr 2011 21:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=QUFn44erOLifqSwRzGePQXO1y39wPF2VdYsB3n9HZME=; b=tFT6bOhZf/yi1Q+N0e2ou9Ju/b/6+211+lI51WFnTmP387j1lCNdXctBN2DpQG0DYN AjcIY+XulBKgdpqJtVcRN3bVhWL1EcKUEkYBtPJHkPN0caSFBcQAx7rcB0bMTrqoJzEr XpUgaoAYI9HjuYQsVdFkoK6J35t95jsOa3CR8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=xlTxvAL5rwDpHK0BXeWwnh8KzOYhPbaj3VK8SPGGHOjczWW2KGwUHLkIb5ZNMYuOUd U21yu16WiRlz4tncYBjuqa6WCQaD7c3a0+9YHJ0xg3kacVfPKufK92yvBd0hNSx4UFxE UCdibSe857bDs8Sx3bpCUbiFF5NyCwq79y3QI= Received: by 10.216.123.74 with SMTP id u52mr6643799weh.24.1303274374230; Tue, 19 Apr 2011 21:39:34 -0700 (PDT) Received: from windows8d787f9 (bzq-79-181-29-160.red.bezeqint.net [79.181.29.160]) by mx.google.com with ESMTPS id f52sm239555wes.11.2011.04.19.21.39.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 21:39:32 -0700 (PDT) From: "Roni Even" To: References: <20110419164804.27A83E07A8@ietfc.amsl.com> In-Reply-To: <20110419164804.27A83E07A8@ietfc.amsl.com> Date: Wed, 20 Apr 2011 07:38:30 +0300 Message-ID: <4dae6384.cafdd80a.562d.14f1@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv+sZCrKaPBP5b9TaCOhOaHxly/6gAYirZg Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WG Review: Real-Time Communication in WEB-browsers (rtcweb) - Mandatory media formats X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 04:39:38 -0000 Hi, I think that during the RTCweb ad-hoc on Friday meeting there was no consensus if the proposed WG should specify which media format MUST or Should be used. So I am not sure why the charter has item 6 in the work to do as well about the deliverables of media format specifications. Thanks Roni Even > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of IESG Secretary > Sent: Tuesday, April 19, 2011 7:48 PM > To: IETF Announcement list > Cc: rtcweb@ietf.org > Subject: [rtcweb] WG Review: Real-Time Communication in WEB-browsers > (rtcweb) > > A new IETF working group has been proposed in the Real-Time > Applications > and Infrastructure Area. The IESG has not made any determination as > yet. > The following draft charter was submitted, and is provided for > informational purposes only. Please send your comments to the IESG > mailing > list (iesg@ietf.org) by Tuesday, April 26, 2011. > > > Real-Time Communication in WEB-browsers (rtcweb) > ------------------------------------------------ > Current Status: Proposed Working Group > Last Updated: 2011-04-14 > > Chairs: > TBD > > RAI Area Directors: > Gonzalo Camarillo > Robert Sparks > > RAI Area Advisor: > Gonzalo Camarillo > > Mailing Lists: > Address: rtcweb@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/rtcweb > Archive: http://www.ietf.org/mail-archive/web/rtcweb/ > > Description of Working Group: > > There are a number of proprietary implementations that provide direct > interactive rich communication using audio, video, collaboration, > games, etc. between two peers' web-browsers. These are not > interoperable, as they require non-standard extensions or plugins to > work. There is a desire to standardize the basis for such > communication so that interoperable communication can be established > between any compatible browsers. The goal is to enable innovation on > top of a set of basic components. One core component is to enable > real-time media like audio and video, a second is to enable data > transfer directly between clients. > > This work will be done in collaboration with the W3C. The IETF WG > will produce architecture and requirements for selection and profiling > of the on the wire protocols. The architecture needs to be coordinated > with W3C. The IETF WG work will identify state information and events > that need to be exposed in the APIs as input to W3C. The W3C will be > responsible for defining APIs to ensure that application developers > can control the components. We will reach out to the developer > community for consultation and early feedback on implementation. > > The security and privacy goals and requirements will be developed by > the WG. The security model needs to be coordinated with the W3C. The > work will also consider where support for extensibility is needed. RTP > functionalities, media formats, security algorithms are example of > things that commonly need extensions, additions or replacement, and > thus some support for negotiation between clients is required. > > The WG will perform the following work: > > 1. Define the communication model in detail, including how session > management is to occur within the model. > > 2. Define a security model that describes the security and privacy > goals and specifies the security protocol mechanisms necessary > to achieve those goals. > > 3. Define the solution - protocols and API requirements - for > firewall and NAT traversal. > > 4. Define which media functions and extensions shall be supported in > the client and their usage for real-time media, including media > adaptation to ensure congestion safe usage. > > 5. Define what functionalities in the solution, such as media codecs, > security algorithms, etc., can be extended and how the > extensibility mechanisms works. > > 6. Define a set of media formats that must or should be supported by > a client to improve interoperability. > > 7. Define how non media data is transported between clients in a > secure and congestion safe way. > > 8. Provide W3C input for the APIs that comes from the communication > model and the selected components and protocols that are part of > the solution. > > 9. The group will consider options for interworking with legacy VoIP > equipment. > > This work will be done primarily by using already defined protocols or > functionalities. If there is identification of missing protocols or > functionalities, such work can be requested to be done in another > working group with a suitable charter or by requests for chartering it > in this WG or another WG. The following topics will be out of scope > for the initial phase of the WG: RTSP, RSVP, NSIS, Location services, > Resource Priority, and IM & Presence specific features. > > The products of the working group will support security and keying as > required by BCP 61 and be defined for IPv4, IPv6, and dual stack > deployments. The Working Group will consider the possibility of > defining a browser component that implements an existing session > negotiation and management protocol. The working group will follow BCP > 79, and adhere to the spirit of BCP 79. The working group cannot > explicitly rule out the possibility of adopting encumbered > technologies; however, the working group will try to avoid encumbered > technologies that require royalties or other encumbrances that would > prevent such technologies from being easy to use in web browsers. > > Milestones: > > Aug 2011 Architecture, Security, Privacy and Threat Model sent to W3C > > Aug 2011 Use cases, Scenarios, and Requirements document (I-D) sent to > W3C > > Sep 2011 Architecture and Security, Privacy, and Threat Model > document(s) to IESG as Informational > > Sep 2011 Use cases, Scenarios, and Requirements for RTCWeb document > sent to IESG as Informational > > Dec 2011 RTCWeb protocol profiles and Media format specification(s) to > IESG as PS > > Dec 2011 Information elements and events APIs Input to W3C > > Apr 2012 API to Protocol mapping document submitted to the IESG as > Informational (if needed) > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ron.even.tlv@gmail.com Tue Apr 19 22:27:22 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 440E7E0690 for ; Tue, 19 Apr 2011 22:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+qdkR7UBJjS for ; Tue, 19 Apr 2011 22:27:21 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 5A20BE0670 for ; Tue, 19 Apr 2011 22:27:21 -0700 (PDT) Received: by wwa36 with SMTP id 36so301676wwa.13 for ; Tue, 19 Apr 2011 22:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=k9fBHNHtuCzX5Jro3CBRIqE4Nb0ePKCy9aHVGQLMWqM=; b=WYrEzYgqMWQBmACtxniseEiGWhFy9lVBI6Em0RNRKZh7/7haZ4l9qqGbeSuZ3shga5 imKOF52G4gamoKnUbfj1KHbs+Gwp23RImGK4yUdrKt8eE0VGenzkX5bLXvJutdjCgET4 GUHRCQFZhdIH16c2TlfaSp/SleY3ITJxhT0YY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=TyfPCh/524NBTHRn3FocvhT67jBK2351XECQ10Ij4QhuhsK3oUbSBAz8PonRHnQsE3 QogOULqmO91HOfHbRCh3oYDR/lVHx3vrlAkURojAiTWKhnJZsmWUvoP+5FprberHnyu8 4NpP7yKVsuBtxdrNoWlYo6F5zUHcefc18XO0w= Received: by 10.216.12.146 with SMTP id 18mr318322wez.63.1303277240674; Tue, 19 Apr 2011 22:27:20 -0700 (PDT) Received: from windows8d787f9 (bzq-79-181-29-160.red.bezeqint.net [79.181.29.160]) by mx.google.com with ESMTPS id x1sm329209wbh.19.2011.04.19.22.27.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 22:27:18 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , "'David Singer'" References: <4DA83346.2060608@alvestrand.no> <4DAC0AFE.3000808@ericsson.com> <8C1CC234-E10B-456A-A85D-2F20CBE0EA89@apple.com> <4DAD5058.70202@ericsson.com> In-Reply-To: <4DAD5058.70202@ericsson.com> Date: Wed, 20 Apr 2011 08:26:15 +0300 Message-ID: <4dae6eb6.813ee30a.2783.1af8@mx.google.com> 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: Acv+cPH+iNC4f56OTKKcFpzn79/wXAAqlhcQ Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: RFC 6222 on Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 05:27:22 -0000 Hi, I think that CNAMEs are also useful for third party monitors as = described in RFC 3550 Roni Even > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Magnus Westerlund > Sent: Tuesday, April 19, 2011 12:05 PM > To: David Singer > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Fwd: RFC 6222 on Guidelines for Choosing RTP > Control Protocol (RTCP) Canonical Names (CNAMEs) >=20 > David Singer skrev 2011-04-18 20:10: > > > > If I am doing a point-to-point call, and I have the connectivity > > established (i.e. IP addresses and the like), why should I trouble = at > > all with CNAME? And, indeed, are there privacy concerns with it > > (well, there are with using @, I rather suspect). Can > > the CNAME problem be handled when aggregation happens? >=20 > Because you don't know when a peer is a single user, or a conference > bridge. In the later case of you will need the cname. Also for point = to > point you might need it if you have multiple sources that should or > should not be synchronized. The point of the new RFC is that the cname > can be set session specific, by drawing a random number that is being > used. Thus you can avoid the downsides of CNAME from privacy point of > view, and the generation aspects. >=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 > ---------------------------------------------------------------------- > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Wed Apr 20 02:16:06 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B5FF4E068B; Wed, 20 Apr 2011 02:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTAa77KPCC0z; Wed, 20 Apr 2011 02:16:06 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfc.amsl.com (Postfix) with ESMTP id C4557E067C; Wed, 20 Apr 2011 02:16:05 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-25-4daea45419c8 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 17.4D.11171.454AEAD4; Wed, 20 Apr 2011 11:16:04 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Wed, 20 Apr 2011 11:16:04 +0200 Message-ID: <4DAEA453.7030708@ericsson.com> Date: Wed, 20 Apr 2011 11:16:03 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Roni Even References: <20110419164804.27A83E07A8@ietfc.amsl.com> <4dae6384.cafdd80a.562d.14f1@mx.google.com> In-Reply-To: <4dae6384.cafdd80a.562d.14f1@mx.google.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , "iesg@ietf.org" Subject: Re: [rtcweb] WG Review: Real-Time Communication in WEB-browsers (rtcweb) - Mandatory media formats X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 09:16:06 -0000 Roni Even skrev 2011-04-20 06:38: > Hi, > I think that during the RTCweb ad-hoc on Friday meeting there was no > consensus if the proposed WG should specify which media format MUST or > Should be used. So I am not sure why the charter has item 6 in the work to > do as well about the deliverables of media format specifications. Roni, I don't quite understand your comment. Yes, there was discussion and there is yet no consensus nor proposal on what media formats there should be selected nor the level of required support in implementations. But if you re-read bullet 6 from the charter: >> 6. Define a set of media formats that must or should be supported by >> a client to improve interoperability. You see that the charter item has quite a lot of wiggle room for the WG to define what level a produced list applies to the implementations. Am I misunderstanding your comment? cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ron.even.tlv@gmail.com Wed Apr 20 03:47:47 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6DA34E0695; Wed, 20 Apr 2011 03:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Vb65Y9tquI4; Wed, 20 Apr 2011 03:47:46 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfc.amsl.com (Postfix) with ESMTP id 85127E0689; Wed, 20 Apr 2011 03:47:46 -0700 (PDT) Received: by wwk4 with SMTP id 4so3919655wwk.1 for ; Wed, 20 Apr 2011 03:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=M8qqeq2TBhhQK4MmKRQ4Inni4lGiDN7TIRpQq/rW/Ws=; b=kDl+X5DhGn4LHKqG/NJsSO0QjQuItqACq3j2+1eqrJ6HxPyYsZv5/aNlCbJA+nczO4 frWZwicfMS3cV4MqpB6RP4Q30HuYAYJEGU4ctSoS5jz2ebZcvku8RxT+IUswDdSWsJcO 23+CWrsq5QGeXo+p40RXai43UsHX06cT17KQI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=IHzU7HO+guU+FMLzZ0sxUQcuiBG85XW0INPOPDNFa4Rjn2k7jykFefihzzR5iSEwcp a3sxEvPvMgDxZ/Xed3r6Sn04cNNgp2UeKSuXHxTkNVb2BLYTRG4VaFiPdmvC4JNYoMeI nsYB6wRobPwZqGuUJSuyg6/ylW3bqlmYfmb6c= Received: by 10.227.206.84 with SMTP id ft20mr5476725wbb.161.1303296465573; Wed, 20 Apr 2011 03:47:45 -0700 (PDT) Received: from windows8d787f9 (bzq-79-181-29-160.red.bezeqint.net [79.181.29.160]) by mx.google.com with ESMTPS id h11sm483228wbc.43.2011.04.20.03.47.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2011 03:47:43 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" References: <20110419164804.27A83E07A8@ietfc.amsl.com> <4dae6384.cafdd80a.562d.14f1@mx.google.com> <4DAEA453.7030708@ericsson.com> In-Reply-To: <4DAEA453.7030708@ericsson.com> Date: Wed, 20 Apr 2011 13:46:39 +0300 Message-ID: <4daeb9cf.4b1be30a.7bf2.2b5f@mx.google.com> 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: Acv/O5UcbQpdwg0rSpm2ZgsYgs0cyAADG6RQ Content-Language: en-us Cc: rtcweb@ietf.org, iesg@ietf.org Subject: Re: [rtcweb] WG Review: Real-Time Communication in WEB-browsers (rtcweb) - Mandatory media formats X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 10:47:47 -0000 Magnus, OK, no problem if this is the meaning. Maybe I have not understood. Roni > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, April 20, 2011 12:16 PM > To: Roni Even > Cc: iesg@ietf.org; rtcweb@ietf.org > Subject: Re: [rtcweb] WG Review: Real-Time Communication in WEB- > browsers (rtcweb) - Mandatory media formats >=20 > Roni Even skrev 2011-04-20 06:38: > > Hi, > > I think that during the RTCweb ad-hoc on Friday meeting there was no > > consensus if the proposed WG should specify which media format MUST > or > > Should be used. So I am not sure why the charter has item 6 in the > work to > > do as well about the deliverables of media format specifications. >=20 > Roni, >=20 > I don't quite understand your comment. Yes, there was discussion and > there is yet no consensus nor proposal on what media formats there > should be selected nor the level of required support in > implementations. >=20 > But if you re-read bullet 6 from the charter: >=20 > >> 6. Define a set of media formats that must or should be supported > by > >> a client to improve interoperability. >=20 > You see that the charter item has quite a lot of wiggle room for the = WG > to define what level a produced list applies to the implementations. >=20 > Am I misunderstanding your comment? >=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 > ---------------------------------------------------------------------- From harald@alvestrand.no Wed Apr 27 05:18:59 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A34E069A for ; Wed, 27 Apr 2011 05:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISzTIHcbaoHX for ; Wed, 27 Apr 2011 05:18:49 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AA90FE06A3 for ; Wed, 27 Apr 2011 05:18:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EC26739E0BC; Wed, 27 Apr 2011 14:18:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbiUVXjcHxVw; Wed, 27 Apr 2011 14:17:58 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 7B96939E08B; Wed, 27 Apr 2011 14:17:58 +0200 (CEST) Message-ID: <4DB809A3.9090102@alvestrand.no> Date: Wed, 27 Apr 2011 14:18:43 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Magnus Westerlund References: <4D9EF7D3.1040806@alvestrand.no> <1D64F821-8D2B-4983-9989-F3EE076583E3@phonefromhere.com> <4DA7F6E3.6010100@ericsson.com> <4DA84449.8090904@alvestrand.no> <4DA85617.1090506@ericsson.com> In-Reply-To: <4DA85617.1090506@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] data-over-RTP vs data-over-datagram (Re: non-media data) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 12:18:59 -0000 Returning to this thread after a few weeks.... I'm still being contrary=20 to make sure we have all the issues explicit where they need to be...=20 and I do hope that some of the people who actually want to send data=20 (instead of us types who speculate about what you possibly might want)=20 can speak up! On 04/15/11 16:28, Magnus Westerlund wrote: > Haralad and other interested > > Snipped out more parts as I added quite a lot around possible > alternatives for you to think about. See below > > Harald Alvestrand skrev 2011-04-15 15:12: >>> I promised to return to why I think TCP over RTP or more general, >>> generic data over RTP isn't the most suitable model. >>> - RTP is a protocol built towards real-time media. Yes the definition= of >>> media can be pretty loose here. But carrying the individual datagrams= of >>> a TCP connection over RTP is plainly stupid, when TCP over UDP will g= et >>> you all the desired functionality anyway with less overhead. >> RTP is, in the extreme view, a ~12-byte header and a set of handling >> rules. We should look at what it is, not so much what it was originall= y >> thought to be designed for (a component in a framework for multicast >> distribution of unidirectional media channels). > Well, the handling rules include RTCP and an intention to handle a > number of different topologies with multi-party handling. There are als= o > additional signalling issues, like how to configure the RTCP bandwidth > value, which features to use and all these things. Things you may not > need for your data transport. If you need them, you anyway should defin= e > an RTP payload format for your data format. If these questions have fixed answers in a specific scenario (like=20 point-to-point), they can be handled by specifying a set of reasonable=20 values for that scenario. > And to be frank, the transport and RAI ADs has been very hesitant to > allow any RTP payload format that is defined for just being a bit pipe > over RTP. The two reasons for this has been Application level framing > principle and the lack of congestion control for RTP. I do wonder about the ALF principle. In some ways, it seems reasonable=20 under ALF that one should be able to use a framing mechanism that=20 provides some of what we want without necessarily worrying that it=20 provides more than what we want... The congestion control is definitely an issue. With RTCWEB deployment=20 likely to increase the amount of media streams encountering congestion=20 significantly, I think we have to address this in a way that's=20 applicable to RTP in general - but that's an AVTCORE matter, not an=20 RTCWEB matter, I think. >>> - RTP requires RTP payload formats for anything it carries. That is t= o >>> ensure that the application level framing ideas are as well captured = for >>> a particular media encoding as possible. That optimization is not >>> possible for general data. >> I think "general data" is a red herring. We can define a few different= >> data-carrying "modes" that have different properties; if some of these= >> are useful, I think it makes sense to define them. > I agree that different transport protocol provides different properties= =2E > And that you should chose the one most appropriate. However, one usuall= y > has to compromise on some aspects, either by needing to do specific > solution for ones data or accept some other potential limitation. On a > high level comparisons between our transport protocols I think can be > summarized like this: > > TCP: unicast only, congestion controlled reliable byte stream Also: Implemented in kernels, allowed through firewalls,=20 double-NAT-traversal fails frequently. > SCTP: unicast, multihoming, congestion controlled, reliable and > unreliable, message oriented. Also: Not implemented in kernels, firewalls know nothing of it (unless=20 UDP encapsulated). NAT boxes know nothing about it (so UDP encapsulation = seems a must). > DCCP: unicast, unreliable, congestion controlled sequence numbered data= gram The "also" list here is the same as for SCTP, I think. > RTP/UDP: unicast and multicast, unreliable, RTP payload of single MTU > size, medium time scale transport feedback. > > UDP: unicast and multicast, unreliable, datagram Properties of traversal of firewalls and NAT boxes are well known.=20 Kernel implemented. >>> - If one can't do general optimization one goes with more general >>> transport solutions, thus why not use a more general data transport f= or >>> the general data? >> Pushing stuff towards a "more general data transport" requires one of >> two things: >> a) having an existing more general data transport that fulfils our >> requirements >> b) defining a new more general data transport that fulfils our require= ments >> The second seems tough. The first ..... what's your preferred candidat= e? > Actually the one I think is easiest from a specification point of view > and that does provide a reasonable service for unreliable datagrams are= : > > DTLS/DCCP/UDP > > That would be the following references: > https://datatracker.ietf.org/doc/rfc4340/ (Base Spec) > https://datatracker.ietf.org/doc/rfc4341/ (TCP-Like CC) > https://datatracker.ietf.org/doc/rfc4342/ (TFRC CC) > https://datatracker.ietf.org/doc/rfc5238/ (DTLS for DCCP) > https://datatracker.ietf.org/doc/draft-ietf-dccp-udpencap/ (DCCP over U= DP) > > My main concern is the maturity of available implementations of DCCP. > Otherwise it provides congestion control and can actually choose which > congestion control algorithms we want supported, TCP-like or TFRC. It > also have some additional features. One is that we get a second port > space providing additional multiplexing points. > > Please note that this is just a friendly suggestion. At least check it > out, and possible post some comments why it would be unsuitable. In a design point spectrum where Ian Hixie's 44-byte datagram header,=20 this proposal and a "data-over-RTP" proposal are the 3 candidates, we=20 should have enough design points that we can start discussing the=20 criteria we evaluate them against (often a good thing). >>> - RTP and RTCP monitoring is also designed with more continous medias= in >>> mind. Here we don't know how much such properties will be true. Also = the >>> congestion controls available might actually have not the most suitab= le >>> properties for certain type of data. >> It's not clear to me that there *are* congestion controls available >> (other than media-specific ones). >> Which ones are you thinking of? > The one that is full defined is to run RTP over DCCP. > https://datatracker.ietf.org/doc/rfc5762/ > > I guess the biggest issue is the lack of experience with this and > especially how you interface the DCCP stack to work well between media > encoding, RTP stack and the DCCP congestion control. If we buy DCCP anyway, this is certainly worth investigating. > The alternative, not standardized yet but closest available for RTP ove= r > UDP is TFRC for RTP. > https://datatracker.ietf.org/doc/draft-gharai-avtcore-rtp-tfrc/ > > That was in reasonable shape prior to its abandonment due to lack of > funding from the ones driving it. Does anyone want to pick it up and see what's missing? > >> Now, the flipside: What does RTP *have* that we will otherwise need >> to define? From your earlier list: >> >> - Congestion Controlled: eh... maybe not. >> - Confidentiality and Integrity Protected - done, we've got SRTP. >> - Providing consent to receive data prior to allow transmission of >> substantial amounts of data - done, we have ICE, >> and need it for media too. >> - Some type of source authentication to prevent man in the middles >> - done, we have SRTP >> >> So apart from congestion control, it seems that RTP's 12-byte header >> actually gives us a lot. > Well, the security parts can be provided by ICE and DTLS over UDP also.= > we still are short the congestion control for such a thing plus all > these things that the UDP guidelines (RFC5405) discuss. Using RTP over > UDP does drag all the RTP baggage into something that may not needed it= , > but it will provide some parts of what you need. If a particular data > format needs RTP functionality, it should define its own RTP payload > format anyway. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > From hoene@uni-tuebingen.de Wed Apr 27 10:48:48 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BA2E07E6 for ; Wed, 27 Apr 2011 10:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=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 6eZHjLIM5Msw for ; Wed, 27 Apr 2011 10:48:47 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by ietfa.amsl.com (Postfix) with ESMTP id B5C97E076E for ; Wed, 27 Apr 2011 10:48:46 -0700 (PDT) Received: from hoeneT60 (p5B2014E0.dip0.t-ipconnect.de [91.32.20.224]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id p3RHmZAH000523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Apr 2011 19:48:42 +0200 From: "Christian Hoene" To: "'Harald Alvestrand'" References: <4D9EF7D3.1040806@alvestrand.no> <1D64F821-8D2B-4983-9989-F3EE076583E3@phonefromhere.com> <4DA7F6E3.6010100@ericsson.com> <4DA84449.8090904@alvestrand.no> <4DA85617.1090506@ericsson.com> <4DB809A3.9090102@alvestrand.no> In-Reply-To: <4DB809A3.9090102@alvestrand.no> Date: Wed, 27 Apr 2011 19:48:37 +0200 Organization: =?UTF-8?Q?Universit=C3=A4t_T=C3=BCbingen?= Message-ID: <000001cc0503$5ab03580$1010a080$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLbRDMFYe9TRnJrpSqIEE/5zFzb2gFoobYsAaKqolIC4V+O4gKih1/yAlP5B+IBSU97tQE5DiEfAn75TJQCB55auJHEFe6w Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.1.2; host: mx06) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] data-over-RTP vs data-over-datagram (Re: non-media data) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 17:48:48 -0000 > Returning to this thread after a few weeks.... I'm still being = contrary > to make sure we have all the issues explicit where they need to be... > and I do hope that some of the people who actually want to send data > (instead of us types who speculate about what you possibly might want) > can speak up! [Christian Hoene] Most RTP payload formats are for audio or video. I = have not seen that RTP is just for other real time data such as GPS, = location, orientation, input devices (mouse, kinect, etc...) or gaming = data. Thus, I do not see that data over RTP is an option that is well = supported. Real-time-Data-over-RTP seems not to be in the = standardization traditions of AVT. Of course, this might change at some = point in future. Until then, I would suggest to support a plain = real-time-data-over-datagram option, as we do not have to follow = standards anyhow to support non-media data over whatsoever.=20 Spoken up, Christian >=20 > On 04/15/11 16:28, Magnus Westerlund wrote: > > Haralad and other interested > > > > Snipped out more parts as I added quite a lot around possible > > alternatives for you to think about. See below > > > > Harald Alvestrand skrev 2011-04-15 15:12: > >>> I promised to return to why I think TCP over RTP or more general, > >>> generic data over RTP isn't the most suitable model. > >>> - RTP is a protocol built towards real-time media. Yes the = definition of > >>> media can be pretty loose here. But carrying the individual = datagrams of > >>> a TCP connection over RTP is plainly stupid, when TCP over UDP = will get > >>> you all the desired functionality anyway with less overhead. > >> RTP is, in the extreme view, a ~12-byte header and a set of = handling > >> rules. We should look at what it is, not so much what it was = originally > >> thought to be designed for (a component in a framework for = multicast > >> distribution of unidirectional media channels). > > Well, the handling rules include RTCP and an intention to handle a > > number of different topologies with multi-party handling. There are = also > > additional signalling issues, like how to configure the RTCP = bandwidth > > value, which features to use and all these things. Things you may = not > > need for your data transport. If you need them, you anyway should = define > > an RTP payload format for your data format. > If these questions have fixed answers in a specific scenario (like > point-to-point), they can be handled by specifying a set of reasonable > values for that scenario. > > And to be frank, the transport and RAI ADs has been very hesitant to > > allow any RTP payload format that is defined for just being a bit = pipe > > over RTP. The two reasons for this has been Application level = framing > > principle and the lack of congestion control for RTP. > I do wonder about the ALF principle. In some ways, it seems reasonable > under ALF that one should be able to use a framing mechanism that > provides some of what we want without necessarily worrying that it > provides more than what we want... >=20 > The congestion control is definitely an issue. With RTCWEB deployment > likely to increase the amount of media streams encountering congestion > significantly, I think we have to address this in a way that's > applicable to RTP in general - but that's an AVTCORE matter, not an > RTCWEB matter, I think. > >>> - RTP requires RTP payload formats for anything it carries. That = is to > >>> ensure that the application level framing ideas are as well = captured for > >>> a particular media encoding as possible. That optimization is not > >>> possible for general data. > >> I think "general data" is a red herring. We can define a few = different > >> data-carrying "modes" that have different properties; if some of = these > >> are useful, I think it makes sense to define them. > > I agree that different transport protocol provides different = properties. > > And that you should chose the one most appropriate. However, one > usually > > has to compromise on some aspects, either by needing to do specific > > solution for ones data or accept some other potential limitation. On = a > > high level comparisons between our transport protocols I think can = be > > summarized like this: > > > > TCP: unicast only, congestion controlled reliable byte stream > Also: Implemented in kernels, allowed through firewalls, > double-NAT-traversal fails frequently. > > SCTP: unicast, multihoming, congestion controlled, reliable and > > unreliable, message oriented. > Also: Not implemented in kernels, firewalls know nothing of it (unless > UDP encapsulated). NAT boxes know nothing about it (so UDP = encapsulation > seems a must). > > DCCP: unicast, unreliable, congestion controlled sequence numbered > datagram > The "also" list here is the same as for SCTP, I think. > > RTP/UDP: unicast and multicast, unreliable, RTP payload of single = MTU > > size, medium time scale transport feedback. > > > > UDP: unicast and multicast, unreliable, datagram > Properties of traversal of firewalls and NAT boxes are well known. > Kernel implemented. > >>> - If one can't do general optimization one goes with more general > >>> transport solutions, thus why not use a more general data = transport for > >>> the general data? > >> Pushing stuff towards a "more general data transport" requires one = of > >> two things: > >> a) having an existing more general data transport that fulfils our > >> requirements > >> b) defining a new more general data transport that fulfils our > requirements > >> The second seems tough. The first ..... what's your preferred = candidate? > > Actually the one I think is easiest from a specification point of = view > > and that does provide a reasonable service for unreliable datagrams = are: > > > > DTLS/DCCP/UDP > > > > That would be the following references: > > https://datatracker.ietf.org/doc/rfc4340/ (Base Spec) > > https://datatracker.ietf.org/doc/rfc4341/ (TCP-Like CC) > > https://datatracker.ietf.org/doc/rfc4342/ (TFRC CC) > > https://datatracker.ietf.org/doc/rfc5238/ (DTLS for DCCP) > > https://datatracker.ietf.org/doc/draft-ietf-dccp-udpencap/ (DCCP = over > UDP) > > > > My main concern is the maturity of available implementations of = DCCP. > > Otherwise it provides congestion control and can actually choose = which > > congestion control algorithms we want supported, TCP-like or TFRC. = It > > also have some additional features. One is that we get a second port > > space providing additional multiplexing points. > > > > Please note that this is just a friendly suggestion. At least check = it > > out, and possible post some comments why it would be unsuitable. > In a design point spectrum where Ian Hixie's 44-byte datagram header, > this proposal and a "data-over-RTP" proposal are the 3 candidates, we > should have enough design points that we can start discussing the > criteria we evaluate them against (often a good thing). > >>> - RTP and RTCP monitoring is also designed with more continous = medias > in > >>> mind. Here we don't know how much such properties will be true. = Also > the > >>> congestion controls available might actually have not the most = suitable > >>> properties for certain type of data. > >> It's not clear to me that there *are* congestion controls available > >> (other than media-specific ones). > >> Which ones are you thinking of? > > The one that is full defined is to run RTP over DCCP. > > https://datatracker.ietf.org/doc/rfc5762/ > > > > I guess the biggest issue is the lack of experience with this and > > especially how you interface the DCCP stack to work well between = media > > encoding, RTP stack and the DCCP congestion control. > If we buy DCCP anyway, this is certainly worth investigating. > > The alternative, not standardized yet but closest available for RTP = over > > UDP is TFRC for RTP. > > https://datatracker.ietf.org/doc/draft-gharai-avtcore-rtp-tfrc/ > > > > That was in reasonable shape prior to its abandonment due to lack of > > funding from the ones driving it. > Does anyone want to pick it up and see what's missing? > > > >> Now, the flipside: What does RTP *have* that we will otherwise need > >> to define? From your earlier list: > >> > >> - Congestion Controlled: eh... maybe not. > >> - Confidentiality and Integrity Protected - done, we've got SRTP. > >> - Providing consent to receive data prior to allow transmission of > >> substantial amounts of data - done, we have ICE, > >> and need it for media too. > >> - Some type of source authentication to prevent man in the middles > >> - done, we have SRTP > >> > >> So apart from congestion control, it seems that RTP's 12-byte = header > >> actually gives us a lot. > > Well, the security parts can be provided by ICE and DTLS over UDP = also. > > we still are short the congestion control for such a thing plus all > > these things that the UDP guidelines (RFC5405) discuss. Using RTP = over > > UDP does drag all the RTP baggage into something that may not needed = it, > > but it will provide some parts of what you need. If a particular = data > > format needs RTP functionality, it should define its own RTP payload > > format anyway. > > > > Cheers > > > > Magnus Westerlund > > > > = ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > > = ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > = ---------------------------------------------------------------------- > > >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From csp@csperkins.org Wed Apr 27 11:46:12 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A75FE07D4 for ; Wed, 27 Apr 2011 11:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 f9H8rdVXqbC8 for ; Wed, 27 Apr 2011 11:46:11 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8ECE077F for ; Wed, 27 Apr 2011 11:46:11 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.5]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QF9kY-0005TD-hh; Wed, 27 Apr 2011 18:46:10 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <000001cc0503$5ab03580$1010a080$@uni-tuebingen.de> Date: Wed, 27 Apr 2011 19:46:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2DFFAE85-A456-405F-880C-F54F1EC0D40D@csperkins.org> References: <4D9EF7D3.1040806@alvestrand.no> <1D64F821-8D2B-4983-9989-F3EE076583E3@phonefromhere.com> <4DA7F6E3.6010100@ericsson.com> <4DA84449.8090904@alvestrand.no> <4DA85617.1090506@ericsson.com> <4DB809A3.9090102@alvestrand.no> <000001cc0503$5ab03580$1010a080$@uni-tuebingen.de> To: Christian Hoene X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] data-over-RTP vs data-over-datagram (Re: non-media data) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 18:46:12 -0000 On 27 Apr 2011, at 18:48, Christian Hoene wrote: >> Returning to this thread after a few weeks.... I'm still being = contrary >> to make sure we have all the issues explicit where they need to be... >> and I do hope that some of the people who actually want to send data >> (instead of us types who speculate about what you possibly might = want) >> can speak up! >=20 > [Christian Hoene] Most RTP payload formats are for audio or video. I = have not seen that RTP is just for other real time data such as GPS, = location, orientation, input devices (mouse, kinect, etc...) or gaming = data. Thus, I do not see that data over RTP is an option that is well = supported. Real-time-Data-over-RTP seems not to be in the = standardization traditions of AVT. Of course, this might change at some = point in future. >=20 > Until then, I would suggest to support a plain = real-time-data-over-datagram option, as we do not have to follow = standards anyhow to support non-media data over whatsoever.=20 RTP is designed for real-time data, and is built on the assumption that = the data is time sensitive, and should be processed subject to time = constraints at the receiver. There are RTP payload formats for = non-audio-visual media, for example text conversation [RFC2793 and = RFC4103] and pointers [RFC2862]. I can envisage RTP being appropriate = for various types of input device, and for some forms of data being sent = in games, and for some types of sensor data, since those things are = timed. It's not a general purpose data transfer protocol though, and = isn't well suited for non-timed data. --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Wed Apr 27 11:50:36 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA33CE07D2 for ; Wed, 27 Apr 2011 11:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 V7VReB-5Du7d for ; Wed, 27 Apr 2011 11:50:36 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id F2680E0769 for ; Wed, 27 Apr 2011 11:50:35 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.5]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QF9mv-0003Ro-jK; Wed, 27 Apr 2011 18:48:37 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4DB809A3.9090102@alvestrand.no> Date: Wed, 27 Apr 2011 19:48:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8499D16B-90BB-4C7D-94B1-D4E4A67452D8@csperkins.org> References: <4D9EF7D3.1040806@alvestrand.no> <1D64F821-8D2B-4983-9989-F3EE076583E3@phonefromhere.com> <4DA7F6E3.6010100@ericsson.com> <4DA84449.8090904@alvestrand.no> <4DA85617.1090506@ericsson.com> <4DB809A3.9090102@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] data-over-RTP vs data-over-datagram (Re: non-media data) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 18:50:37 -0000 On 27 Apr 2011, at 13:18, Harald Alvestrand wrote: > Returning to this thread after a few weeks.... I'm still being = contrary to make sure we have all the issues explicit where they need to = be... and I do hope that some of the people who actually want to send = data (instead of us types who speculate about what you possibly might = want) can speak up! >=20 > On 04/15/11 16:28, Magnus Westerlund wrote: >> Haralad and other interested >>=20 >> Snipped out more parts as I added quite a lot around possible >> alternatives for you to think about. See below >>=20 >> Harald Alvestrand skrev 2011-04-15 15:12: >>>> I promised to return to why I think TCP over RTP or more general, >>>> generic data over RTP isn't the most suitable model. >>>> - RTP is a protocol built towards real-time media. Yes the = definition of >>>> media can be pretty loose here. But carrying the individual = datagrams of >>>> a TCP connection over RTP is plainly stupid, when TCP over UDP will = get >>>> you all the desired functionality anyway with less overhead. >>> RTP is, in the extreme view, a ~12-byte header and a set of = handling >>> rules. We should look at what it is, not so much what it was = originally >>> thought to be designed for (a component in a framework for multicast >>> distribution of unidirectional media channels). >> Well, the handling rules include RTCP and an intention to handle a >> number of different topologies with multi-party handling. There are = also >> additional signalling issues, like how to configure the RTCP = bandwidth >> value, which features to use and all these things. Things you may not >> need for your data transport. If you need them, you anyway should = define >> an RTP payload format for your data format. > If these questions have fixed answers in a specific scenario (like = point-to-point), they can be handled by specifying a set of reasonable = values for that scenario. >> And to be frank, the transport and RAI ADs has been very hesitant to >> allow any RTP payload format that is defined for just being a bit = pipe >> over RTP. The two reasons for this has been Application level framing >> principle and the lack of congestion control for RTP. > I do wonder about the ALF principle. In some ways, it seems reasonable = under ALF that one should be able to use a framing mechanism that = provides some of what we want without necessarily worrying that it = provides more than what we want... A protocol isn't just a framing format though. The semantics of RTP are = very much focussed on real-time, time sensitive, media delivery. Trying = to use it outside that space is likely to cause problematic semantic = mismatch, to the extent that you'd be better duplicating the framing = (which is the most trivial aspect of RTP) in another protocol that = doesn't have all the other features of RTP that you don't want. --=20 Colin Perkins http://csperkins.org/ From singer@apple.com Thu Apr 28 06:44:44 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CE7E0717 for ; Thu, 28 Apr 2011 06:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVy+TshUN8l4 for ; Thu, 28 Apr 2011 06:44:44 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5E03FE0669 for ; Thu, 28 Apr 2011 06:44:44 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LKD009QH7HXCQN0@mail-out.apple.com> for rtcweb@ietf.org; Thu, 28 Apr 2011 06:44:43 -0700 (PDT) X-AuditID: 11807137-b7cd4ae000003108-a6-4db96f4ac429 Received: from [17.153.54.49] (Unknown_Domain [17.153.54.49]) by relay16.apple.com (Apple SCV relay) with SMTP id 49.96.12552.B4F69BD4; Thu, 28 Apr 2011 06:44:43 -0700 (PDT) From: David Singer In-reply-to: <2DFFAE85-A456-405F-880C-F54F1EC0D40D@csperkins.org> Date: Thu, 28 Apr 2011 09:44:42 -0400 Message-id: References: <4D9EF7D3.1040806@alvestrand.no> <1D64F821-8D2B-4983-9989-F3EE076583E3@phonefromhere.com> <4DA7F6E3.6010100@ericsson.com> <4DA84449.8090904@alvestrand.no> <4DA85617.1090506@ericsson.com> <4DB809A3.9090102@alvestrand.no> <000001cc0503$5ab03580$1010a080$@uni-tuebingen.de> <2DFFAE85-A456-405F-880C-F54F1EC0D40D@csperkins.org> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] data-over-RTP vs data-over-datagram (Re: non-media data) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 13:44:45 -0000 On Apr 27, 2011, at 14:46 , Colin Perkins wrote: > On 27 Apr 2011, at 18:48, Christian Hoene wrote: >>> Returning to this thread after a few weeks.... I'm still being contrary >>> to make sure we have all the issues explicit where they need to be... >>> and I do hope that some of the people who actually want to send data >>> (instead of us types who speculate about what you possibly might want) >>> can speak up! >> >> [Christian Hoene] Most RTP payload formats are for audio or video. I have not seen that RTP is just for other real time data such as GPS, location, orientation, input devices (mouse, kinect, etc...) or gaming data. Thus, I do not see that data over RTP is an option that is well supported. Real-time-Data-over-RTP seems not to be in the standardization traditions of AVT. Of course, this might change at some point in future. >> >> Until then, I would suggest to support a plain real-time-data-over-datagram option, as we do not have to follow standards anyhow to support non-media data over whatsoever. > > > RTP is designed for real-time data, and is built on the assumption that the data is time sensitive, and should be processed subject to time constraints at the receiver. There are RTP payload formats for non-audio-visual media, for example text conversation [RFC2793 and RFC4103] and pointers [RFC2862]. I can envisage RTP being appropriate for various types of input device, and for some forms of data being sent in games, and for some types of sensor data, since those things are timed. It's not a general purpose data transfer protocol though, and isn't well suited for non-timed data. > Specifically, I'd say that, given the choice between getting all the data (possibly at some indefinite time in the future) or getting data on time (but possibly incomplete), TCP attempts to do the former, and RTP the latter. That makes RTP unsuitable if loss is undesirable and/or timeliness is not needed. David Singer Multimedia and Software Standards, Apple Inc. From john.elwell@siemens-enterprise.com Thu Apr 28 09:57:16 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A57FE0714 for ; Thu, 28 Apr 2011 09:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.972 X-Spam-Level: X-Spam-Status: No, score=-104.972 tagged_above=-999 required=5 tests=[AWL=1.627, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZUy8moLh9WO for ; Thu, 28 Apr 2011 09:57:16 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 89CB3E0670 for ; Thu, 28 Apr 2011 09:57:15 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1304009834!5775923!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 32339 invoked from network); 28 Apr 2011 16:57:14 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-8.tower-182.messagelabs.com with SMTP; 28 Apr 2011 16:57:14 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id EBAA71EB83E3; Thu, 28 Apr 2011 18:57:13 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 28 Apr 2011 18:57:13 +0200 From: "Elwell, John" To: Colin Perkins , Harald Alvestrand Date: Thu, 28 Apr 2011 18:57:13 +0200 Thread-Topic: [rtcweb] data-over-RTP vs data-over-datagram (Re: non-media data) Thread-Index: AcwFDAI99OnFm8QjS5O0/q2F1zS5pQAuQaxQ Message-ID: References: <4D9EF7D3.1040806@alvestrand.no> <1D64F821-8D2B-4983-9989-F3EE076583E3@phonefromhere.com> <4DA7F6E3.6010100@ericsson.com> <4DA84449.8090904@alvestrand.no> <4DA85617.1090506@ericsson.com> <4DB809A3.9090102@alvestrand.no> <8499D16B-90BB-4C7D-94B1-D4E4A67452D8@csperkins.org> In-Reply-To: <8499D16B-90BB-4C7D-94B1-D4E4A67452D8@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] data-over-RTP vs data-over-datagram (Re: non-media data) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 16:57:16 -0000 >=20 > A protocol isn't just a framing format though. The semantics=20 > of RTP are very much focussed on real-time, time sensitive,=20 > media delivery. Trying to use it outside that space is likely=20 > to cause problematic semantic mismatch, to the extent that=20 > you'd be better duplicating the framing (which is the most=20 > trivial aspect of RTP) in another protocol that doesn't have=20 > all the other features of RTP that you don't want. [JRE] Not to mention all the RTCP stuff comes with RTP and probably isn't r= elevant to non-real-time data. John >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > =