Re: [rtcweb] Another approach to forking...

Randell Jesup <randell-ietf@jesup.org> Fri, 23 September 2011 15:30 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 62BF821F8CD3 for <rtcweb@ietfa.amsl.com>; Fri, 23 Sep 2011 08:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 pkweubRLM45O for <rtcweb@ietfa.amsl.com>; Fri, 23 Sep 2011 08:30:32 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 589BA21F8CD0 for <rtcweb@ietf.org>; Fri, 23 Sep 2011 08:30:32 -0700 (PDT)
Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] 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 1R77kQ-0002tF-7R for rtcweb@ietf.org; Fri, 23 Sep 2011 10:33:06 -0500
Message-ID: <4E7CA5DD.4060302@jesup.org>
Date: Fri, 23 Sep 2011 11:29:33 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E7C8277.9000902@alvestrand.no>
In-Reply-To: <4E7C8277.9000902@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] Another approach to forking...
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: Fri, 23 Sep 2011 15:30:33 -0000

On 9/23/2011 8:58 AM, Harald Alvestrand wrote:
> Just to confuse the forking issue still further:
>
> If the APIs remain as they are today, a JS application that wants to 
> support forking can do the following:
>
> - Create a PeerConnection
> - Cause it to generate an SDP blob ("SDP OFFER")
> - Send that SDP blob out to be forked
> - Throw away the PeerConnection
> - As the answers come back, for each answer:
>   - Create a new PeerConnection
>   - Take out the SDP blob, put "SDP OFFER" at the top, and give it to 
> the PeerConnection
>   - Throw away the generated "SDP ANSWER"
>
> Then connect all the media to output devices as appropriate, and shut 
> them down one by one as the application decides that these were not 
> the connections that would last.
>
> For extra safety, cause the PeerConnection to do a renegotiation at an 
> appropriate time, so that both sides have seen an SDP OFFER/ANSWER 
> exchange that actually came from the other side.
>
> It requires a little bit of insight into the SDP offer/answer model, 
> and it's a pity to have to resort to string manipulation at any level, 
> but .... it doesn't seem anywhere near impossible. Not even 
> particularly architecture-breaking.

Evil (kinda), but effective in practice.  I'd prefer the ability to effectively 'clone'
a PeerConnection object on receipt of (another) speculative answer (see my earlier
proposal), removing the need to play games like above.  This requires keeping in the
PeerConnection any necessary state to reproduce the necessary object state on a new
speculative (or final) answer.  Seems fairly straightforward.  Alternatively you
could use a model where an offer was done via a PeerConnectionOffer object, and on a
(speculative or final) answer a connected PeerConnection object is produced by it.
When the app is done and has decided "no more forks accepted" (for example on an ACCEPT
per my proposal), it would kill the PeerConnectionOffer and any PeerConnections it didn't
want to keep.  This is a bit 'cleaner' an API in my mind than just PeerConnections with
some sort of fork/clone method, but that's minor and a personal preference.



-- 
Randell Jesup
randell-ietf@jesup.org