Re: [rtcweb] API options for supporting fork with ROAP (Re: SDP Offer/Answer draft-jennings-rtcweb-signaling)

Stefan Håkansson LK <> Tue, 18 October 2011 12:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7073521F8BAA for <>; Tue, 18 Oct 2011 05:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dxI5UESUf04w for <>; Tue, 18 Oct 2011 05:25:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0E9CD21F8B43 for <>; Tue, 18 Oct 2011 05:24:59 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c26ae0000035b9-7d-4e9d701a1799
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id B2.82.13753.A107D9E4; Tue, 18 Oct 2011 14:24:58 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Tue, 18 Oct 2011 14:24:58 +0200
Message-ID: <>
Date: Tue, 18 Oct 2011 14:24:57 +0200
From: Stefan Håkansson LK <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [rtcweb] API options for supporting fork with ROAP (Re: SDP Offer/Answer draft-jennings-rtcweb-signaling)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Oct 2011 12:25:01 -0000

Our idea is basically that whenever you create a new PeerConnection in
the same context as you have already created one or more
PeerConnection's, the same local candidates should be re-used. Of course 
the 5-tuple must remain unique so that different connections don't 
collapse into one, but this is quite simple to resolve.

For clarity, the above would be requirements on the implementation (in 

This means that support of forking would be simple as the IP+port's to
send media to (for the remote end) remains also for the new PeerConnection.

Another advantage is that creating new PeerConnections will be faster as 
new candidates does not need to be gathered.

I think this is quite a clean solution since there is no need for API
changes, or any additional factory layer.


On 10/18/2011 01:18 PM, Iñaki Baz Castillo wrote:
> 2011/10/18 Harald Alvestrand<>:
>>> Said that, I strongly like your option 2 "Creating a new
>>> PeerConnectionFactoryWithOffer". If I understand it properly, when a
>>> RTCweb environment allows media forking, the RTCweb client should
>>> create a PeerConnectionFactoryWithOffer object rather than a
>>> PeerConnection. Then it sends the offer over the wire. Upon receipt of
>>> each response with different ROAP/SDP answer, the object would
>>> internally generate different PeerConnection objects (but the state of
>>> all of them are governed by the PeerConnectionFactoryWithOffer
>>> object). Am I right?
>> Yes, that's right.
>> One advantage of this approach is that the new class comes in addition to
>> the normal PeerConnection class, so the interface for this functionality
>> does not clutter up the interface for applications that don't want to deal
>> with forking; they just never create such objects, and will reply to
>> subsequent answers with "ERROR" (as they're always free to do).
> I like the idea.
>> There are a number of additional details that need specification before this
>> can be implemented, of course; we might want to delay that functionality
>> beyond the first wave of releases.
> As you noted, the point is that this advanced feature can be added
> later over the existing stack. So I support this proposal.
> Regards.