Topic of the month covered by WebRTC “activists”
In 2015 I have been posting the WebRTC Topic of the Month on the Upperside blog. This is now moving here, to TheNewDialTone.
WebRTC is rapidly changing with new services, announcements and advancements of the technology.
The idea of WebRTC Topic of the Month is to take one topic each month and bring the opinion of the leading WebRTC activists about it.
For this month the topic is: The impact of ORTC on WebRTC deployment and adoption
ORTC Background
ORTC is a pretty hot topic on the technology side of WebRTC. Many still see it as a competing technology to WebRTC and therefore are worried it will delay adoption of WebRTC.
On the other hand, some are not clear technically what new capabilities ORTC brings and what are the challenges associated with it. In a very high level, it is not correct to compare ORTC with WebRTC but rather to compare it to SDP (which is how media attributes are described in WebRTC and SIP). To better understand ORTC and how it is used read, this short post that sums it all up.
Now that you have read this post and better understand ORTC, you know it is simply a next phase of the WebRTC1.0 standard, some refer to it as WebRTC1.1 and not so much as WebRTC2.0 (meaning not a revolution but rather evolution).
Let’s get to the answers to the question about the impact of ORTC on WebRTC deployment and adoption.
Starting with my opinion on this topic.
Amir Zmora
Link: TheNewDialTone
ORTC was once viewed as a technology competing with WebRTC. This is no longer the case.
- It is a next step of the standard
- It gives more fine grain control over media
- It doesn’t mandate sending SDP from one side to the other but rather allows applications to decide how they want to exchange media information between session parties. The actual setting of the media attributes is through APIs
There are interoperability “risks” but they can be mitigated in the application and through a shim that will be available.
In practice, there is no reason to hold off adoption and deployment of WebRTC services due to ORTC.
Those who do so are probably not informed enough about ORTC or simply use it as an excuse.
Tsahi Levent-Levi
Link: BlogGeek.me
None.
Edge is interesting, but lacking adoption that is important. Here are the gruesome numbers.
We’ve seen a few companies initially adding ORTC support to make it to the initial launch of ORTC in Edge – but little more than that afterwards.
Dan Burnett
Link: Standards Play
As usual, I view everything with my standards hat on.
Although ORTC’s original positioning as a competitor to WebRTC was confusing for the industry in a way that definitely delayed adoption, the message is finally getting out that ORTC is now NOT a competitor.
There is an agreement that WebRTC is the standard. Also, there is a set of guidelines, agreed to by all involved, on how the two efforts are to merge together going forward. This has removed the competition concern as a reason to delay adoption.
Although Microsoft has only publicly committed to ORTC so far, plans to implement WebRTC 1.0 APIs in a shim library on top of ORTC are intended to address differences as the two standards merge, strongly suggesting that standards-compliant WebRTC 1.0 applications will eventually work in EDGE as well as Chrome, Firefox, and Opera.
Chad Hart
Link: WebRTC Hacks
ORTC is net benefit for WebRTC and will only help to increase WebRTC adoption. I see two groups: those that are happy with the status quo of WebRTC and those that aren’t.
For those that are happy with WebRTC today and do not want to deal with the new ORTC API’s there is little to fear. The W3C has promised to keep the next version of WebRTC – WebRTC-NV – backward compatible with the 1.0 spec as it adds new ORTC API’s so no one needs to re-write their apps.
The majority of WebRTC developers use some kind of framework, so the real burden is on the makers of those frameworks to maintain continuity as they incorporate the new ORTC API’s. When they do implement the ORTC API’s, they will have the option of exposing new capabilities that are valuable to their users.
For all but the relatively small number of WebRTC framework makers out there who need to evolve their platforms, ORTC will just present new options without taking away what’s there. In fact, the adapter.js part of the WebRTC project is already proving to do a great job in helping Microsoft’s Edge ORTC implementation interoperate with Chrome and Firefox web apps.
Then there are those who are not happy with WebRTC today. These are often more advanced users who want to do more than a simple peer-to-peer talking heads app. Some examples are large scale real time broadcasting, large party video conferencing, embedded IoT devices, finely tuned mobile apps, or those that need to have lower-level control over networking and media parameters.
These applications often break some of the assumptions used in the WebRTC 1.0 spec. Workarounds often exist, but they are messy which is one reason why the W3C is working to incorporate the work of the ORTC Community Group into WebRTC-NV.
For those who aren’t happy with WebRTC today, ORTC could be what pushes them to use WebRTC in the first place. This was the case with Microsoft.
ORTC will enable a lot more innovation in the way RTC is used. That will lead to more exciting apps and ultimately more WebRTC adoption on top of existing use cases.
Want to joint Topic of the Month as contributor?
Rules of engagement for Topic of the Month: No product/company promotion. Contributors should have a wide market perspective.
If you would like to join this initiative and have your opinion published here in future posts please drop me a note.
Leave a Reply