Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]

[Roman Shpount <[e-mail]>]

On Fri, Oct 28, 2011 at 6:18 PM, Hadriel Kaplan <[e-mail]>wrote:

> Yes, but in theory we don't need to support ROAP forking to let you do
> that, because you don't need to do it that way.  For example you can write
> the JS to send a "session request" message without any ROAP/SDP, and as each
> "session response" comes back from each team member with a ROAP OFFER, the
> local JS creates a new PeerConnection and sends back to each team member a
> ROAP ANSWER from you.  So basically mimicking the offerless-INVITE model of
> SIP.
>
> Or send a JS "session request" and get back a "session response" from each
> team member without any ROAP, then create each PeerConnection and send a new
> distinct "session request" with ROAP OFFER separately to each team member.
>  Kind of like a 3xx response model of SIP.
>
> Or send a JS query to get back a list of URLs each representing a team
> member, and create a PeerConnection for each and send a ROAP OFFER to each
> URL.  Really like a 3xx response model of SIP.
>
>
If you do not need to inter-operate with SIP you can implement forking like
functionality with signaling only. If you do, you need forking support (or a
some sort of SBC or gateway solution).

In general, I think it makes sense to support forking if it does not greatly
complicate the WebRTC client implementation, makes API more complex or has
some security implications. Forking support is a good thing, since it will
allow for better interoperability and more flexible future signaling
scenarios. I don't think it is hard to add support for forking in WebRTC
(all you need to do is to reuse the same ICE candidates for all calls in the
same browser session), and this model encourages better resource usage. It
does mean that the same TURN/STUN servers should be used for all calls in
the session, but other then that it does not limit any of the functionality.

_____________
Roman Shpount