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

[Christer Holmberg <[e-mail]>]

Hi, 

>> 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 am not sure whether option 3) uses a single PeerConnection, but one alternative is that we use multiple PC objects, but they all share the local parameters and candidates.

Personally I think option 2) would be ok for most cases, and enough to support in "phase 1".

And, IF someone really wants to support parallel forking, there is always the possibility to create new PC objects, send offers associated with them etc.

Regards,

Christer