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

[Christer Holmberg <[e-mail]>]

Hi,

>> I think that is unlikely to happen, as forking is normally done in a serial manner (to avoid other issues associated with parallel forking).
>
> I am not sure why you would say that most forking is serial. It is quite often parallel. What is commonly done to avoid support for multiple 
> parallel media streams is playing media from the newest received RTP stream. In either case there is no guarantee that you picked the 
> winning stream, and you always need to make sure that you use the SDP received in the dialog that got 200 OK and that media playback 
> switches to RTP stream that remains. Making this work is often problematic in SIP since there is no way to associate received RTP with 
> received SDP information due to RTP being sent from a different IP/port from the one used in SDP. It should be easier with WebRTC 
> since ICE support is required and remote party IP/port can be determined for each flow.
>
> Finally, when you are dealing with forking you need to keep track of the remote IP/ports and ICE candidates for each dialog. You can 
> play media from only one of them, but this remote connection state is required to complete the call setup when 200 OK is received.

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, eventhough my own experience is different :)

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

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)?

Regards,

Christer