[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