Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway)

[Iñaki Baz Castillo <[e-mail]>]

2011/10/31 Harald Alvestrand <[e-mail]>:
> I think having a single PeerConnection object send media to multiple peers
> at the same time breaks the model we've been working from.
>
> It may be reasonable to give a PeerConnection the ability to switch from one
> remote peer to another remote peer (to support 180-like things), but I don't
> think it's reasonable to have it connected to multiple remote peers.
>
> So if we support real forking, we'll have to create multiple PeerConnections
> to do that.

AFAIK there are three alternatives here:


1) PeerConnection can just communicate with a single peer.

2) PeerConnection can just communicate with a single peer but the per
can be replaced later (so still we reuse the same local candidates,
but ICE+SRTP must be "restarted". This solves serial forking.

3) PeerConnection can communicate with multiple peers at the same
time. This solves serial and parallel forking.


In my opinion:

- Option 1) is very limited.

- Option 2) is a MUST.

- Option 3) would be great but it introduces some complexity. Imagine
there is parallel forking and the WebRTC client recives 3 SDP's from 3
different peers, and passes all of them to the same PeerConnection. At
same point a remote peer stops sending media so we get a callback
"peerStopsSendingMedia()" in out PeerConnection. Does it mean that we
can close the PeerConnection? not, because we must check whether there
are other active peers yet (and there are in this case). So this
introduces complexity at JavaScript level. The question is: is this
complexity not so hard? can it be limited by some parameter when
creating a PeerConnection? I imagine soemthing like:

   new PeerConnection( capabilities=[], allow_multiple_peers=false/true)


-- 
Iñaki Baz Castillo
<[e-mail]>