DECT repeater

In the last blog, I wrote something about how far the DECT signals typically go. There are two scenarios, where the base station cannot cover the area. The first one is in large buildings, for example hospitals or hotels where you need to install several base stations to cover it all, and potentially also a DECT handover if you don’t want to loose the call when walking down the stairs from one floor to another. The second scenario is where you need a “booster” that juts extends the reach of the signal, and in that case you would use a DECT repeater.

As the name suggests, what the repeater does is to repeat the signal. This is not “boosting” the signal, because the signal strength of the repeater is similar to the strength of the base station. It just repeats the signal, so that the traffic that occurs in one timeslot will be copied into another timeslot, so that the base can talk through the repeater to the handset. For example, if you have a long hallway, this is a simple and elegant solution to provide good signal strength everywhere. The repeater works from the handset point of view like a handover solution, because when the handset goes from one end of the hallway to the other, it will eventually perform a handover somewhere in the middle.

You can also add multiple repeaters to a base station. However, there are limits. First of all, because the number of timeslots is limited and they overlap to a certain extent, your timeslots will be eventually full and that’s it. The other problem is that once you have too many repeaters, you are increase the total jitter in the system, possibly to the degree that the whole system becomes instable and then calls drop like flies when you use that bug killer spray. I don’t know what exactly the limits are, but I would be conservative with the number of repeaters that you can safely add to the system. If you need 16 repeaters to cover your area, you probably need another solution and also you probably need more than the 4 concurrent calls that you can have with the m9.

The other problem is encryption. Because many vendors have come up with their own encryption protocols, you cannot connect any repeater to any base station. You have to either turn encryption off or you have to use a pair of base and repeater that use the same encryption protocol. For the snom m9, we have added a special version that deals with the problem (this will be called “snom m9r”, as the name suggest this has something to do with the repeater).

The ultimate goal is to have a system where you can handover from one base to another, without the need of repeaters. Right now, such systems are available; but with a hefty price tag. In many cases one or two properly set-up repeaters can solve the problem as well and the whole solution is cheaper and easier to install.

How far can you go?

Being able to walk in the office and talk is a great thing! But how far can you go? Because DECT is relatively new in the USA there are many misunderstandings in this area. Marketing always loves to print hard numbers in the datasheet. But it dep0ends a lot on where you put the devices and what material is in the middle. Generally speaking, metal and concrete are a problem. If there is just the air between the base and the handset, you can go pretty far (maybe even 300 yards), but this is just the most optimistic case. Even one yard might be a challenge if you have a 13 inch metal from the Bismarck world war II battle ship armor plating between the base and the handset. So I did a couple of field trials. Here is my report.

In our office, if I put the base station in the middle, I can pretty much go anywhere, even outside where the restrooms are (if I have to; but watch out when flushing the toilet, people might notice). Of course we have a lot of electronic gear in our office, and I am sure our neighbors upstairs and downstairs too. But that does not seem to be a problem as DECT uses a different frequency as WLAN. As soon as I go into the elevator, the game is over. The metal of the elevator seems to keep the signals out and the conversation ends. I guess we all know this problem from the cell phone world. Surprisingly, when leaving the building I am picking up a signal again, and I can even go to the mall, which is like 100 yards away, and even after going inside I still have a signal (though the voice starts to break up). Walking a few more yards, that’s it and the connection is lost. So for the office the bottom line is: as long as I stay in the office everything is good; it ends at the elevator. Maybe in summer I could also sit outside and get a few phone calls done. I would say our office is 50 yards long and has up to seven drywalls between the base and the handset.

At home, things are easier. Thanks to the US building style (wood and drywall) we have perfect reception everywhere in the house, even in the basement. I can even hang out in the neighbor’s garden and have a beer while still connected to the base at home. No problem there.

If you are living in an apartment, things might get more difficult. Usually there is a lot of concrete and steel in high rise buildings; at least for the floors. For the floor that’s a feature because your neighbors will not be able to register with your base (see my blog about the PIN code). Unless you have the luxury that your apartment covers several apartments there is no problem. Usually inside the apartment there is not too much concrete being used, so there is also no problem. Actually I believe the designers of DECT had the case in mind that a whole high-rise apartment building is using DECT in every apartment and they still want to be able to provide service to all of them. A too strong signal would be counterproductive.

