Re: [rtcweb] Usecases for innovation.

[Ravindran Parthasarathi <[e-mail]>]

IMO, low level API are nothing but exposing (secured) RTP library API from browser to web developer. Of course, it helps in case the web development focused on special web-application like

1) Proprietary SDP next generation mechanism (if ROAP proposal is accepted as default API mechanism) implementation. Of course, lot of flames on SDP already and alternative proposal for the specific deployment is possible.
2) Signaling mechanism like H.245 (Media description of H.323) which does not direct well fit with SDP
3) RTP specific enhancement services like adding proprietary RTCP extensions.

But I don't whether the above application will be interesting to typical website developer (not telephony or UC provider) and also, Browser vendors spelt out in the last meeting that it is tough to maintain these API in browsers.

Thanks to Randell for sharing his experience and burning issue in WebRTC. I understand that security & privacy should be the main focus of this WG. 

I raised standard signaling issue as it is normal response in any real-time (telephony or unified communication) development that signaling is less important and let us focus on service but after couple of releases with this mentality, signaling manageability go for toss which calls for hack & re-structure in signaling layer. The proprietary signaling helps for time to market but provides the manageability & scalability issues in the long run. Lot of so-called SIP based mechanism works based on unsubscribed NOTIFY & INFO mechanism. I have seen these kind of proprietary implementation wherein the companies struggles to move out of it because of developed service on top of this protocol infrastructure. I'm more skeptical about "no standardizing signaling protocol" argument as the argument mostly comes from VoIP & telephony service providers or OEM.

Thanks
Partha

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf
>Of Randell Jesup
>Sent: Wednesday, November 02, 2011 11:25 PM
>To: [e-mail]
>Subject: Re: [rtcweb] Usecases for innovation.
>
>On 11/1/2011 12:02 PM, Wolfgang Beck wrote:
>> On Tue, Nov 1, 2011 at 3:18 PM, Iñaki Baz Castillo<[e-mail]>
>wrote:
>>> 2011/11/1 Tim Panton<[e-mail]>:
>>>> I've repeatedly been asked for use-cases for innovative applications
>of webRTC
>>>> to justify my contention that we should be providing a low-level
>framework,
>>>> not an embedded legacy compatibility application.
>> [..]
>>> Indeed most of the discussions in this WG are about how to make
>>> ***current*** SIP devices to work with a WebRTC scenario. It's a
>>> limited vision of WebRTC in which the main interest is to make profit
>>> of this new spec within telcos business. Bad IMHO. But, where are
>>> those "innovative" and "crazy" Web folks right now? why 95% of people
>>> discussing in this ***open*** WG are telcos? So this is also their
>>> fault, the fault of people not participating here and now.
>
>Well, the IETF's AVT group has a strong component of telephony (really
>VoIP/Video) people, so it's not that surprising.  Most of the "web"
>people would be focused on the W3C side of things, and have minimal
>interest in the plumbing. ;-)  Mostly only in how the exposed interfaces
>affect them, but they (generic website/app developers) haven't really
>seen what's proposed yet - and most of them don't even follow the W3C,
>which is more major site vendors and browser people I believe.
>
>I straddle both - long-term core Mozilla contributor, now employee, but
>in the interim spent 7 years working on videophones. But I'm no expert
>on website/javascript-library design.  (Mozilla does have people more
>focused on that involved.)
>
>> Well, I'm working for a telco. Hadriel' employer sells equipment to
>> telcos and telephony providers.
>> Still our proposals to avoid standardized signaling and to depart from
>> classical telco signaling flows were not well
>> received by the crazy web folks. The world has turned upside down..
>
>We (browser vendors) have a strong focus on getting something
>deployable, without unduly limiting potential innovation.  We also (as
>has been mentioned) have concerns over complexity exposed and the
>resultant reliance on (rarely-if-ever-updated) JS frameworks.
>
>Quite honestly, the largest problem we have is NOT signalling; one way
>or another media and data channels can get open and negotiated.  The
>biggest problem and hardest one to "solve" (it's not truly "solvable")
>is security and privacy and the user-interaction aspects of that.  The
>technical issues of signalling, congestion control, and data channels
>are all eminently resolvable (even if there is no universally-agreed
>'best' solution).  Security and privacy are far harder, and the
>solutions less satisfying.
>
>So, if you have brain cycles to born, spend them on security, IMHO.
>
>(Note: personal opinions, not official Mozilla position, though
>"Mozilla" may agree with me)
>
>--
>Randell Jesup
>[e-mail]
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb