Re: VS: Teleco Integrators vs Web Developers vs Browser Implementers

But two major ones actually support it, and only one against, while Apple is silent (doesn't mean anything, since there is no official statement)

We have rather good progress I would say. Browsers should talk with browsers using current approach without big problems, if we are talking about interop with other devices/software - feel free to build your gateway 

-Alexey

On Jul 5, 2013, at 22:28, Robin Raymond <robin@hookflash.com> wrote:

> 
> No, I would like to make a proper modularized API that is useful for _everyone_ and not for just _me_.
> 
> I'm NOT the only one having troubles. Even SIP developers are lining up against this API, and they are using a "standard" by your definition. Here's some of the feedback from people actually trying to use this API:
> https://docs.google.com/spreadsheet/ccc?key=0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=0
> 
> I'd like to propose an API that specifically doesn't needlessly push a monolithic SDP know-everything about the transports, connections, state, constraints and streams embedded in an obtuse format all bundled into one blob that is not compatible with of the previous standards for existing standard networks, and stop a needless and intrusive offer / answer state machine that doesn't need to exist for an this kind of an API.
> 
> As an aside, and as far as I know, two of the four major browser vendors do not support this one WebRTC API. We are far away from having the promised universal access for everyone that WebRTC promised.
> 
> -Robin
> 
> 
>> <postbox-contact.jpg>	Martin Steinmann	5 July, 2013 2:13 PM
>> >From: Robin Raymond [mailto:robin@hookflash.com] 
>> >Sent: Friday, July 05, 2013 1:50 PM
>> >To: Martin Steinmann
>> >Cc: 'public-webrtc_w3.org'
>> >Subject: Re: VS: Teleco Integrators vs Web Developers vs Browser Implementers
>> > 
>> >
>> >Right, the current API is ill suited to support leading edge protocols. I 100% agree with you. That's why I'm proposing an alternative that allows for >today's protocols but doesn't prohibit the future from happening too.
>>  
>> OK, so you would like to add a new use case that is important to you, but not (yet) to most others.  If stated as such I would agree that this should be a basis for a discussion, provided it does not completely derail the existing process and timeline for the rest of us.
>> --martin
>>  
>> 
>> >
>> >And even though I didn't bring up the topic because I explicitly try not to promote on these forums, Open Peer is "open". It's not official "standards >track" via an official "standards body" but a open project like many other open projects. As a reminder, XMPP did not start out in the standards >track either when it first came out. Not every standard has its origins being designed by a committee before being crowned a "standard".
>> >
>> >-Robin