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

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

2011/10/29 Roman Shpount <[e-mail]>:
> 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).

Even more, some WebRTC scenario could just not allow forking at all.
Since the in-the-wire protocol is up to the developer he does not need
to accomplish all the features and use cases of SIP, but just those
his scenario needs.


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

I hope this is achieved as it opens the door to cool  scenarios
(indeed this is required in SIP, but could also be required by some
future scenarios we cannot imagine right now).


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