Re: [rtcweb] State of the Forking discussion

[Iñaki Baz Castillo <[e-mail]>]

2011/11/3 Ravindran Parthasarathi <[e-mail]>:
> Question #2: If it is supported in which form would it supported in?
>             I support for B3 or B4 as it covers both serial & parallel forking.

> I'm interested in parallel forking because serial forking support is partial support of forking in terms of SIP (RFC 3261) which may leads to interop issue and also, it is always possible to get 2 18x response with different to-tag and different SDP answers while interworking with SIP (2 dialogs with 2 different offer/answer pair at this stage)

Right. But note however that most of the SIP devices just choose a
single media session and render that to the human (regardless there
could be N sessions due to multiple 18X with different Totag and
SDPs). So I don't consider this a very important limitation as the
very same occurs in 99% of SIP phones.


> and 200 may came any one of the remote (first or second).

Yes, but that is not parallel forking, it's serial forking. For this
last case we don't require WebRTC to support media parallel forking,
but just the hability to *replace* the media information of the remote
peer with a new one (the SDP in 200) by reusing the same local
PeerConnection.

So this is case B2 above, and not B3 or B4.


> Also, WebRTC forking infrastructure shall be used for other services as mentioned in http://www.ietf.org/mail-archive/web/rtcweb/current/msg02516.html.

You already received a reply in that thread. The use cases you
describe there don't require media-forking. Instead they require N
media streams from different PeerConnections in local side. Then we
can discuss about the need (or not) for mixing different streams in
the browser (like a 3-Way-Call in legacy telephony), but that is not
about media forking at all.


Regards.



-- 
Iñaki Baz Castillo
<[e-mail]>