HD-Telephony: HIP or Hype?
Since the advent of the High Definition Television, The HD phenomena has spread far and wide in recent years making the “ordinary” “extraordinary” with the addition of a simple 2 letter prefix. The telecommunications industry is no exception with the strengthening concept of HD-Telephony. Is it all hype or is there an actual benefit to better sounding phone calls? How does this affect the hardware and software designed to keep us connected? As a software developer in this field, I hope to shed a little light on the topic and separate the facts from the misconceptions.
The term “High Definition” is traditionally applied to a technology when a new innovation allows a noticeable improvement in quality or detail from an existing version. The superior picture quality of an HD TV for example. The improvement in telephone audio quality that HD-Telephony offers is far less profound than that of HD-TV or HD-Radio but it’s an improvement nonetheless. The biggest issue with HD-Telephony is that the majority of phones and phone switches were designed with the mentality that every call they would encounter would be the same audio format and sampling rate. As VoIP grows in popularity we already face this issue with the various encoding formats used to reduce the size of the media stream. Encoded audio cannot be manipulated or analyzed and must first be decoded to alter the volume for instance. Then it must be re-encoded to the proper format when passing the call to the public telephone network. Variances in audio sample rates add another dimension to this problem because the decoded audio may then need to be re-sampled before being re-encoded or processed. If a high-definition audio signal is re-sampled to a lower rate at any point, all benefits of using that format are lost. Therefore, it is important to ensure that any calls using an HD-audio format only pass through devices that use the same sampling rate as the original call. So at this time, using a higher quality audio format for calls destined for the public phone network is pointless. On the other hand, there are many benefits to supporting HD-audio in your application or device with little or no cost to the bandwidth usage on your network as long as you pay attention to when and why you are using it.
I have done a great deal of work for the Asterisk open source PBX project. Asterisk supports voice-over-IP but it was really designed to support legacy telephone equipment such as analog telephones and digital circuits where higher quality audio is far from a reality and of little concern. That was among the many reasons I decided to start my own project called FreeSWITCH. Since I had the luxury of knowing about the importance of varying sample rates, I was able to design my application to not only translate audio between various encoding formats but also to mix and resample audio as well. I think this has paid off in the long run because I now see many opportunities to take advantage of HD-audio as newer phones are being developed.
One situation where higher quality audio shines is when you have several phones on the same network that support HD-audio. In this case it will be possible to experience a noticeable improvement in quality with every call. When calls are destined for the public telephone network or some other legacy device that will only support lower quality audio, the switch can negotiate the call with the calling phone at the lower quality in anticipation. This puts the burden of re-sampling on the phone and since the phone was designed to operate at either format anyway it has little impact on performance. Once you have the logic in place to determine when to use high definition audio most of the disadvantages begin to melt away. In FreeSWITCH, we can take full advantage of high-definition conferencing, audio playback and speech generation / recognition when applicable. In the case of conferencing we can even allow legacy devices to join a high definition conference by re-sampling the audio to the correct format. As long as the format is chosen wisely or corrected to match the format of the destination there are no drawbacks to the addition of HD-Telephony into an existing architecture.
Another concern many have with the idea of HD-Telephony is that it appears to be counter-intuitive with the goal of efficiency. There is a misconception that because the quality of the audio is higher, then the amount of bandwidth necessary to transport that audio must also increase by the same factor. To transmit uncompressed audio, it will indeed require twice bandwidth of an 8khz stream to send a 16khz media stream. However, once encoded, a 16khz audio stream can use the same or less bandwidth than a standard 8khz g711 stream. It may be true that some encoding formats designed for 8khz can greatly reduce the network bandwidth required to send a high volume of calls but again, in those cases, the telephony switch can request the most optimal encoding format from the phone or provide the encoding to the desired format by way of software or hardware encoding. The basic principle is that if the one phone calls another phone on the same network or when the exchange dialed is a known high definition resource, it chooses a high definition format and when the phone calls an exchange that will put the call over a highly encoded trunk using something like g729 it will negotiate g729 with the phone from the beginning to get the optimal results of that media path.
Many new SIP phones now support high quality audio using g722 as well as low bandwidth codecs such as g729. The open source speex codec supports wideband 16khz as well as ultra-wide-band 32khz. Many new wireless phones support both narrow and wideband audio formats making it possible to complete a HD-audio call from your mobile phone to a HD-ready conference or SIP phone without giving up any additional resources or functionality. There is simply another factor to consider when negotiating the call and just because it’s more difficult to deal with, we should not ignore this technology that has actually existed for a long time. It may not offer many benefits to Ma Bell but HD-Telephony is emerging in the marketplace and when used properly, has the potential to raise our standards to the next level.
Thanks a lot for this article.
-----------
sohbet
Very interesting project.
As a VoIP enthousiast and audio specialist, i'd like to give my opinion :
1) HD is very interesting, but should give a sound better than G711. according to my tests, G722 is not a good codec. We can hear a non natural sound, not as bad as the high compression G729 codec, but we can easily hear the compression even if the bandwith is larger. The quality/compression ratio is not good at all.
I would not propose such an approximative quality to my clients, because they are used to the perfect quality of G711, giving a very natural sound since more than 30 years.
G711/16 is giving the same very natural sound as G711/8. G711/16 is supported on Aastra phones. Aastra phones are the best ones for opensource telephony because of their compatibility with the asterisk world, efficient tftp autoconfiguration, and free XML advanced features, specially in the latest 2.2.1 firmware with free XML 2.0 scripts.
Speex codecs have a very high conversion time (the worst of all codecs ; at least inside asterisk) and are not heavily supported. This is a problem for profesional telephony. Hardware implementation i've seen have compatibility and bugs problems.
G722.1 or G722.2 is a better alternative but is not free. I've made some tests with G722.1 (the provider "France Telecom" is using it in France), and does not sound as natural as G711 neither.
As the global bandwith available for IP networks raise each day, and because FTTH will be a reality in the near futur (or is for some country), it would be a good choice to not compress audio data at all to get the best quality for HD telephony. In this regard, G711/16 seems the best choice for a new telephony standard, without any licence problem, giving a perfect sound, and really easy to downsample and convert to 8 KHz and other codecs. For country where high bandwith is not available, then G711/8 will stay the best choice for compatibility.
G711/16 is very fast very simple and give the best audio quality. Globally it is the less processor hungry solution.
I would highly prefer a very good standard codec G711/16 easy to deploy and implement on every phones, than a heavy and industry unsupported Speex/16 /32.
Last, please let me give my opinion about the futur of the opensource world for telephony systems :
According to the actual state and evolution of Asterisk, i do not think that this project has a big future, except perhaps for hobby. Asterisk is like a full time beta software. It does not have enough reliability, enough power (scalabilty and call processing power), and enough serious in its developpement.
In a few years we will say : did you remember when we were fighting with Asterisk ? It was a funny thing isn't it ?
Asterisk is good, for running Digium cards. Not really more. This market will slow down as soon as the telephony network will become mostly full IP.
We can do really better and Freeswitch is a good sample of that.
The futur of telephony is not the TDM / SS7 world. It is the full IP (and IPv6) world.
Asterisk is not IPv6 compliant. It is quite funny to see this today. ( i know, there is an IPv6 fork).
In this regard, projects like freeswitch are interesting because they do support a really higher call processing power.
I will end giving 2 important warnings :
1) The telephone software world is not like the data software world.
Telephone experts cannot deal with a moving target like Asterisk is.
A company keep his telephony system often during 10, 15 or even 20 years and needs to have a clear migration path during this period.
The opensource project of the futur of telephony will need to take this into consideration, or it will fail.
For example, API changes will need to be carefully studied, so that all the precedent developpements keep working on new versions. Like it is the case for the X86 instruction set in the computer world.
Dialplan changes should be even more conservative. Keeping an absolute compatibility with precedent versions is mandatory.
If no opensource telephony switch software take this into consideration, then the furtur of the IP world telephony software will be a commercial software, certainly based on all the good work made by the opensource telephony community. This is not tolerable for all the community developpers who have spent time on the initial projects. In this regard, i hope that projects like Freeswith or new Asterisk forks will rise to a higher grade, to really become a professionaly usable alternative.
Telephony world is a slow and serious world...
Last the diaplan need to be simple to understand and program. the xml structure is perhaps good for a data software programmer, but for a telephonist, it is quite cumbersome.
The Asterisk diaplan is simple to learn and program. That's a good point.
2) In the telephony world, things need to be perfectly reliable. Audio quality need to be perfect. No alternatives. World scaling and standards needs to be fully respected.
Because the futur of telephony is the IP world a special care must be taken with buffering, intelligent codec negociation, bandwith reservation and multiple trunk registrations for redundancy (a true redundancy, not only outbound calls).
Asterisk almost completely fail here, forgetting to take into account those problems, at least for the lastest three points.
I've not seen any other projects taking into account the latest 2 points, bandwith control - reservation and redundancy problems.
Those problems are well managed in the traditional SS7 telephony world. This should be the same in the IP world.
I think that a telephony switch engine should be able to decide himself if a call (inbound or outbound) can be accepted according to the available WAN bandwith and requested codec. Eventually it should be able to choose a highly compressed codec if the bandwith become too restricted and the call cannot be rejected for urgency reasons. It should even be able to drop an active call to allow for an urgeny call to go through the trunk.
Last, for the success of full IP telephony, a big effort need to be done by VoIP providers and IP links providers. The best example is certainly the need for a consistent ANI and CID through providers. This is not the case today. When CID are correctly transmistted, very often the CID name disappear, and most often the ANI is not taken into consideration. This is a big problem for urgency services.
All this is not serious. VoIP is like traditional telephony less basic functions and quality everyone needs every day.
Please mister providers and programmers, bought a few books about SS7 telephony and learn traditionnal telephony. Then do the same thing with VoIP.
Because of this full IP telephony is today something like a Formule 1 competition engine inside a consumer grade vehicule.
ENUM needs to be fully deployed as well, to simplify full IP telephony, and remove all the bad things that happens when calls go through VoIP providers.
I wrote a document in french concerning the problems we have today with VoIP providers and IP links providers, and what to test to choice them.
If someone would be interesting to translate it in english, please let me know.
Great Post and one I believe would add needed value to VoIP. I am however biased being an audiophile. Sound Quality is of importance to me... It does look however that people are quite interested in higher sound quality in telephony...
Also Congrats for your well-thought software. I hope it attracts a great following and that you find financial success with it...
Lesly
Great post. Thanks for information..
---------------
betsson | bodrum property | e-Okul
Being new to telephony, this article helped in understanding quite a bit of Intrinsic details of the technology. I love freeswitch and will be a freeswitch user forever. Hoping to see freeswitch grow into the no 1 application for telephony.