Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway)

[Hadriel Kaplan <[e-mail]>]

On Oct 29, 2011, at 1:29 PM, Iñaki Baz Castillo wrote:

[snipped example implementation scenario]

> Conclusion
> ----------------
> 
> SIP media forking can be implemented in JavaScript without mandating
> special requirements in WebRTC for interoperating with "legacy" SIP
> (why do we call "legacy" to SIP???). And we just need  tu use existing
> SIP mechanisms.

Right, as I said before, we don't actually have to implement ROAP forking in the browser, because the JS+Server code can be clever enough to do it, even to SIP.

The question is if we should implement it in the browser anyway, to make things work better for the scenarios where they do go to SIP.

We know that even an interworking-function can "hide" the forking, because they do that right now for SIP-H.323; but we also know that doing so is error-prone and causes media-clipping.

So if it's not too difficult/complicated to implement, handling it natively in the browser is likely to yield the best user experience.  And the nice thing is that if the browsers get it wrong, or the WebApp doesn't want to do it, the JS+Server can still fix it or make it not happen.


> No signaling gateway is required (of course !!) nor a media gateway
> (if second bullet in "Assumtions" section above is satisfied).
> 
> We all are happy (but those who have in mind a market selling
> WebRTC-SIP gateway boxes and want that the specs satisfy their
> business model).

I hope you don't think I'm arguing for things for the purpose of selling WebRTC-SIP gateways.  I'm trying very hard to list all the things a WebRTC domain must do if it wants to *avoid* gateways.  
[Not because my company doesn't plan on selling WebRTC-SIP gateways - but because people should use gateways/SBCs when they need to for security/control/etc., but not simply to interoperate.]

-hadriel