I had a case with a house that had concrete floors and where the DECT base was in the basement. The signal was very weak in the first floor already, and the second floor was completely dark. Anyway, WLAN did not make it even to the first floor. Putting the base in the first floor solved the problem.

Cookies are not (only) for eating

HTTP provides a mechanism for authentication that ask the browser either to send the username and the password more or less in clear text to the server (Basic authentication) or in a hash (Digest authentication). Believe it or not, but Digest authentication was and is a problem for some browsers, so practically only Basic authentication can be used in all environments. Common denominators tend to be small. Plus it is difficult to ask the browser to forget the username and password that has been entered after a certain time; it will be pretty much there as long as the browser is running.

Because of this, web servers started to use another technology, called “cookies”. There you can control how long a session will be valid and you can also control the layout that the user will see when logging in. This is today pretty much standard. And so we thought this is how you should log into the m9.

The m9 keeps all information related to a login session in a special object inside the built-in web server; not only the login credentials, but also session variables. For example, the identity that the user has chosen is stored in this session variable. Another one is the duration, after which the session will expire.

The snom m9 stores the cookies temporarily. Many users are concerned with permanent cookies (including me), and browsers today make a big distinction between permanent and temporary cookies. So there should be no problem. If you use the HTTPS transport layer, then the cookies will be exchanged between the browser and the snom m9 in an encrypted fashion, so that outside parties will not be able to see them in clear text. Because the web server does not care where the request comes from, it would be possible, if you know the session cookie, to resume the session from another computer; in other words, you could skip the login part and start editing user data just like that or use the powerful debugging possibilities as admin to do other bad things.

There was recently a report that it would be possible to steal the cookies (BEAST). This attach assumes that someone is able to execute JavaScript in the web page for the m9. I am not the biggest security expert, but I think that would assume that the attacker must be able to modify the files on the m9 file system; which would be pointless because once someone can do that, this guy can also read the configuration in clear text which would be a shortcut to all secrets on the system and he can skip tricky TLS problems.

Injecting JavaScript is admittedly a big problem with many web sites, for example when you receive a call from “<script type="text/javascript">document.write('<b>Hello World</b>');</script>” (that would be the display name in the SIP URI) and that is being shown in the call history of the web page. However, there are few places where such content is being printed out on the web page, and we made sure that such text is properly encoded in HTML, so that the browser does not misunderstand this as HTML that should be executed. Because the m9 does not have too many web pages, it is relatively easy to do that compared to huge web sites (e.g. for bank), where such a check will be a lot more work!

The problem with QoS?

I remember a couple of years I had an angry customer trying to tell me that everything is okay with his internet connection. He could send and receive emails, and also he could access web sites without major problems. It was just the voice that just did not work properly! I was trying to explain to him that there is a difference between communication that may take a few seconds and communication that should happen within a few milliseconds. He wasn’t very technical and I think I must have lost him with the word milliseconds.

Anyway, today we are not really further with the QoS topic. Bandwidth might be higher, but the fundamental problem is still there. An endpoint like the PBX just cannot enforce it. If someone starts downloading MP3 files or videos and your home network does not have the luxury of a fiber connection, you will probably still face the same problems today. There has been a lot of work in this area, trying to come up with traffic shapers, VPN tunnels and so on. At the end of the day you can say: if you don’t control the router on the other end (provider), you can only increase the probability of QoS, but there is still no guarantee.

So you can’t enforce it, but at least you can measure and log it. That’s the point where RTCP comes into play. This protocol sits next to RTP and provides some additional information about what’s going on with the media. There is even a standard called RTCP-XR, which sends additional information (extended reports). The m9 supports that, and if the other side is able to read it, it can generate nice reports out of it. For example, the snom ONE PBX generates a report for each extension and for each trunk (well, if the other side supports it) that shows you how the quality “mean opinion score” was over the last 24 hours. I attach a picture of a real busy day (okay, it came from a stress test).

What you can see there is that most of the calls were in the 4.1 area, which is usually a good G.711 call (because it is narrow band, G.711 does not make it higher). Some calls obviously had some quality problems, probably some packets dropped or the delay got too long. Some calls even have a score of just 1, which is pretty bad (but at least you could hear something, must be close to smoke signs).

