Dectdroid

Android has become something in the telephone history that you cannot ignore. So it seems logical to build a DECT phone based on Android—snom Dectdroid? Does it?

The idea goes like this: Take a standard Android phone, forget about the GSM interface and replace it with a DECT interface. Hopefully this will be done using CatIQ, so that the handset can access the internet over the DECT air interface. Then you can run all kinds of apps on the Dectdroid, and this would be your corporate phone for walking around in the office. Applications could be like this:

·         Hospitals have a lot of semi-mobile staff that walks around in the building all the time. They can use the handset for talking, but it would also be very easy to add apps that deal with the routine in the hospital. Thanks to a large developer community, finding someone to write some hospital specific stuff should be easy.

·         Same story for hotels. Really pretty much the same, of course with different applications. For example, the maid application who can just click on “cleaned up the room” when she is done with a room.

·         Regular offices would also like it, because you can give every employee and Dectdroid instead of another handset and a small app could help transferring calls, picking up calls and so on.

·         DECT has advantages compared to WLAN and Bluetooth which are important in the voice business: You can have a lot more handsets in the room than with Bluetooth and because the DECT frequency is reserved only for DECT devices, there are much less problems with interference with other devices. Also, DECT is low power. As we all know.

While that all sounds nice, there are a couple of problems here:

·         Price. You would suddenly increase the cost for the device by magnitudes. Remember that Android devices are usually made in the millions, and DECT handsets in this category will probably be far away from that. This does result in a different price tag. I would guess MSRP in the area of 400 USD.

·         Battery lifetime. As soon as you have DRAM, the battery time will go down. The problem is solved with the smart phone handset; however keep in mind that those devices have a powerful battery, which is expensive and heavy.

·         The patent situation is also very unsatisfactory from a manufacturer’s point of view. Imagine we make this beautiful Dectdroid, and then get a letter from on the big players asking us to stop immediately or pay huge amount of cash for the patent infringements. If you are one of the big ones, the legal department will probably almost be happy they got so much work to do and so much attention. However small fish like snom cannot afford a team with ten people checking the patent situation about Android.

All in all, it is probably easier to just add a USB device or something similar to an existing Android device and use this as the device for talking over DECT. Looking at some recent Android phones in the hundred dollar range, this is probably even cheaper.

So for me the bottom line is, at first glance it sound like a good idea. But the volume will be too low to justify the effort and most customers can also live with the single-chip DECT handsets that are available today.

The German virus and the snom m9

In Germany there was recently a major scandal about the “Bundestrojaner”. This was a Trojan horse programmed by a consultant company to infect PC of gangsters. Fortunately or unfortunately the CCC (Chaos Computer Club) found the thing and dissembled it—showing shockingly simple APIs to control it and they even published the encryption key for the encryption of the data. It was a major uproar and even the parliament had to deal with the question how this all could happen. Everyone was quick to mention that everything was within the scope of the law and order and that everything was under control.

However, this leaves a lot of questions open. In short, every program that you install knowingly or not knowingly is a leap of faith. Let’s go quickly through my checklist for Trojan horses:

·         It has access to the file system and/or to other interesting resources like the microphone or camera. This is what the guys are after.

·         It has access to the network and opens the firewall and it keeps that connection open for a long time. This makes it easier to receive commands, for example instant messages with text content that is being displayed on the screen or remote commands to read the file system and send them back as instant message.

·         It may use an encrypted protocol to send the data, so no one can figure out what exactly is being sent. Ideally uses an encryption protocol that is not publically known.

·         It registers the user in a public location, so that someone who wants to get access to it does not have to search where the laptop is right now.

·         It has this irresistible reason to use it, for example “I can make free phone calls with all my friends now”.

This frankly reads like the feature list of any soft phone. If you install that free softphone from Kudingingrad and ever wondered how these guys make money: well the answer is the might make money with your data. For example, give that banker in Wall Street a free softphone (greedy as these guys are, probably he can’t resist the “for free” temptation) and start speculating in the stock market with the extra information you get directly from the source. From time to time, you can even set the price!

So let’s say snom is an evil company and wants to get all your data, using the snom m9. The problem starts with the first point on the checklist. How can the phone get access to any useful data? That’s a challenge; maybe it is able to get access to the LDAP directory and upload that to that spy server. It could turn on the microphone and send all the data to that evil server in the former headquarters of the Stasi in East Berlin. However user might complain that the battery standby time really does go down significantly after the last upgrade… Because there is no video, seeing what is going on in the room is also not an option. The m9 is really a bad platform for stealing information. Sorry, evil snom.

