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

[Stefan Håkansson LK <[e-mail]>]

On 10/18/2011 03:30 PM, Iñaki Baz Castillo wrote:
> 2011/10/18 Stefan Håkansson LK<[e-mail]>:
>> 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
>> browsers).
>>
>> 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.
>
>
> Hi Stefan, that looks nice, but could you explain what does it mean
> "in the same context as you have already created one or more
> PeerConnection's"?

What I mean is: if this web app has already created a PeerConncection, 
and is about to open another one (e.g. for a new fork), the new 
PeerConnection should use the same local candidates as the one already 
created collected.

>
> Could you please translate it into a theorical JS API?

Even better, I can point to the current API proposal: 
<http://dev.w3.org/2011/webrtc/editor/webrtc-20111017.html>. I think no 
changes would be required to the API per se, but some text on how the 
user agent should act need to be added.

(I'm sure I've overlooked some aspect, but hopefully it would be 
possible to fix)

Br,
Stefan

>
> Regards.
>
>