Re: [rtcweb] Regarding cloning of PeerConnections when multiple answers are received

[Roman Shpount <[e-mail]>]

On Tue, Apr 10, 2012 at 4:18 AM, Magnus Westerlund <
[e-mail]> wrote:

> Actually TURN forces one to setup at least new permissions for each peer
> that you want to accept flows from. Thus, even cloning an existing local
> state will require additional actions for any TURN candidates. I haven't
> looked into the detail for TURN TCP.
>
>
You are correct, when a new remote peer is added to a given allocation TURN
allocation, a new permission needs to be added if remote peer address is
different (permission is per address), new channel needs to be
created(optional but highly recommended for RTP), and ICE exchange should
be completed to confirm the connectivity. This procedure is the same for
adding new remote peer due to normal session re-negotiation (you can send
an offer with the same SDP on existing connetion and get a new response
with different peers back), reusing TURN allocation in case of bundle, or
in case we discuss -- forking. I would expect that a functional WebRTC
implementation must be able to reuse the same TURN allocation for multiple
connections within the same call. I do not think that adding support for
this to enable reuse of the same allocation across multiple calls would
complicate things too much.
_____________
Roman Shpount