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

Hadriel Kaplan <HKaplan@acmepacket.com> Fri, 23 September 2011 13:23 UTC

Return-Path: <HKaplan@acmepacket.com>
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 CEC9321F8BA8 for <rtcweb@ietfa.amsl.com>; Fri, 23 Sep 2011 06:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.229
X-Spam-Level:
X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, J_CHICKENPOX_25=0.6]
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 AM1yYwD7hZyY for <rtcweb@ietfa.amsl.com>; Fri, 23 Sep 2011 06:23:15 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAB021F8B1E for <rtcweb@ietf.org>; Fri, 23 Sep 2011 06:23:15 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 23 Sep 2011 09:25:47 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 23 Sep 2011 09:25:46 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Harald Alvestrand <harald@alvestrand.no>
Thread-Topic: [rtcweb] Another approach to forking...
Thread-Index: AQHMefRNEfPyrR9P3kauDT2dWYY7CA==
Date: Fri, 23 Sep 2011 13:25:46 +0000
Message-ID: <2DB2EECF-82F3-4D36-AD17-6891CDAACBBF@acmepacket.com>
References: <4E7C8277.9000902@alvestrand.no>
In-Reply-To: <4E7C8277.9000902@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A6BABBB4A4E5D84480E1DBF7C1CF2690@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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 13:23:15 -0000

On Sep 23, 2011, at 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

By this you mean take the answer and make it appear as an offer to PeerConn, right?


>  - Throw away the generated "SDP ANSWER"

But wouldn't the new PeerConn's be creating new ICE ufrag/passwords that won't match the one it created in the original PeerConn's offer, and thus not be able to successfully negotiate ICE with the peer(s)?

And doesn't PeerConn create/allocate the IP:ports used for MediaStreams?  If so, each new PeerConn would also presumably be using a new UDP listen port and break this.

-hadriel