Re: [rtcweb] Let's define the purpose of WebRTC

Randell Jesup <randell-ietf@jesup.org> Mon, 07 November 2011 15:40 UTC

Return-Path: <randell-ietf@jesup.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E65E21F8C20 for <rtcweb@ietfa.amsl.com>; Mon, 7 Nov 2011 07:40:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level:
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pZQw2gr3gTQ for <rtcweb@ietfa.amsl.com>; Mon, 7 Nov 2011 07:40:55 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id B629E21F8C1B for <rtcweb@ietf.org>; Mon, 7 Nov 2011 07:40:55 -0800 (PST)
Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1RNRJf-0002f5-CU for rtcweb@ietf.org; Mon, 07 Nov 2011 09:40:55 -0600
Message-ID: <4EB7FBE8.9070506@jesup.org>
Date: Mon, 07 Nov 2011 10:40:24 -0500
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CALiegfkVNVAs_MyU_-4koA4zRwSn1-FwLjY9g_oZVkhi9rSK5Q@mail.gmail.com> <CAD5OKxt=k_Mon_GMs1w-bGMgpk12h6ZQ=FkoRVsTp4271iMSLA@mail.gmail.com> <CABcZeBNMTgwH-R_jd-AiEJ8tELTeFMNm-bAJohRg2RxD5e+kZQ@mail.gmail.com> <CAD6AjGRBmrAqB3CEWxtaXnryPA5App13S2jJPAt+7HwWZsQFzA@mail.gmail.com> <CABcZeBNtoizuRymVMxF4CdiLu1Nju63C0xkWJHjoarpxeLXjyA@mail.gmail.com> <CALiegfk=oJJ20GhKQBKA7aspHhUyQ-s+DR-qSi4XV455Nj718w@mail.gmail.com> <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <4EB74D06.8000006@jesup.org> <4EB7D17D.8080307@ericsson.com>
In-Reply-To: <4EB7D17D.8080307@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] Let's define the purpose of WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Nov 2011 15:40:56 -0000

On 11/7/2011 7:39 AM, Stefan Håkansson LK wrote:
> On 11/07/2011 04:14 AM, Randell Jesup wrote:
> ....
>
>> And glare:
>> Cullen's classic example of glare is two people talking, browser to
>> browser, and one saying "lets add video", and both turning it on. No
>> interop or SIP required for that to cause glare.

> I would say, if we could completely forget legacy we could also forget
> glare. We could have one offer/answer to open a connection (using ICE).
> Setting up the RTP-streams could then be separate for each end: the A
> side initiaes offer/answer to set up the streams flowing A->B and B does
> the corresponding for streams B->A, and these o/a dialogues could be
> separated. (In essence each side set's up what is in its localStreams
> array independently.) Then there would be no glare. (Not that I'm
> arguing for it)

Even two one-way channels could have glare between an IP change at one 
end (or change in what resources it has to receive codecs, or window 
size it's displayed, etc), and the sender wanting to change something 
(even simply to go inactive/MUTE).


-- 
Randell Jesup
randell-ietf@jesup.org