In order to push everyone a little bit, the m9 sends the necessary information in the SDP for all calls and for all PBX types, at least those where we know it does not screw anything else up. This is a kind of “advertisement” for RTCP-XR. I hope that some folks see it in the logs and put it on the to-do list for their PBX!

Take the m9 home?

When you look at the market for DECT devices, actually most of them are sold into residential, especially in Europe but also in the United States DECT has become classic at home. However, practically all devise are using good-old POTS for the connection or ISDN if you are in Germany. Would it make sense to give home users an upgrade to use VoIP-based DECT at home?

The biggest problem of course is price. At Wal-Mart, they are selling DECT phones for 15 USD, and if you would put a 99 USD dollar VoIP-based phone next to it, people would ask themselves what’s the point? DECT handsets are pretty much talking endpoints, and that’s what you already get from POTS. Also, prices for POTS have fallen so much, that there is little point saving a few bucks for calls.

Of course, at home we are using m9 handsets and my wife does accept it. But the biggest point is that she has a lot of international calls, and because they are still expensive if you use telephone companies, that’s the point for us to use it at home. For regular national calls, we still have the 15 USD device with the POTS line that we got included in the internet package.

The other thing that we are doing is using the handset as PBX extension in the company. That’s another thing you can’t do when using POTS. DECT is great because I can walk around in the house and even outside without having to worry about loosing the connection. If I have to, I can easily transfer a call and there is no need to fork the call to the cell phone.

Competing on price will be impossible. I believe the biggest point is that I have a mobile PBX extension at home; then next to that my wife can talk for hours to people outside of the country; and seen from this perspective the m9 makes sense at home. I don’t think it makes sense to sell the m9 through Wal-Mart, for example. But I do believe it makes sense to point out to customers that they have the option and it does make their life easier when they work from home from time to time.

Does ZRTP solve the key exchange problem?

In my previous blog I talked about SRTP and the problem to negotiate the SRTP secrets. If TLS can be used and this actually makes sure that the keys are negotiated between the endpoints, life is easy. However in many cases that is not possible and another solution is desirable. ZRTP tries to solve that problem and we put it into the m9, at least in a special build.

ZRTP stands for Zimmermann RTP. Phil Zimmermann is the guy who invented it. He is a kind of celebrity in the crypto scene, because he is the one who wrote PGP (pretty good privacy). ZRTP tries to solve the problem that there is in many cases no trusted entity available, e.g. a trusted root certificate authority like in the case of TLS and the use of certificates. If such a Root CA is available, then there are other options like DTLS, which runs TLS over the media UDP transport layer.

The general idea, in my own short words, is to store the cryptographic secret from the last conversation with someone and use it for the next conversation. Because most of the phone calls today are done by dialing the address book and you don’t trust a first-time caller anyway, this is a way to establish a trust relationship with the communication peer. On the m9, there is a directory called “zrtp” that stores the information, so that also after a reboot cycle this information is still available.

In the special case that you are talking to the PBX, the question is if you are talking to the PBX itself or the remote party. That’s where things get a little tricky. ZRTP needs the information in the SIP headers to figure out where you are talking to, so in theory you would have to have a different key for every remote party. That can be done relatively easy in the case of talking to extensions; but in the case of talking to someone on PSTN (over the PSTN gateway) this is not very practical. So in these cases there is either no ZRTP (which makes sense because the remote party on PSTN does not receive an encrypted audio stream) or the PBX or PSTN gateway has to encrypt the traffic in a B2BUA way, and also keep the keys for each remote party ID. Practically speaking, I would say, as long as there is RTP in the game, ZRTP makes sense; otherwise it is just a feel-good pill with no substance behind it. But at least for internal calls, ZRTP is an improvement; if the service provider lets the ZRTP packets pass through to the other side, it is also a very important improvement against the situation where you don’t encrypt at all. For example in the case of the “nsa.com—we got the cheapest routes to Afghanistan”, if they would pass the ZRTP packets back and forth between wherever you are and Afghanistan, then they would have a hard time to listen to your phone calls.

