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

On 10/19/11 09:52, Stefan Håkansson wrote:
> On 10/18/2011 06:07 PM, Roman Shpount wrote:
>> On Tue, Oct 18, 2011 at 9:57 AM, Stefan Håkansson LK
>> <stefan.lk.hakansson@ericsson.com
>> <mailto:stefan.lk.hakansson@ericsson.com>> 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.
Actually my current understanding is that in all cases, all video 
components of all MediaStreams would use the same RTP session, and all 
audio components of all MediaStreams would use the same RTP session.

If the TOGETHER extension (draft-alvestrand-one-rtp) or BONDING 
extension (next version of 
draft-holmberg-mmusic-sdp-multiplex-negotiation; the name changed) is 
supported, both media types would be sent across one RTP session.

The word "multiplexing" is awfully confusing; at least Holmberg and I 
have concluded that it's better for communication if we don't use it.
>
> 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.
With a caveat  ....

note that the parameters passed to the constructor of PeerConnection 
(STUN/TURN server) will affect the candidate sets, so if those change, 
the cached candidates cannot be used.

>
> 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
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>