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

[Harald Alvestrand <[e-mail]>]

On 10/18/11 12:24, Iñaki Baz Castillo wrote:
> 2011/10/18 Harald Alvestrand<[e-mail]>:
>> 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.