T-Mobile has been supporting mobile HDVoice for over a year. However, my sense is that not very many people are actually experiencing HDVoice. If they are, they might not even know it.
For example, two of my associates have the Google/LG Nexus 5 handsets on T-Mobile’s network. Both are the sort of people who would hear and appreciate the difference that HDVoice makes. That said, both were initially of the impression that the Nexus 5 did not support HDVoice on T-Mobile!
This gave rise to the idea that we should devise a simple way to verify that a call was in HDVoice. If convenient, this would allow anyone interested to make a call between two handsets and know with certainty that the devices and call path was actually delivering HDVoice.
Devising such a test turns out to be very easy in a world of smart phones. All you need is a tone generator or a recording of a specific continuous tone.
This week OnSIP, long known for its popular SMB hosted PBX service, launched a new initiative offering WebRTC– based platform-as-a-service. Their core business has been the hosted PBX service, which is built upon SIP standards. This new service targets web developers who want to easily incorporate WebRTC into their applications.
The companies web site has been extended to include an area described as OnSIP For Developers which details the service offering. The principle behind the service is to leverage their core SIP infrastructure to deliver the signaling solution that WebRTC alone does not provide. Thus a web developer can easily create a WebRTC based front-end that’s backed by the scalable, geographically distributed infrastructure of the OnSIP hosted PBX platform.
For the several weeks we’ve had the new “Extended Range” Doorbot installed in place of the original device. The only apparent difference between the two is the addition of a short external antenna to enhance the Wifi connectivity.
Happily, the new unit does seem to stay better connected to our WLAN. In the past I was not comfortable evaluating the behavior of the Doorbot+client application given the questionable connectivity. At present the network connection seems sufficient to examine the behavior of the system as a whole.
I have the DoorBot client application installed on a variety of devices:
The fact that I’m using so many devices may be a little unusual, but I would expect that many families will use 2-3 devices, most likely a couple of cell phones (his & hers) and a tablet. Although a family with kids may well have more than this.
There are times when it would be handy to capture the video output of an Android device. This is typically what I need when writing something about an app that does something dynamic. For example, AudioTool by J.J. Bunn. As a tool for simple audio test & measurement capturing its output in real-time is the ideal way to communicate the measurement being taken. A static screen shot is fast & easy to accomplish, but video can be much more illuminating.
Quite recently I swapped out the Intensity Pro for an AVerMedia Game Broadcaster HD. This card has the ability to capture a 1080p60 stream. In so doing it drops every second frame to actually save a 1080p30 stream to disk.
I have an issue with “meta“ things. I blog, but I’m not engaged with the broader realm of bloggers. Blogging about blogging baffles me. Similarly, although I’ve been involved in the VUC since 2008, I’m not really engaged in the world of podcasters/internet broadcasters. I’m trying to work on this by sharing some of the techniques that I’ve discovered in doing VUC calls.
This post implies that Skype is tremendously popular in this space, and yet there is some desire to seek out functional alternatives. The author, Andrew Zarian, offers the following list of alternatives; Google+ Hangouts, Zoom, Apple’s FaceTime and Cisco’s Jabber. All are certainly worthy of consideration.
Last weeks commentary about how larger companies need to do better at rolling out WebRTC seems to have struck a chord in some circles. Apparently there are others who feel as I do that creating yet another free WebRTC-based video chat tool is just so much reinventing the wheel. It’s a pure marketing move aimed at establishing cool-by-association with something hip, shiny & new.
However, this critique we should reserve for developers who ought to know better. More specifically, those who are already involved in communications of some sort. Citrix’s GotoMeeting for example. If you have a track record of working with voice+video then WebRTC is novel, but it should not be entirely new.
In reality, the purpose of WebRTC is to enable an entirely new class of web developers with respect to online communication. That means word of WebRTC needs to spread. It needs to leave the confines of the crowd that knows that Opus is an audio codec, and find a home with the crowd that just needs to put some nice new feature into their web application. This is migration to face a much larger audience of developers.
For anyone who has been tracking WebRTC over time the interview is bit on the cursory side, but it does what is required. It gets people who are not already into communications excited about adding a new tool set to their web development arsenal.
This sort of training for developers that is going to be crucial to getting WebRTC used in the myriad possible applications that its creators might have imagined. It will enlarge the discussion around its use, bringing to bear the imagination of a massive new audience. This is where the new toolset that WebRTC presents will hopefully inspire innovation.