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

[Roman Shpount <[e-mail]>]

On Thu, May 3, 2012 at 2:02 AM, Christer Holmberg <
[e-mail]> wrote:

> You are absolutely right. I still question whether we need to support
> parallel forking. If you say it occurs often, I can't argue against you,
> even though my own experience is different :)
>
>
You do end up with parallel forking when you allow registrations from
multiple devices. This is a policy option, but once you enable this,
parallel forking or B2BUA are the only options. Furthermore, even if you do
serial forking, you end up with multiple parallel media streams being
received by the client due to loose synchronization between RTP streams and
SIP signaling. The main discrepancy between current WebRTC signaling model
and SIP is that in SIP, when you do forking, you still have separate
dialogs that each maintain state. Even if only render media from one RTP
stream, black hole all the other media, and send media to one RTP
destination, you still have dialog specific SIP and ICE state that you can
update (for instance due to UPDATE transaction) and recover if the
currently selected dialog ended up not being the one that was selected in
200 OK. This is not an option with WebRTC.


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


> 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.
_____________
Roman Shpount