- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Tue, 18 Oct 2011 12:24:41 +0200
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: Roman Shpount <roman@telurix.com>, Jonathan Rosenberg <jonathan.rosenberg@skype.net>, rtcweb@ietf.org, public-webrtc@w3.org
2011/10/18 Harald Alvestrand <harald@alvestrand.no>: > 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? 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? Regards. -- Iñaki Baz Castillo <ibc@aliax.net>
Received on Tuesday, 18 October 2011 10:25:09 UTC