WebRTC Technology has been paving the way for innovation in Real Time Communication since its inception, giving developers access to flexible web APIs for video, audio and data channeling in order to create services that are liberated from the restrictions of plugins.
Developers have been leveraging WebRTC to create a host of services including live expert customer service, virtual shopping, easy instant voice and video collaboration without phone numbers, and much more.
WebRTC as a “service” from companies like GENBAND has allowed developers to produce and improve exciting services, despite its reliance on the somewhat complicated Session Description Protocol which operates behind the scenes to create peer to peer connections.
The creators of the ORCA (Open Real Time Communications API) community group have been working on simplifying the complexity by developing what they consider to be a better alternative to standard WebRTC approaches. They recently changed their name to ORTC CG (Object Real Time Communications Community Group). The group was formed by Erik Lagerway (Co. Founder/Product Executive) and Robin Raymond (Chief Architect) of the RTC company, Hookflash in 2013. They are heavy influencers of WebRTC Technology and WebRTC 1.0, but simultaneously formed ORTC CG as a way to generate a solution to what they felt addressed a potential flaw in the direction of WebRTC technology.
Other developers in the group come from major companies and organizations like AddLive, Dialogic, Google, Microsoft, and W3C. Most of the community also participated in the primary WebRTC Technology development group, and found common ground in addressing what they saw as the limitations of SDP for managing signaling processes. They plan on launching a demo of their API solution in the 4th quarter of 2014.
As far as the limitation of scope goes, the ORTC CG takes issues with the fact that SDP forces developers to dictate the media being transmitted for both the peer and remote receiver. If the developer’s RTC application is sending just audio, then the receiver can only reply with an audio stream. There are ways of working around this, but it just makes the whole process more challenging.
Lastly, in order to prevent isolation between the applications developed using the technology there would need to be an agreed upon browser vendor/version for the services to work on. One provider’s variation on SDP would need to become dominant in order for the signaling to work across various endpoints. This sort of monopoly could cause stagnation in innovation.
So why does all of this matter?
The ORTC CG’s new API solves more challenges than just the limitations of SDP signaling. Right now several developers are strongly opposed to the standardization of WebRTC 1.0 because of its shortcomings. A major figure in this opposition is Microsoft, whose support is crucial in the standardization of the technology as a whole. Microsoft does, however, support the new ORTC API and has sent developers to assist with the community group. They have even started to produce their own demos with the technology. The incorporation of the ORTC CG’s API into WebRTC 2.0 (while keeping backward compatibility to the current SDP specification) could be significant for the eventual standardization of WebRTC technology across the web.
In the end, the ORTC CG is seeking to give more power to the developers, which was the intent behind WebRTC technology from the start.