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

Randell Jesup <randell-ietf@jesup.org> Mon, 07 November 2011 17:35 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 E38F921F8C07 for <rtcweb@ietfa.amsl.com>; Mon, 7 Nov 2011 09:35:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.558
X-Spam-Level:
X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 sM5Ul3wyEVK7 for <rtcweb@ietfa.amsl.com>; Mon, 7 Nov 2011 09:35: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 E3F1321F8B66 for <rtcweb@ietf.org>; Mon, 7 Nov 2011 09:35:54 -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 1RNT6n-0007Zx-8Q for rtcweb@ietf.org; Mon, 07 Nov 2011 11:35:45 -0600
Message-ID: <4EB816D1.1040708@jesup.org>
Date: Mon, 07 Nov 2011 12:35:13 -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> <CAAJUQMihjTRgpO8hjgiYz5iLbWTncdXFO8nnRE9VDRND36-b2w@mail.gmail.com> <4EB7FAED.4070104@jesup.org> <4EB806F7.2090603@alvestrand.no> <CAAJUQMjcoR+epj03GWyAmZbdLPt87KHACEGH7oQubaGm7CTZUQ@mail.gmail.com>
In-Reply-To: <CAAJUQMjcoR+epj03GWyAmZbdLPt87KHACEGH7oQubaGm7CTZUQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] 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 17:35:56 -0000

On 11/7/2011 11:53 AM, Wolfgang Beck wrote:
> On Mon, Nov 7, 2011 at 5:27 PM, Harald Alvestrand<harald@alvestrand.no>  wrote:
> [on SIP-style forking]
>> If we were doing a greenfield application, I'd let the server tell all the
>> possible endpoints that they should set up a connection to the original
>> caller, and forget about the caller calling anyone.
>>
>> The difference between caller and callee is a question of your level of
>> abstraction.....
>
> That's the kind of innovative thinking I thought RTCWEB was all about.
>
> And this forking discussion is a good example how the requirement to
> have interop between different RTCWEB apps and/or SIP is holding us
> back. Ditch the trapezoid and do greenfield.

This has nothing to do with trapezoids.  This is something I believe we 
need even if there was an absolute block on SIP interop.

And I disagree with Harald here; telling the clients they should open 
connections to the "caller" is exactly what parallel forking by the 
server does.  It tells them "here's the offer and ICE candidates, open a 
connection to the "caller" and complete negotiation."  It'd be silly not 
to include the OFFER in the message to the "callee's", since we have to 
send them the ICE candidates anyways - plus, the "callee's" may need 
that info for alerting, etc, and not providing it would add more 
round-trips.  Never forget that even half-round-trips can be PAINFUL to 
some applications!  And don't forget that this might get used on links 
that bounce off a satellite (or two!), or transit low-bandwidth wireless 
networks or mesh networks, etc.  Now there's RTT... ;-)

Now, the "caller" may have taken the first ACCEPT, or it might run them 
parallel until a final accept on one, or it might keep all the options 
open for the entire "call" (which doesn't map super-well to SIP, note, 
though it can be emulated in SIP).  So the "caller" may decline the 
ANSWERs or final ANSWERS (ACCEPTs) from any of the forked "callees". 
That's entirely up to the app.


-- 
Randell Jesup
randell-ietf@jesup.org