Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

[Christer Holmberg <[e-mail]>]

Hi,

>>     (Another option, if we want to support parallel forking, would of
>>     course be to create a completely new PeerConnection, with a *new*
>>     local IP address:port. But, you would of course then have to provide
>>     that information to the remote peer.)
>>
>>
>> This would probably do absolutely nothing to SIP interop. And if we do
>> not need SIP interop we can live without forking (at the cost of being
>> slightly less efficient in some call setup scenarios).
>
> Ignoring SIP interop, this might work as an equivalent to cloning, but
> requiring an extra O/A exchange (and adding considerable chance of
> clipping on a second fork being activated).

Assuming you have to perform the ICE procedures anyway, I don't think it would cause clipping. It probably would cause some additinoal call setup delay, though, as you need to perform that extra O/A exchange before the ICE procedures can start.


>>     I have no strong feeling on whether we want to do cloning, but do
>>     people agree that, for a given PeerConnection, we only need to
>>     support a single remote peer (which can be modified, though)?
>>
>>
>> I think if we do cloning we will only need to support a single remote
>> peer per PeerConnection. Strictly speaking even updates due to
>> provisional responses would not be necessary, since you can always clone
>> the connection and provide a new answer to it instead.
>
> I believe that's correct.

Sure. But, that would also mean that you would have to clone the PeerConnection mid-session, if the remote entity changes.

Regards,

Christer