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

[Christer Holmberg <[e-mail]>]

Hi, 

>>> In my opinion a better solution is to create a new 
>>> PeerConnection for every new early dialog, which uses the 
>>> *same* address/candidate parameters as the "parent" PeerConnection.
>> Hmm we should talk about this - I have a hard time seeing 
>> how that is going to work. I was working on the assumption 
>> that  PeerConnection could deal with more than one 
>> offer/answer pair at a time. Given the current WebRTC API and 
>> something like ROAP - it seems like that should just work.
>
> 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.

We could create new PeerConnections objects for every early dialog, but the idea was that the new object could use the same local parameter (IP address:port, candidates etc) as the "parent" object, so that one does not need to send a new offer.

However, for serial forking we would only need a single PeerConnection object, assuming we could switch the remote parameter.

So, again, I think we should first agree on WHAT we want, and then we can start thinking on HOW to get it.

Regards,

Christer