It’s hard to believe that in this day and age of digital transformation you still have to announce yourself when you ring a contact center. Or even worse, why you have to repeat your account details from one agent to the next. It’s among the most frustrating of customer service experiences, not to mention inefficient and costly for operators.
Cable companies and television networks can’t take a trick at the moment. As if digital disruption and cord cutting wasn’t making life tough enough, now comes the rise of participatory broadcasting, the phenomena where viewers collaboratively interact while consuming content, and maybe even participate.
Still coming to grips with on demand and online/mobile viewing, traditional broadcasters must now find a way to provide immersive and engaging viewer experiences to compete with the likes of Facebook Live, Meerkat and Periscope.
The popular technology media would have us believe Flash is the worst technology flub since Windows Vista/Apple Maps. It is nothing but a giant security flaw and should never have existed. But pause for a moment and consider this – if it weren’t for Flash there would most likely be no Netflix, no Meerkat or Periscope, no YouTube, no Facebook Live.
You see, while these services may not have all been built on Flash originally, they all stand on the shoulders of the pioneering work Flash did around online video. So, while we’re all quick to celebrate its downfall and lament its many obvious flaws, let’s pause for a moment and remember that if not for the pioneers who inevitably make mistakes (Adobe with Flash perhaps more than most), there would be no progress.
WebRTC is maturing and we can see the needs in the market evolving along with this.
However, with the increased need for rich, digital experiences comes the challenge of building more advanced applications. We know that building real-time video communications can be challenging, especially when it involves more than two participants. To pull off a multi-party call using WebRTC off-the-shelf you’ll need a strong backend infrastructure and a deep understanding of media processing. That’s why we are looking forward to exploring this topic with WebRTC expert, Tsahi Levent-Levi, founder of bloggeek.me, in our upcoming webinar.
The world has indeed changed in the last year as WebRTC has made massive strides both from a standardization and from a market adoption point of view. A whole host of innovative applications are succeeding on mobile and desktop end-points.
But despite another 12 months of progress, one of the key points of contention that remained stubbornly unresolved was the great video codec debate: Should VP8 or H.264 be the Mandatory-to-Implement Video Codec for WebRTC? It was a welcome and surprising move that led the IETF Working Group to finally arrive at the following consensus just last week:
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.
A major vulnerability was uncovered yesterday which affects a majority of web service providers. The exploit is related to OpenSSL’s heartbeat extension which could enable a malicious attacker to access private keys. The bug has been present in OpenSSL since December 2011, and was brought to light yesterday. You can find more information about the exploit termed “Heartbleed” (CVE-2014-0160) here.
Our operations team reacted immediately to this and has taken the necessary steps to secure our infrastructure, ensuring the appropriate secure versions of OpenSSL are in place.
Connectivity, we at TokBox believe, is one of the cornerstones of real-time communication applications. So we are happy to announce that we now support TURN over TCP.
There are several technologies which are used to help establish connectivity in WebRTC. The first mechanism is using a protocol called STUN. STUN uses a ping-pong mechanism to find the public IP of a client end-point so that a peer-to-peer session can be established and one can traverse a firewall. While this is useful in a number of scenarios, there are cases where one could be behind symmetric NATs, where STUN does not suffice. TURN helps in these cases. TURN is a mechanism by which real-time media can be relayed through a TURN server to punch through firewalls. OpenTok seamlessly supports STUN and TURN so a developer doesn’t have to worry about how to setup up these servers, scale them, establish connectivity etc.
At TokBox, we aim to push boundaries and deliver the best possible WebRTC-enabled experience for application developers building face-to-face video applications. One of our guiding architectural philosophies has been to provide the right primitives for developers to build rich and powerful applications. In addition, we want to make sure we abstract the underlying nuts and bolts and enable the cloud service to dynamically react to changing environmental conditions (bandwidth, packet-loss, etc.) in order to deliver the best possible experience.
The multiparty stream routing component of the OpenTok platform is also capable of shaping traffic in real time. Let’s take a look at how this this capability delivers a significantly improved quality of experience for users.