The bottom line is that anything running on your computer or tablet or smart phone or whatever is a leap of faith. If you want to play safe with networking stuff just buy some gear that has no access, just like the snom m9 or the other snom desktop phones…

nsa.gov--we got the cheapest routes!

Dear National Security Agency, this post is not against you and has probably nothing to do with what you are doing in the real life. Anyway, this story is so good that it could be true, and I want to share it. Feel free to replace NSA with the service provider or government agency of your choice and the country of your choice!

I was always wondering how you can get access to phone calls for the purpose of recording them and hopefully finding some interesting content. It seems there is an easy way: become an Internet Telephone Service Provider (ITSP)! All you have to do is bid for the destinations that you are interested in. For example, you want to record all phone calls that go to Afghanistan? Well, just start bidding for the traffic based on the destination patterns. Or you want to record all phone calls to a specific number? Just bid for that number, I think the prefix can be longer than just a few digits so why not the whole number? Everything is pretty much automated these days, for example check out the Voice Peering Fabric (VPF) which handles tremendous amounts of traffic. It would be interesting how quickly they can change the routes, maybe if you know someone is about to place a call, quickly bid for the route and bingo! That would save a lot of money for the unwanted traffic and the work to work through all the recordings. Also, what you get as the new service provider, is also the phone number people are calling from, also making it easier to find out if the call is interesting or not.

Maybe guys like the VPF should also support bidding for source-based numbers, so that you can filter for only the traffic from the people that you are interested in. This might sound like a bold request, and it would be really difficult to explain that with anything else than the interest of recording.

The other way to do that is to run a PBX in the country of your choice and oopsss, you picked a trivial password. I am sure sooner or later the "friendly VoIP scanner" will find you, and give you lots of traffic for the country. Then also the recording part will be trivial. Okay, in this case you would make no money, but at least it is only national traffic that you have to terminate. Usually this is cheaper that international traffic, especially in some countries of specific interest these days.

So what does this have to do with the snom m9? Not much. The m9 does support the usual encryption mechanisms like SRTP and TLS; but what is it good for when your service provider just translates everything into plain unencrypted traffic and sends it to a service provider that you cannot control at all? Even ZRTP is usually not the solution. Most service providers will terminate the ZRTP at a kind of session border controller (which you have to trust and you will do that), and then it will go South from there.

G.726, transcoding and smart codecs

DECT uses the G.726 codec to transmit the voice over the air, no matter what codec was negotiated on the SIP side. Ops that is not 100 % correct, in the new DECT standard (CatIQ), the air interface also supports other codecs like G.711 or G.722; but let’s forget about this for now and until CatIQ handsets are widely available.

G.726 is one of those good-old ITU codecs. It is in the same area like G.711, G.729, G.721 and also G.722 with constant bitrate, no matter if you are talking or not or if you are playing music on hold. It probably comes from the time when telephone calls were running on slots with fixed bitrates (TDM), and having a bit rate of 32 Kbit/s allowed to have actually two phone calls in one 64 Kbit/s second slot (that’s really 64000 bit/s, not 64 * 1024 as we would assume in the computer age). Anyway, for the air interface it makes a lot of sense to pick a fixed rate codec as well, because—guess what—DECT is also using TDM slots for the voice and transmitting bits over the air cost a lot of energy and spectrum, so limiting it somehow makes a lot of sense.

We can be happy that they chose 32 Kbit/s and not less. In GSM, they usually use only 13.2 Kbit/s where the voice quality really suffers. Even if you use a great microphone, compressing voice to that level will have to throw a lot of information away, so that cell phones using the GSM standard have little potential for good audio quality. Anyway, in DECT they decided to use another codec, and that codec was G.726. It compresses the voice not too much, and it is actually difficult to tell the difference to G.711, the codec that is still mostly used in digital voice. The G.726 is pretty friendly to the CPU, and it causes only very little delay with the encoding and decoding. The other reason to go for G.726 is that it is not as heavily patented as for example G.729. IMHO a great choice that many service providers should seriously consider!

