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

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

2011/10/31 Christer Holmberg <[e-mail]>:
>> 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.

Maybe I'm wrong, but AFAIK the local candidates are generated when
creating a PeerConnection object. This is: you create a PC object and
internally it gets the candidates, so you cannot create a second PC
and use the same local candidates. Am I wrong?



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

I also agree. Also, many SIP phones just render a single media stream
even when media parallel forking occurs, and switch to the definitive
SDP when the 200 arrives, so IMHO this is not a great limitation for
WebRTC.



> 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.

Right.



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