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

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

On 10/18/2011 06:07 PM, Roman Shpount wrote:
> On Tue, Oct 18, 2011 at 9:57 AM, Stefan Håkansson LK
> <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     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.
>
>
> What would happen if new PeerConnection has a different set of
> codecs/media streams? Do we just add/remove local candidates based on
> how many different streams are needed?

Now we're getting into the stuff that is not my home turf :). But as I 
understand it, the current assumption is that the browser would in fact 
only open one port which all RTP streams use. In most cases all streams 
would be multiplexed over the same 5-tuple, but the other end (if it is 
not a browser) could open separate ports for each RTP stream, if it 
(read legacy) would like to avoid multiplexing.

This means that when the first PeerConnection is set up it would gather 
candidates (host, srflx, ...) for one port only; my idea is that these 
candidates would be re-used if a second PeerConnection is created.

Codecs and media streams would be negotiated per PeerConnection.

I hope this is roughly right, not my home turf as said.

>
> Overall I do like this idea since it not only addresses the forking
> issue, but suggest a good resource usage policy.
> _____________
> Roman Shpount
>