There is one more reason why providers should consider G.726: Transcoding. If you are calling from a DECT device, you want to avoid that the voice has to be transcoded from G.726 into linear and then into G.711 or something else. This is because every transcoding step reduces the quality of the signal. Even if you are transcoding from a “bad” codec to a “good” codec, you are loosing information, and it will sound worse. Something like the 1 x 1 of the information science: You can only loose information, not add something.

Well, that might not be true forever, even in the codec world. Maybe one day we will have a codec that knows the speakers voice so well, that it can figure out what is being said and synthesize the missing spectrum. It would also be useful for filling up gaps when packets get lost—assuming the codec really knows what is being said. We have to be careful here: Maybe one day you are talking to the bank with the super codec, the bank guy asks you if you really want to purchase one million snom shares, you say “no” but right at that moment there is a lot of packet loss, and the smart codec kicks in and synthesizes a perfect “yes” and the deal is done. That’s where I prefer a dumb codec like G.726.

Languages in the web interface

Today, if you want to sell products, you have to support multiple languages. Even if you are in a country that has clearly a primary language, there are so many people from other countries that a support for additional languages does not hurt. The way it is done in the handset is different from the way it is done in the base; today’s topic is about the base.

If you want to change the language on the base, you first have to log in. The first time you login, you will get US-English content; hopefully your language skills are good enough to navigate to the page where you can change the language. Then after this, you have to log out and log in again. Then you should see your favorite language. The language settings is global, so if you have other folks that want to log in, you will have to agree on a common language.

On the base, practically all texts are used in the web interface. The m9 has a built-in web server and due to the space limitations, it cannot be a full-blown PHP or ASP server. However, the m9 web server does come with some smart functions, including language items. When the m9 web server has to produce a page, it looks for special tags in the file and replaces them with dynamically created content. The syntax is pretty simple: it just references a number; that’s because all items are just indexed by a number. Other products like the snom ONE are using texts, but we figured that for a small embedded product like the m9, number will have to do.

The syntax of a language file is also pretty simple. There is no XML, just plain line-based items terminated with a CR/LF. Each line contains a number in the beginning, followed by the translation text. Comment lines start with a pound symbol, and there is one more special line, which tells the web server which language this is. Upon boot up, the web server just reads the whole file, and then when it has to generate language content, it just puts it into the HTML text. Everything is UTF-8 encoded, so we would even be able to support Japanese, Chinese, Koran, Urdu, you name it. Not sure if Hebrew and Arabic are problems, as they are writing from the right to the left. For those guys who read the blog entry how to log into the base via telnet, you can find those files in the html directory with the name lang_xx.txt, where xx is the language.

If one of you finds out that a translation could be improved, please drop us a note and we can easily change it for the next release. We actually thought about having a “feedback button” where the end users can propose other translations; but at the end of the day this does not only occupy valuable development time, it also does occupy more code in the base so we forgot about it for now and let’s do it the good old fashioned way: email to support.

Busy Lamp Fields

Many DECT phones are using in small companies, where the users still are in love with their good old analog phone systems. One of the features that users love so much is the busy lamp field and the shared line appearance. Would it make sense to have such a feature on a business DECT phone as well?

The idea goes like this: Why don’t we add a few (e.g. four) buttons below the display and use a LED behind them to show the status of other extensions? Then the software can subscribe to the button information, and when the PBX has an update, the DECT base would operate them. When used as shared line buttons, these buttons could be used for seizing an outbound line, placing a call, parking or holding a call and then when blinking picking it up on another handset. It all works nicely on the snom desktop phones (when using snom ONE), so it would make sense to have it also on the handset.

Well, there are a few obstacles. First of all, adding buttons means changing the plastic; changing the hardware. This is something that you don’t want to do, if you don’t have to.

Then there are problems on the DECT side. The way DECT works is that the handset sits there and waits for broadcast messages every few seconds. Then the handset could setup a connection to the base and fetch the message from the base (DECT still pretty much comes from the TDM world, so there is no big difference between a phone call and a data connection). When the LED are changing frequently, that would mean a lot of connections; and each of them takes power. The other little problem is that most DECT stacks have problems with more than one connection at a time, which would be another obstacle when you are in a phone call to update the LED. And especially if you want to support a large range of DECT handsets, you might end up in a lot of connections, making it difficult to have some space left for the voice!

So the bottom line is: Everything is possible, but some things are just easier than others. As for the BLF idea, this belongs to the ideas which are more difficult. There is a reason why there is no DECT device in the market with this.