[rtcweb] Another approach to forking...
Harald Alvestrand <harald@alvestrand.no> Fri, 23 September 2011 12:55 UTC
Return-Path: <harald@alvestrand.no>
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 E5A3A21F8C2D for <rtcweb@ietfa.amsl.com>; Fri, 23 Sep 2011 05:55:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.856
X-Spam-Level:
X-Spam-Status: No, score=-108.856 tagged_above=-999 required=5 tests=[AWL=1.743, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 KsqJoasl-JJC for <rtcweb@ietfa.amsl.com>; Fri, 23 Sep 2011 05:55:59 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5099921F8BEE for <rtcweb@ietf.org>; Fri, 23 Sep 2011 05:55:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2754E39E0C4 for <rtcweb@ietf.org>; Fri, 23 Sep 2011 14:58:32 +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 xkThNibpC0tW for <rtcweb@ietf.org>; Fri, 23 Sep 2011 14:58:31 +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 BE23E39E0BC for <rtcweb@ietf.org>; Fri, 23 Sep 2011 14:58:31 +0200 (CEST)
Message-ID: <4E7C8277.9000902@alvestrand.no>
Date: Fri, 23 Sep 2011 14:58:31 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [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 12:56:00 -0000
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. Harald
- [rtcweb] Another approach to forking... Harald Alvestrand
- Re: [rtcweb] Another approach to forking... Hadriel Kaplan
- Re: [rtcweb] Another approach to forking... Harald Alvestrand
- Re: [rtcweb] Another approach to forking... Randell Jesup