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/19/2011 10:20 AM, Harald Alvestrand wrote:
> 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
>>> <[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.
> 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.

That's right.

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