On the snom m9, the only thing about ZRTP you will notice is that there is a log level for ZRTP messages. If you want to play around, you will be able to see the ZRTP negotiation process. We don’t do things like playing out crypto messages at the beginning of the conversation, but AFAIK we do display the lock on the display of the handset once the call is secure.

So what’s the roadmap for ZRTP? It is for sure right now a chicken egg problem. If there are no ZRTP devices, there is nothing to test against. With the support for ZRTP in the m9 we wanted to help to increase the number of available devices, and even if the display is not perfect yet, it does help to increase the ratio of available devices. As always, feedback from customers is appreciated.

What's the story about SRTP?

I am still surprised how little VoIP traffic is encrypted in the year 2011. While it has become quite normal to use HTTPS to protect, most of the phone calls run encrypted over the WAN or the LAN. While in the old times, the national intelligence organizations has to work hard to get access to a specific phone line, today they just have to bid as a 2^nd tier service provider for the cheapest route to a specific destination. They could even advertise it like “NSA—we have the cheapest routes to Afghanistan”.

SRTP makes sure that someone who sees the RTP traffic just gets some pretty random noise that does not allow any decoding of what is actually said on the phone. What a wire tapper will see is from where and to where the traffic flows, and it is also possible to see the RTP headers, including the sequence numbers. Someone who can actually modify the SRTP packet can also drop packets; however when changing the payload or even one of the headers, the checksum will not match any more and then the decoder will drop the packet.

SRTP uses AES as the encryption algorithm. Usually people use AES-128 which gives you a superb security. The way it works is that the AES algorithm essentially calculates a pseudo-random number based on the input from the RTP packet, essentially the sequence number and some “salt”. It is extremely difficult to calculate the input from the output. 64 bits already represent 18446744073709551616 possibilities, and 128 bits are 18446744073709551616 times 18446744073709551616 possibilities. You do need to do a lot of number crunching to get the right input if you should know the output.

Some people are confused how just 128 bits can be so secure, especially because today usually 2048 or 4096 bits are used in private and public RSA keys. The point here is that the 2048 bits must be a multiple of two prime numbers, so that not every bit combination in the 2048 is possible and there are a lot of algorithms in the game to calculate the two prime numbers. At the end of the day, RSA is used to negotiate the input for the SRTP algorithm for each call: While in RSA there are public and private keys being used, SRTP uses keys that both parties know. And the SRTP key changes from phone call to phone call, and the RSA keys remain the same for a potentially long time, so some extra security is welcome here.

One stupid thing with SRTP is that the receiver has to guess what the “rollover counter” looks like. The problem is that the sequence number is only 16 bits, and after 65536 packets you start over again. This happens after 22 minutes latest for a packet length of 20 ms. So one good test is to put the call on hold for 23 minutes, and then resume the call. If the other side has problems, this is probably because of the rollover counter. The m9 has some special logic built in to guess where the rollover counter is when you resume the call after such a long time. Actually there is also another SRTP called SSRTP which solves that problem, but unfortunately it is not backward compatible with SRTP. The snom m9 also supports the SSRTP, but as far as I know only Microsoft OCS/Lync use it.

The other common problem was that some implementations don’t check the SRTP checksum (MAC). For example, some old firmware versions of the snom phones happily played everything back that looked like SRTP, and when there was something going wrong with the key negotiation or holding the call for too long, it would play thundering loud static noise (which is what you “hear” if you are tapping the wire). The m9 did the proper MAC checking from day one, so the thundering loud static noise should be no problem.

As for encrypting traffic over the service providers there are a couple of problems. Most service providers use some kind of session border controller that will translate the SRTP stream into regular RTP stream. Especially the checksum will not make it through the session border controller, ending up in pretty much the thundering loud noise that I talked about above. The biggest problem though is to negotiate the SRTP keys with the end partner, because TLS might transport the keys to the session border controller, but this one will remove it and the other party will not receive it. Apart from that, the SBC will also be able to read the keys, so that at least the carrier can record the call. Standards like ZRTP try to solve the problem by negotiating the keys through special RTP packets, but again the problem is that the SBC might intercept that.

Anyway, when SRTP is being used and everything works okay, you should see a lock symbol on the snom m9 handset display. At least in the LAN or when connected to the corporate PBX that should be relatively easy and you can at least be sure that the internal calls remain private.

