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

Harald Alvestrand <> Tue, 18 October 2011 11:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E964721F8B43 for <>; Tue, 18 Oct 2011 04:10:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.449
X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bY-DqMvfgw0a for <>; Tue, 18 Oct 2011 04:10:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0B32021F8B0E for <>; Tue, 18 Oct 2011 04:10:21 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BF3539E0CD; Tue, 18 Oct 2011 13:10:19 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FqMzOQHaVTnA; Tue, 18 Oct 2011 13:10:18 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTPS id 78CAD39E082; Tue, 18 Oct 2011 13:10:18 +0200 (CEST)
Message-ID: <>
Date: Tue, 18 Oct 2011 13:10:18 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: Iñaki Baz Castillo <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: Jonathan Rosenberg <>,,
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 11:10:22 -0000

On 10/18/11 12:24, Iñaki Baz Castillo wrote:
> 2011/10/18 Harald Alvestrand<>:
>> I and some people from Ericsson had a discussion about forking the other day
>> (the ability to send out one request and have it generate multiple
>> PeerConnections on the response).
>> Options include:
>> - Sending a request with no content for which state must be kept, creating
>> new PeerConnection objects on answer that can handle an answer without
>> generating an offer first, and then renegotiating stuff that needs state
>> subsequently
>> - Creating a new "PeerConnectionFactoryWithOffer" object that holds the
>> state of the request, but has the ability to mint several PeerConnections on
>> responses
>> - Throwing away the initial PeerConnection, munge the incoming Answer to
>> look like an Offer, create a PeerConnection from it, and throw away the
>> resulting Answer
>> - Create the ability to create a PeerConnection from an Offer + an Answer,
>> together with the ability to create an Offer without creating a
>> PeerConnection (this is a variant of the Factory method)
>> - Do something different.....
> Hi Harald, if I'm right the problem arises when the RTCweb client
> generates a SDP/ROAP offer, sends it to the proxy/server and receives
> more than one SDP/ROAP answer. The problem is that, currently, the
> PeerConnection object just expects a single answer, am I right?
Yes. My note was intended to point out that there's a number of API 
solutions here, but they all cost in terms of complexity.
> The above options 1 and 3 require the RTCweb client to generate an
> "INVITE" (let me name it INVITE) with no SDP/ROAP, which IMHO limits
> too much some possible scenarios. In SIP world, sending an empty
> INVITE means that the receiver could offer in the 200 OK response a
> SDP offer with codecs not supported by the caller, so the caller must
> send ACK and later a BYE. That's commonly ugly so I discourage its
> usage for RTCweb.
> 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).

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.