Audio Quality Matters
When mobile carriers started introducing HD voice capabilities to their networks – people were amazed by the quality of a 16KHz sampled audio stream. I remember the astonishment of consumers, having seen the HD logo on their phone for the first time. While HD voice became a norm in mobile network, traditional phone networks are still utilizing g7xx codecs – normally associated with a 8KHz sampled audio stream. Which means that regardless what you’ll do – the normal phone network simply doesn’t rack-up to the audio quality provided by mobile networks.
When it comes to VoIP, the number of available options is far greater – ranging from the traditional g7xx, through AMR codecs and other HD codecs (Opus, SILK, iLBC, ISAC). For sake of comparison, let us examine the following diagram:
Codecs are compared by their ability to provide a full band for audio sampling, without losing information – while at the same time, being able to compress the audio stream to a well-defined bit rate stream (yes, I know this is a very broad description – but I’m doing my best not to go too deep on the technicalities of these).
While codecs in the g7xx family are fairly static in the 64kbps bitrate, it is fairly clear that using these codecs in a challenged network environment – is sub-optimal. However, codecs that use a lower bit-rate, will normally require a higher CPU utilization – for higher compression levels.
So, if we look into the higher section – we can observe the MP3 codec (yes, we’re missing some other codecs in there), we can deduce that for music playback and streaming – MP3 is by far a superior choice. But when it comes to voice communications, it is imperative to ‘balance’ the quality requirement and the bitrate requirement. This is where audio codecs as Opus and its counterparts excel. You probably don’t know this, but Opus is more or less the de-facto standard for in-browser communications – so if you ever used Google Meet or such, audio in these are performed with Opus.
Compared to other codecs, Opus has a major advantage in mobile devices – the ability to control the complexity of the codec. The higher the complexity, the better compression you get, but, you pay in CPU requirements. Lower the complexity… you get the idea. In a mobile environment, being able to “adapt” the complexity in real-time is an advantage. A good mobile SDK and platform should be able to handle such a scenario.
Integration and Stability
Much can be said about integration and stability issues. Ranging from readable APIs through simple to use SDKs – the technical discussion can go on and on and on.
While the uphill of any application level integration is fairly well known, the integration between platforms is always a challenge. Also, if you ever tried integrating a mobile application SDK with your existing infrastructure – you probably already
know that in most cases – if your business is one of scale, you already know that connecting your mobile application customers to your business phones system is not feasible. So, the overall assumption is that integrating direct-to-consumer VoIP services is expensive and requires a significant technical infrastructure.
However, that is UNTRUE. Since the introduction of CPaaS services, it is becoming easier to expand your existing on-premise infrastructure – without investing a dime. Over the course of the past year, solutions such as BYOC (Bring Your Own Carrier) are making it easier for businesses to connect to CPaaS providers – without being tied to the CPaaS’s phone numbers of call services.
Stability – that’s a different question – what does make a solution stable? is it the stableness of the mobile SDK? maybe the quality of the call? or is it something else?
At Cloudonix we take stability as a black-box concept. It means that issues like network reconnection or traversal between IPv4 and IPv6 infrastructure should happen automatically. With IPv6 network springing up all over the world, the chances of an application needing to work on a dual network is rapidly becoming the norm.
A stable solution will not include a single part, but will provide an all encompassing (holistic) solution – starting with the mobile device, through the communications infrastructure all the way to your on-premise system. Able to mitigate issues – without the intervention of the application developer – or the remotely connected on-premise system.
Power and Network
In the early days of smartphones, power consumption was a major issue. Applications, specifically those that were constantly on, were notorious for causing havoc on your device. As technology evolved, developers got better as utilizing power – but also the devices got much bigger, with batteries that will not shame a small gaming console. However, VoIP applications, are still considered battery and network hungry – even today.
The truth is, depending on how your application is designed – battery and network consumption may still be an issue. Take applications as whatsapp or viber, if your examine you power and network consumption on these – you will see that they are among the highest consumers – even in idle mode. How can that be?
That can be attributed to the applications “availability and presence” abilities. Regardless of what we’ll do, these require network connectivity, which in turn requires power. But, does it really require that much power all the time?
When we started developing our mobile SDK – a customer had presented us with a challenge. Make our mobile SDK work with a car entertainment system that is based on Android. These systems are notoriously small. Single core machines that are slow, low on memory and will normally use a low-end CPU to boot.
The result was that we needed to re-think of how our SDK will work on these devices. So, by leveraging push-notifications and intelligent SDK service scheduling, we were able to create a version of the SDK that required a very small technical footprint. As a bonus, the same improvements enabled the SDK to be highly battery and network efficient – as there were no more ‘live connections’ kept active.
In-app communications is no longer a myth and the various FUD around it, is no longer valid. As we boldly progress to 2021, the incorporation of in-app communication services to mobile applications will grow. Be it social applications – or service applications – these will rapidly become more and more popular. Uber may have been the first ‘major player’ to go that route – but I’m confident we’re gonna see more as we progress into 2021. With solutions like Cloudonix (and others as well), in-app communications is attainable but other players, not as technical as Uber, but nonetheless – they will benefit from it.
Would you like to learn more?
We’re confident you have more questions – so this is the place to ask these. Simply fill the question form to the right and send it to us. One of our team members will return to you with an answer.