The encryption from the base station to the handset is another story.

Microsoft Lync and DECT

When you purchase a PBX system from one of the “traditional” vendors, there is practically always a cordless option available. However, when rolling out Microsoft OCS or Lync, this is an area when things get a little tricky. I already discussed the technological options in the area of cordless communications in one of the previous posts, and DECT is something that would fit in nicely into the Microsoft world, especially in Europe where DECT is a mainstream technology for quite some time.

In the past few years, snom did get the expertise on how to talk to Lync and it seems logical, that the m9 platform should also connect with Lync. To make it short, there is something on the m9 available; however this is in a “beta” stage without proper and systematic testing available yet and also some features missing. In contrast to the desktop phones, on the m9 there is no special build necessary; you just need to set the m9 up properly and then you can try the Lync functionality out if you like.

Right now, there are essentially two things that should be working. This is once making and receiving phone calls (honestly, I am not even sure if the transfer would work properly). The other thing is that when you are on the snom m9 handset, you would see that in the presence state. http://forum.snom.com/index.php?showtopic=5182 and http://wiki.snom.com/Snom_m9/Documentation/Online_Manual#Microsoft.C2.AE_Office_Communication_Server_2007_R2_Integration have some more details what needs to be done to get this working.

There are a few things still missing. First of all, the plug and play experience is not really there yet; you still have to set everything up through the web interface. IMHO that is something important, because manual setup cost time/money and that’s where Joe Doe screws things up. Lync offers a nice way to use PIN codes to get the registration job done (no passwords necessary it seems), it would be very handy to have that working. Even software update for the handset would be a possibility, once you can install a CAP on Lync that has the right firmware. Other essentials are calling 911 (Lync has its own way to get this job done) or accessing the address book the Lync style. Also, the question is if we can integrate some basic instant messaging features on the handset.

So for those who want to get some cordless experience in the Lync world, right now you have to either take what’s there or you have to wait until there is a fully integrated, tested and approved version available. The latter might take a few months; until then we are happy if you give us feedback on how it works and we can see if there is anything that needs to be fixed and that can be fixed.

The picture caller-ID

I call it “poor man’s video telephony”, and it is essentially sending someone’s picture along with the caller-ID. I personally believe it is superior to video telephone, because you can control when the picture has been taken, make sure you have shaved properly in the morning, or have proper makeup, light, no hangover and so on. And still the other side can see who they are talking to! Plus you can do other things while hanging in a one-hour telephone conference, like getting some emails done.

In ISDN it seems to be possible to send a picture along with the caller-ID; but is has never really been used outside of the lab as far as I can tell. In SIP things are a lot easier, but again still I have not seen any SIP provider sending picture information along with the INVITE. So at the end of the day it is the responsibility of the PBX or even of the base to come up with a picture, based on the caller-ID.

Thanks to the iPhone and other smart phones, adding a picture to an address book entry has become real easy and popular. However, the problem is that the resolution can be brutal for a small device like the m9. Think about a 10 mega pixel photo! The m9 just has 16 MB RAM, so decoding the whole image is not an option. So right now, we put some limits to the resolution. And you can load pictures on the base, probably just a handful. More powerful is to load the pictures on the PBX (like the snom ONE), and then when the call comes in, the snom m9 loads the picture from the server.

In DECT, loading a picture is not trivial. DECT has timeslots with 32 kbit/s capacity, and you have to get the picture through that pipe unless you want to do something really fancy with multiple timeslots. So for an 80 x 60 pixel image, with let’s say 16 bits per pixel, you have 76800 bits, which can be loaded in 2.4 seconds. This is still okay. However, if you would have to load a let’s say 800 x 600 image, this would take 240 seconds. This would have a negative impact on the customer happiness! So what the m9 does, it takes the picture, decodes it (must be JPEG format to keep things simple), and then scales it to a format of 80 x 60 pixel. I believe the scaling is done “on the fly”, so that the internal memory is always 80 x 60 pixel, and there is no need to allocate huge amounts of memory. This may take a while, as the snom m9 CPU is just a small embedded ARM. However compared to the time it would take to transfer the image into the handset, it is well spent time!