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

On 10/18/2011 02:58 AM, Roman Shpount wrote:
> Cullen,
>
> Did we decide to explicitly not support forking which generates 
> multiple final answers? If this is not the case, how is this supposed 
> to be implemented using your model?

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.....

Of course there's always the option of not supporting forking, leading 
it to be a problem that only concerns those who write gateways into 
systems where it is required; SIP systems that don't support forking are 
in the same boat.

It's not impossible, but it does have an overhead cost.

> _____________
> Roman Shpount
>
>
> On Fri, Oct 14, 2011 at 11:09 PM, Cullen Jennings <fluffy@cisco.com 
> <mailto:fluffy@cisco.com>> wrote:
>
>
>     Jonathan and I submitted a new draft on setting up media based on
>     the SDP Offer/Answer model. The ASCII flows are a bit hard to read
>     so until I update them, I recommend reading the PDF version at
>
>     http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf
>
>     Clearly the draft is an early stage but we plan to revise it
>     before the deadline for the IETF 82. Love to get input -
>     particularly on if this looks like generally the right direction
>     to go.
>
>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb