Today, we are excited to announce that version 2.3.0 of the OpenTok iOS SDK is available to our developers.
In addition to support for iOS 8 and Xcode 6, we also want to share details about additional new mobile features which we’ve outlined below.
- Build Voice-optimized experiences: Audio Levels API and UI best practice example. See more.
- Audio Driver API: implement custom Audio I/O in your app.
- Support for the armv7s architecture.
- Support for the iOS Simulator.
- Intelligent Quality Control features:
- Video recovery from audio-only fallback.
- Connection Quality API: a warning callback to notify that audio-only fallback is eminent.
- Audio-only fallback redesign.
Learn more about OpenTok iOS SDK 2.3.0 here.
We always want to share as much as possible with our community so today we’re sharing a description of how we developed the opentok-editor collaborative editor using ot.js and CodeMirror. You can see the editor in action at meet.tokbox.com and you can see how to use it for yourself at the opentok-editor github page. We love to see people using our open source projects so please feel free to file issues and contribute pull-requests to this project on Github.
Signaling between client end points has always been an important facet for most interactive web applications. The use cases range from text chatting to multiplayer games to driving a robot remotely. In the world of HTML5, most developers establish signaling through websockets, long polling and server side events. However with the advent of WebRTC, data channels joined the ranks and the question posed by many developers is “Where do data channels fit in the equation?”
Data Channels provide a way to send binary / text data to another peer over the browser. The data channel api is very similar to web sockets when it comes to sending different types of data. It works peer to peer without the need of a centralized server or an additional hop in most cases.
We know readers of this blog are enthusiasts and thought leaders when it comes to WebRTC implementations. Three months ago Mozilla launched its own experimental WebRTC feature powered by OpenTok into its Firefox Nightly channel. Now they’re calling on you to get involved and test it out as they release it into Firefox Beta.
Since launching this experimental feature it has evolved, and will continue to evolve, but the goal remains the same, to make audio and video communications simple and connect everyone with a WebRTC enabled browser.
When creating new services and products, organizations always face a challenge whether to buy or build key underlying components and functionality. As WebRTC attracts an increasing degree of interest, we regularly hear from customers that they are considering the trade-off around the decision to buy or build. Many go so far as to try and build their own real time video or audio solution before they turn to a hosted platform like OpenTok. Not surprisingly given the business we are in, we come down pretty strongly on the side of leveraging a hosted service.
Come November, it will have been four years since we launched the OpenTok platform into the world. Can you believe it? During that time technology has evolved, market demands have shifted, and mobile has become king. As your ambassador to real-time communications, we’ve stayed on top of that ever-changing ecosystem.
That’s why we have some important news to share with you – The OpenTok 1.0 platform will no longer be supported as of January 5th, 2015. It was a hard decision to make as the TokBox team and you – the OpenTok community – have dedicated so much time and energy to building on top of it.
WebRTC is changing the way enterprises communicate within their organization and with their customers.
As a result of the large and diverse range of different use cases of WebRTC in the Enterprise world, there are inevitably a number of challenges that need to be addressed. We’ve compiled a list of some of the key challenges and solutions for consideration with regards to implementing WebRTC for Enterprise solutions: Signaling, Multi-party, Interoperability, Quality and Scalability.
SIP? XMPP? JSON? Rumor? The right answer to the signaling question probably depends a lot on your starting point and on what you’re trying to accomplish.
While many people think signaling should be standardized; others think we already have the answer in SIP or REST. Some maintain that the lack of a signaling specification (beyond the need to support SDP offer/answer) is a huge gap in the WebRTC standard.
Next week TokBox will be attending the Gartner Catalyst Conference in San Diego, August 11-14. We’re looking forward to being a part of the conversation about how technologists can leverage mobile, cloud, and big data to drive more operational effectiveness and competitive advantage. At TokBox we passionately believe that real-time communications, and WebRTC in particular, should be a core component of this conversation.
Throughout the course of the conference, the TokBox team will provide insight into the growing popularity of WebRTC within enterprise applications. The impact is beyond traditional communications systems and that is exactly what our CTO, Badri Rajasekar, will be talking about during his session:
**July 25 UPDATE Since launching their experimental service powered by OpenTok over a month ago, Mozilla has received a lot of positive feedback. As of today, they are making the WebRTC feature available through Aurora so that they can gather feedback from even more users. It’s important to note that they are still in the testing and experimental phase and are keen to get your feedback as always. We’ll keep you posted as the feature develops.**
TokBox has always believed in the power of WebRTC to change the way that people communicate in the digital world. Not just in browsers, but also on phones and other connected devices as well as the amazing devices of the future that we know are coming.
Last night TokBox released patches to the OpenTok iOS and Android SDKs to resolve a recently identified OpenSSL vulnerability that affects the majority of web service providers.
In early June, a security advisory was issued by OpenSSL, quoting the following:
‘An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server.’