Microsoft Teams, Direct Routing and SBCs (pt.1)
My journey creating a scalable SBC as a Service for Microsoft Teams Direct Routing is over at Snapsonic.com.
WebRTC + SIP over WebSockets arrives at SignalWire
I haven’t blogged here in some time, so I figured that since the topic is relevant this would be a good opportunity to dust off the old blog (webrtc.is / sipthat.com) and post something we have been working on at SignalWire. I am quite passionate about WebRTC and real-time communications so it’s great to be helping bring it to life at SignalWire!
We all know and love <cough> SIP, so we decided we would enable the use of SIP over WebSockets at SignalWire. This new offer also enables functionality like WebRTC with SIP over WebSockets.
This means our customers can now use off the shelf JS libraries, like JSSIP to create basic web experiences for their users, powered by SignalWire. It used to be a bit of a PITA, to create services that provided users with seamless online communications. Now it’s a breeze, and when using SignalWire it’s also very affordable.
For now, we are enabling basic calling and video capabilities, the advanced functionality (including video conferencing) will come in conjunction with a future release of a SignalWire RELAY JS library.
Personally, I can’t wait to see what creative minds will build using this technology with SignalWire on the backend.
If you want to know more about SignalWire’s new WebRTC + SIP over WebSockets offer, you can read about it on the SignalWire product blog.
Hookflash, Google and Microsoft lead on ORTC / WebRTC 1.1 Public Draft
The first ORTC Public Draft Specification has been published, authored by Hookflash, Microsoft, and Google. (http://ortc.org/wp-content/uploads/2014/08/ortc.html ) This specification extends WebRTC 1.0 with new functionality to create a WebRTC 1.1 API with exceptional flexibility and no loss of compatibility.
Like WebRTC, ORTC (Object Real-time Communication) enables plugin-free real-time communications for mobile, web and cloud, but is specifically tailored to provide the direct control needed to enable advanced multimedia and conferencing features.
“We heard developers say that they wanted more direct control over the technologies available in WebRTC. At the same time, we didn’t want existing developers to have to start over with a new API. ORTC is our proposal for how we can accomplish both of these things – a new set of APIs for direct control, that builds off the existing WebRTC 1.0 API set. As an evolution of the existing API, we consider this WebRTC 1.1” comments Justin Uberti, Google Tech Lead, WebRTC. “We’re grateful to Hookflash for their work to get ORTC off the ground. They have been instrumental in making this cross-industry collaboration happen, and we look forward to continuing our work with them.”
This newly published public draft has come a long way since the W3C ORTC Community Group was formed in mid-2013. As it has progressed from an initial set of ideas to a fleshed-out draft complete enough for implementations, several companies have gotten closely involved, with Microsoft and Google now joining Hookflash as authors of the emerging specification.
“We have been working hard to get the ORTC API to the point where it can be implemented. This would not have been possible without the initial and continuing work of Hookflash”, commented Bernard Aboba, Principal Architect, Skype, “We also are excited by the ORTC API’s support for advanced video features such as SVC (Scalable Video Coding) and simulcast. The Javascript Object API approach has made these advanced video technologies more accessible, which has been difficult in the past.”
The W3C ORTC Community Group now numbers more than 60 participants.
“We believe the contributions to WebRTC 1.1 / ORTC will allow web communications technology to become ubiquitous and transcend nearly all communications technologies that came before it” says Hookflash Co-founder, Erik Lagerway, “We are honored to be working with some of the brightest minds at Google, Microsoft, and the other contributing members in the ORTC CG to mature WebRTC into a universal go-to toolkit enabling communications across the globe.”
For more information on ORTC, see:
W3C ORTC Community Group
ORTC.org – History and FAQs
WebRTC.is – ORTC & WebRTC news
Hookflash enables real-time social, mobile, and web communications for integration of voice, video, messaging with federated identity into world leading software, enterprise, applications, networks, mobile and computing devices. Hookflash and Open Peer are trademarks of Hookflash Inc.
Developers can register at (http://fly.hookflash.me) to start using the Hookflash RTC service and toolkits today. For more information on Hookflash RTC toolkits and White Labeling please visit Hookflash http://hookflash.com.
Come and work at one of the coolest companies in the space! We’re now hiring for these development positions: iOS, Android, Node.js & C++ send us your resume: jobs@hookflash.com.
Hookflash – Trent Johnsen
855-466-5352 Ext: 1
WebRTC, ORTC and OTT Comm
There’s a lot of noise and plenty of dust getting kicked up around WebRTC these days. Every hour it seems there is another company announcing support for WebRTC or have built an app that uses the technology. In many cases it’s an extension to the existing offer, where WebRTC is leveraged as a web-based SIP softphone for instance.
For the love of Pete, does the world need yet another phone?
What does excite me is when I start thinking about the effects that WebRTC and ORTC will have on rich media OTT (Over The Top) communications moving forward.
If we look at the success of apps like Whatsapp, Tango, Viber, Voxer, Facebook Messenger etc etc these are all OTT applications that have already won in mobile communications. Placing a phone call, is nearly the last thing a teen or twenty-something user is looking to do with their phone. Just by pure observation, we can see this demographic using mobiles devices for messaging and now video chat more and more. Btw, this is the generation that will be leading our Enterprise companies in the not so distant future.
We know this, but we still insist on integrating old tech that does not seem to be accelerating in growth. Why? To answer my own question, “because lots of us continue to buy VoIP phones and SIP PBXs for our business”. And to that I say, good for you! But that is not the real opportunity for those developers who embrace WebRTC and ORTC.
WebRTC & ORTC will allow us to push the envelope and do things we can’t do today. And to do things we can do today but in a much more efficient and enjoyable manner. Maybe RTC will find its way into social news, citizen journalism, or maybe media rich banking, healthcare and CRM apps, in your TV, mobile devices, browsers et al. The possibilities are nearly endless but one thing is quite clear, it’s not going to happen unless we change our current approach.
In order for WebRTC to win, in mobile, web and server-side. We will need a JavaScript friendly object model, not an Offer/Answer model based on telecom of old. Even if you don’t share the same opinion, you owe it to yourself to take a look at what’s happening in the W3C ORCA Community Group. For me, (and a bunch of others) there lies the future of WebRTC.
/Erik
For disclosure purposes, I am a co-author on the ORTC API and a co-founder at Hookflash .
Stop Talking to Yourself. Go beyond the RTCWEB Silo!
RTCWEB / WebRTC is designed to let two or more browser-enabled devices communicate P2P (peer-to-peer) with audio, video or data. But there’s a big catch. The browsers can’t communicate out of the box unless some undefined “external process” gathers information about each browser and hands the information to the other browser.
This mystical external process is known as “on the wire signaling”. Gathering information from a browser/peer needed to communicate isn’t incredibly difficult for a moderately talented programmer, nor is exchanging the required information. All that would be required is some kind of go-between web server and a socket or two. This solution is relatively simple and there are other companies setting themselves up to provide that kind of service offering.
But that kind of signaling will quickly becomes unwieldy to manage in the real world and misses many critical use cases and components in much larger deployments. The overriding presumption in such a model assumes both ends want to communicate and does not define how they want to communicate, let alone addressing very complex security issues.
So what does make up a robust and complete P2P communication solution?
A well thought out P2P solution should addresses these concerns:
- Initiation of communication between peers that are not actively expecting communication
- Exchanging the types of communication desired (audio/video/text/etc.)
- Allow peers the option to allow or disallow communication
- Allow peer to disengage communication at any time gracefully
- Changing the nature of the communication at any time (adding or removing media types like audio/video/text, media on hold, transferring sessions to other participants, etc.)
- Handle users’ identities so that users on independent systems can interoperate (and identify themselves when communicating)
- Handle users logged into multiple locations as the same user
- Find users to communicate with by their known identities (social, generic, 3rd party, etc)
- Validate the identity of the user you think you are connecting with
- Secure communication channels in a way that even servers involved in the “communication setup” are not able to decrypt information exchanged between peers
- Handle group conversations amongst peers without needing servers to relay the data
- Handle communication to applications outside to the browser (e.g. interoperate with mobile apps)
A well designed P2P platform should be designed to enable users on various websites to talk beyond each respective web silo. Users of one website can find and communicate with users on another website and even to users on mobile devices.
It should work with your existing identity model. Alice and Bob on your website are still known as Alice and Bob in the P2P network. You don’t need to administer and map a separate database of usernames and password that would be required with other legacy signaling protocols.
The network should allow users to locate other users by their social IDs, phone numbers, email addresses or by using your own custom defined identities – social or otherwise. It should be built with strong security in mind. Each user has their own private and public key, which when tied with an identity model yield strong proof of identity with completely private communications between peers.
A developer should be able to take the open source libraries and rapidly build and deploy powerful client applications with all of these features built-in and deploy without the headache of managing a communications network. No web developer I have ever met volunteered to be the one trying to figure out the complex ins-and-outs of everything that a good P2P design will resolve. So, I ask you, do you as a developer really want to be stuck in a little silo of communication, maintaining your own custom communication signalling protocol?
If you are looking to leverage WebRTC in a browser or if you just want to build a powerful communications feature into an app, you owe it to yourself to do the research. Before you get headlong into your project and find out the tech you chose was not up to the challenge, take a look around. Libraries like the one found in the Open Peer project could very well fit the bill.
—
Authored by Robin Raymond, edited by Erik Lagerway
Hookflash posts now on Tumblr
I have decided to stop posting Hookflash content here, all of my new Hookflash posts will appear over at Tumblr.
/Erik
Robert Scoble on Hookflash (teaser)
Robert Scoble asked Trent Johnsen to come down to the Rackspace offices in San Francisco to talk about Hookflash. Co-founder – Erik Lagerway came in via Hookflash from North Vancouver for the meeting. The entire video is much longer 😉 We had a great time, thanks Robert!
Hookflash at Innovation Showcase / Enterprise Connect
.
Hookflash CEO – Trent Johnsen, will join Dave Michels for Innovation Showcase (on the keynote stage – part of Enterprise Connect), in Orlando on Tuesday March 27, 2012.
WebRTC is live. Flash, take cover!
Update 2: To the hundreds/thousands of repetitive spam tweets / twits, “Will WebRTC replace / kill Skype”, the answer is NO!! It will not. WebRTC is using broken Jingle in the browser, it does not support chat and can only make and receive calls., there is no buddy / contact list to speak of etc etc. NO it will not replace Skype. Stop with the spam tweets already, please!
Update: It seems to me that until all the browsers are on board, native clients will be required to make this go. Which is not outside the realm of possibility, considering Google has open sourced the GIPS audio and video engine along with WebRTC.
Something to remember, WebRTC is not RTCWEB! It may sound silly but it’s true. WebRTC is a Google-centric project using Google code etc. RTCWEB is essentially an IETF effort, a working group driving towards open real-time communications on the web. They are not the same, which can be rather confusing.
— Original Post —
Google has been busy it would seem, last night WebRTC appeared to the public for the first time. This has some pretty serious implications for Flash, which was the de-facto technology one had to use to get real-time communications in a browser, that has now been circumvented, at least to a certain degree.
The sessions are not run by a signaling protocol per se, not Jingle, no XMPP, not SIP not anything we have seen before. All the session management looks to be coming from libjingle. Which, to me means Jingle is in the browser.
A few early comments:
1. Where does Google stand on websockets? Google have said they will block it if an exploit emerges.
2. Chrome, Opera & Firefox are the supported browsers. Where does Safari and IE land? My guess is that Microsoft will not be in any hurry to implement this considering their recent Skype acquisition.
3. Web-cam captures from HTM5 has not been ratified, although this is likely not as serious as the former points.
Open and secure alternative to Skype
Imagine a new secure P2P (Skype like) offer that also supported SIP in the client. You could use the client software on it’s own (just like Skype) or attach it to just about any VoIP service or phone system for free.
Does it make sense for consumers?
Does it make sense for business users?
Is there room in the market?
Would you use it?
Martyn Davies chimes in…
I would use it, but as a telecom industry insider, I know that I’m not the average business user or consumer. As to whether there is room in the market, I think that depends a lot on what Microsoft do with Skype now that they own it. From a business point-of-view, their efforts are focused around OCS/Lync (and software licenses), so Skype there is not adding to their central proposition. Skype has a lot of users, but produces very little revenue, since the majority just use the free services. As a Skype competitor you would have the same problems getting to the cash.
Skype was really the first company to take VoIP and make it completely trivial to install and use. To do that, they had to take some liberties and deviate from standards (like SIP), so that they could add the magic that made it work from behind firewalls, add security and self-configuration, and integrate video so seamlessly. Like Facebook, once it is clearly the biggest of its kind of services, it becomes the community that everyone must join. I can’t see that another Skype-alike has a way in, unless Microsoft significantly change the rules now.
WebRTC.is 