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

[Roman Shpount <[e-mail]>]

On Wed, May 2, 2012 at 4:41 PM, Christer Holmberg <
[e-mail]> wrote:


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