Simple transfer like in the good old days

In the old days we were using a DECT system for the company (there was no VoIP at this time). I don’t recall ever putting a call on hold ever in my life before, but I do recall that I did a transfer. However not by using buttons on the handset, just physically: It was more a handover than a transfer. I just walked over to the person that should get the call and gave him my handset.

While that sounds antic, it was very productive (probably because this was a small office). While walking I could still talk, thanks to the cordless nature of DECT. Then before the transfer, I could visually verify that the transfer target was ready to take the call. Then the handover was also very simple, just physically pass the device into the hand of the target. The only problem was that after he finished the call, I wanted the handset back. This probably explains why DECT handsets get displaced to easily (the m9 has a function to locate all handsets to address this problem).

Key systems also used to be very productive. Unfortunately those systems were not in the favor of the IETF standardization committee and it is impossible to implement that with the existing standards. Seems like in the old days life was sometimes easier.

Anyway. Maybe nobody needs these features anymore because you cannot walk into the other person’s office any more if you are working from home. That’s something you could not do in the good old times!

Why software updates take forever

When you update the base station, it takes just a minute to download the software and install it. However, when it comes to the handset software update, it takes much longer. This is surprising at first glance, especially because the handset has just something like 768 KB Flash memory.

The reason for that lies in the DECT protocol. DECT has many advantages when it comes to the robustness of the voice transmission over the air and the lifetime for the battery. Voice is being transmitted at a rate of 32 kBit/s in the core DECT specification, which is enough for a good audio quality. However, when performing a software update, the constant bitrate of the voice channel becomes the problem: 768 KB times 8 bit divided by 32 kBit is 196 seconds, which is 3:17 minutes. Add the overhead for securing the channel with checksums, acknowledgements and so on and you get ten minutes for updating the firmware over the air.

We can actually be happy that the handset has just 768 KB memory. Imagine you wanted to update a 1 GB Flash over the air! It would take 4 days to update the software, if nothing goes wrong during that time. This also answers my question if it makes sense to have an Android based DECT handset: You need to have WiFi on the handset along with DECT. Wifi for the software updates and other miscellaneous data transfers and DECT for the voice calls.

Now it also becomes obvious why we included a USB connector in the handset. In the factory or even in the warehouse later, making a software update over the air for a large amount of handsets is not an option. Then it is much easier to connect the handset through USB and do the software update in a few seconds.

This also explains why you need to manually update the handset. If we would automatically update the handset after a base firmware update, users would face an unpredictable outage for up to nine times ten minutes (1:30h). And if the handset is low on battery, it could get stuck in limbo during the writing of the software. This could drive people mad, including our support department. Therefore, we thought it is better to leave the software update initiation to the user and he can make the decision it is to update the software on the handset.

It is cloudy (with a chance of meatballs?)

It does make a lot of sense to register the m9 in the cloud. For many small offices, most of the calls with go to an external number anyway and in all these cases, you do need a working internet connection anyway. Microsoft Lync hosted is one of the hottest topics out there right now. Many people say that Lync is primarily geared at the fortune 500 companies, but why not use it in a restaurant, a shop or in a dental practice? The technology behind Lync is complex; but the frontend to the user is actually pretty simple and users can enjoy many of the powerful features that come with Lync. So it is time to give it a test drive!

First, we made sure we are running version 9.5.6 (or higher). Old versions had problems with some DNS failover, so you have to be sure to run that version. You can check on the wiki on how to perform software upgrades (see http://wiki.snom.com/Snom_m9/Firmware/Release). You can check this on the status screen of the m9 and should see something like this:

Before you can register, you must either upload the Root CA for the certificate that SBC is using or just accept all certificates. You can do this also from the web interface of the m9:
Make sure that you select the right server type and that you want RTP encryption. In our example, we are using identity 6, but of course you can pick any other identity. Just make sure that you have a handset assigned to the identity if you pick something else than identity 1.
Then it is time set up an account for Lync. Fill in the information provided below and make sure that you activate the identity. The outbound proxy is “sip:sip.mshosted.net:5061;transport=tls”, it did not fit into the screen shot. You don’t have to fill in the mailbox, this will be automatically be filled in after the registration was successful.


You can check on the status page (registration tab) if the registration was successful. You should see “200 ok” on the page. After that, should are able to make a call.

Important disclaimer: The snom m9 has not been "officially" tested with Microsoft Lync. Use it at your own risk and fun.

Yealink and DECT?

I remember that Yealink had a DECT phone “W52”. It is not unusual that Yealink takes a look at what snom does, and then comes out with something similar. It looked like they did this also after snom came up with the m9.

Anyway, when I searched for Yealink and DECT, there was a press announcement and you can even buy it on the internet. However the price seemed to be unusually high, so it seems that Yealink abandoned the product. Is that right? Maybe someone out there can comment on this.

If they really abandon the product, this raises questions. Was the volume not high enough to keep the product alive? Does Yealink instead plan to come out with a WiFi phone to address cordless, even though snom did not do this yet? I can hardly imagine that Yealink ignores the cordless space. Let’s see, maybe there is a W53 coming around the corner.

Routers and NAT

IPv4 remains to be a pain in the neck. The biggest problem is that there are not enough addresses, and people need to do dirty tricks to keep the network up and running.

One of the biggest problems is that routers have only a limited number of NAT UDP table entries. The problem is this: When a client in the private network sends a UDP request to the public Internet, the router has to remember from which private IP address and port the packet came from. It associates that address/port with a port on the public interface of the router. Obviously you can have up to 64 K ports on a router doing this trick.

However, there are at least two problems. The first one is that most devices have a limited table size. For example it is not unusual to have just 32 table entries. So if there are 32 devices in the private network sending out a UDP packet, the router will have to drop old table entries to accommodate the new entries. Then when a response for an old port association will come back from the internet, the router will drop the packet.

The problem is even bigger.

Because this works okay when you use UDP for DNS. DNS is pretty much stateless here, and if the NAT table should have dropped the connection already, the DNS client will just repeat the request and the whole thing takes a little longer. But when we start using SIP registrations, dropping the NAT becomes random and sometimes (probably most of the times) it works fine, and then sometimes it does not work fine and you are missing incoming calls. That’s when people get frustrated. I don’t even blame them: It is very difficult to trouble shoot this problem. DNS and other UDP-based services work okay, but SIP traffic just gets dropped randomly. It is easy to point fingers at the SIP devices, but now you know, there is not much the device can do.

What people do is making the registration interval shorter. I have seen registration intervals of five (5) seconds! This starts a kind of battle for the shortest registration duration, all contributing to a huge waste of bandwidth. It is almost like denial of service, but it keeps the service calls for the providers low. On the m9, I must say we were very hesitant to add support for STUN (market demanded it for those providers who cannot afford the luxury of a session border controller); but at least we made the default refresh interval very short to have a good chance to win in the battle for the ports, hehe.

Is TCP the answer? Not really. In the real world, the number of TCP connections is also limited for the cheap routers and it becomes as erratic as with UDP. I have seen cases…

This is madness.

I can’t wait until we turn off IPv4 and use IPv6 instead. Lets hope for better routers. Cheers.

Hello snom Active!

There is a new service available from snom, called “snom Active”.

This is a central provisioning system for installations where other provisioning is not available, e.g. no option 66. What happens is it goes to a central provisioning location and is maintained from that service. So if the device does not have a provisioning location setup yet, it will connect to the public Internet and download its configuration from there.

This kind of provisioning service was already from snom; however it was not a very well-known feature because it was very difficult and cumbersome to use. The new snom Active makes it possible to log in on distributor and VAR level and manage devices in bulk or individually. There are templates available; the whole configuration can be set up by snom Active (the previous snom provision mechanism was just a redirect service).

New is also that the snom Active checks the client certificates from the devices. The m9 has certificates built-in, snom Active will actually verify that the device with the Mac address therefore it really is that device and not just a web browser in the internet trying to steal some passwords. Because snom Active trusts snom based certificates, this service is really plug and play and secure.

Use cases are like this: A VAR can manage the devices for different devices, so that they will automatically always fetch the right configuration, even if the customer decides to “play” with the settings. A factory reset will always get the devices back to the state they were during installation. If changes become necessary, they can be done on snom Active, not on the device. This solves some problem with firewalls where it is difficult to get access to the device.

Another use case is that a distributor sells the m9 preconfigured for a service provider to residential customers. For example, let’s assume that distributor D makes a deal with service provider S, and provides a DID number for each device that he ships. Then the customer who receives the device plugs the device in the network, and voila the devices fetches the configuration, sets up the registration and the customer can start making the first phone call without even knowing what an IP address is. This also makes a lot of sense for promotional purposes, because many service providers are already handing out prepaid accounts for trial use—once the small prepaid account is used up, customers are redirected to a subscription service where they can sign up for the real service; all on the phone. I believe this is really a killer feature that might be an inroad into residential customers, talking about customers that expect the simplicity of a PSTN installation.

Please note that this service requires version 9.4.12 on the m9, because the previous versions did not check the location for snom Active.

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.

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!

The cable view

The last post was about logging and how it helps you to find out what is going on in times of trouble. But that is not the only tool that the snom m9 offers. There is another tool built in, it is called the “PCAP trace”.

PCAP means “packet capture” (see http://en.wikipedia.org/wiki/Pcap) and it is a format that several tools understand for the display of what happened on the cable (whatever that is). For example a popular tool is “Wireshark”, which you can easily run on the operating system of your choice. You can see all protocols, IPv4 or IPv6, LLDP, ARP, SIP, RTP, HTTP, and whatever might be in your network.

Usually, when you want to see what is going on in the network level, you need to use either an Ethernet hub (if you can still find one) or set up a port monitoring on the Ethernet switch. Then you can record the packets on the Ethernet interface of a PC. This method a “true” picture of what is going on; however it is a lot of work if you quickly want to see what is going on. And you need physical access to the device, and in cases when you are using things like 802.1X things might get really tricky.

The snom 300 series already had the PCAP trace possibility for years and it proved to be very useful. Instead of connecting an external device, the phone just records the traffic from the device and stores it internally. Then you can download it from the web interface. There is a limit on how much you can record, but usually a few hundred KB are not a problem and this usually helps a lot to find out what is going on.

The snom m9 does essentially the same thing; however it adds the possibility to start capturing right after the boot. This makes it possible to see for example the DHCP traffic or 802.1X in the beginning. In the case of the desktop phones, you really needed to connect physically to the device to see this traffic. On the m9, you can just set the switch and then the software will automatically turn the recording on in the beginning.

Because of the dual IPv4/IPv6 stack on the m9, it is now possible to “debug” DHCP. For example, if you have problems with DHCPv4, you can set the flag to start recording during bootup, then reboot, and log into the device using the IPv6 local link address and download the PCAP trace. For development, I can tell you guys, this was a killer feature. It was never so easy to see what is going on during the boot phase!

Logging

Today’s topic is logging. In theory, you would never need it. However we all know from the real life, that when things go not the way they should, it is good to have some help from the device. That’s why the m9 comes with a powerful logging subsystem. You can see the log easily from the web interface, there is one page where you can set the log level and there is another page where you can see the log messages.

In the snom desktop phones, there is just one flat log level. If you turn log level 9 on, you get flooded with messages. They may include what you need, but you have to be quick to get them out of the system and you have to spend some extra time to get them out. Because if this, on the snom m9, we split the log up into different categories:

·         General events: All other events that do not fit into any of the other categories.

·         Media-related events: Events coming from the media subsystem, for example RTP related messages, SRTP decoding problems.

·         SIP registration messages: Everything that has to do with the SIP registration. Not only the SIP messages, but also the routing of those messages, refresh intervals and so on.

·         SIP call messages: Everything related to the SIP call. As with the registration, not necessarily only the SIP messages, but also other stuff associated with a call.

·         Other SIP messages: All other SIP messages, for example subscriptions, instant messages.

·         Web server events: The snom m9 has a built-in web server; in this log level you will see when someone logs in, when a session expires and so on.

·         DNS events: DNS can be complicated, and there is a special log level for the DNS messages.

·         LDAP events: Everything related to the LDAP client in the m9.

·         DECT events: Events that have to do with the DECT subsystem.

·         Network events: Events that are coming from the network subsystem, for example DHCP messages, LLDP, 802.1X messages.

·         TLS: If you have problems with the TLS subsystem, those messages are in this log level. You can even increase the log level, so that you can see what secrets are being exchanged.

·         ICE: The snom m9 uses ICE for some server types, and there can be specific problems in this area. That’s why we included a log level for this.

·         ZRTP: If you are using ZRTP, you can see the related messages in this log level.

In each category, you can select between 0 and 9. 0 means that there are no messages being shown in this category; 9 means as much as possible. The m9 limits the total to around 100 KB; if the total content gets more than that, the m9 drops the oldest log entry. This makes sure that the m9 is not running out of memory because of logging.

Also we decided to make another change to the behavior of the snom desktop phones. The newest messages are at the top. This is simply because usually you are interested in the most recent messages, and you don’t have to scroll down the page to see them. The other change that we did is that the log messages are mixed with the SIP messages. This makes it a lot easier to see how the log messages relate to the SIP traffic. Having it in two different pages makes this job a lot more difficult.

SIP Interoperability?

Sometimes, when I read datasheets that list what kind of RFC the SIP phone supports, I don’t know if I should laugh or cry. Interoperability has become a disaster in the SIP world. If you buy a cell phone, there is the “GSM” logo printed on it and you can be pretty sure that the core features just work. In SIP, that’s not the case and there is not even a logo. Naïve customers, big or small, but SIP devices and expect that they just work out of the box. Seems like ten years after SIP got the heads up, the SIP RFC is more like a place for fame (not fortune) for the authors instead of solving basic problems. There is an interesting site that lists the explosion of SIP standards, http://rfc3261.net/.

On the desktop phones, snom accumulated more than 700 settings that tell the phone all kinds of things, including parameters for the SIP stack. My most famous example is the “Refer-Brackets” setting, which tell the phone weather it should put those < and > brackets around the destination or not. Believe it or not, but in the year 2011 this setting is still in use. LMAO. How can you know when you want to register a phone to your server if you should turn the setting on or off??? Another funny setting is the “Broken Registrar”, which practically turns off any security check on the phone, so that anyone in the network can bomb the phone with UDP and make it ring.

In the m9, we tried another approach. Because the number of settings on the desktop phone is significantly bigger than the number of servers in the market, we decided to make settings called “server type” that handles all those tricky special cases. For example, if you are using snom ONE, just set the server type to “snom ONE” and then the interoperability should be working okay. This is not only a lot easier for the user; it is also a lot easier for the CPU. Having 700 settings does cost memory space, and having just one setting and some if-the-else checks in the code makes the code a lot more compact.

There are still some settings outside of the main server type setting. For example, there is still a settings “SRTP enabled” which kind of parameterizes the server behavior. There are other settings that just have no influence for certain server types (like “use ICE”), maybe one day we can add a JavaScript in the web page that just hides those settings when you select a certain server type. Anyway.

There are some attempts to get the situation with the SIP standard under control. Especially on the SIP trucking side (that’s where the money is!), there are some promising activities that try to standardize the way all those RFC should be used. For the snom m9, this means: As soon as those standards are clear, we will start adding those to the dropdown menu to make the users life easier and give SIP a better experience than trying hundreds of settings out!

Trouble with the default PIN!

There is a lot of talk about security these days. The m9 has a lot of stuff that should help to make your phone calls secure. However, what is all the security good for when users don’t change the default passwords?

The default PIN for the base is 0000. This is something that is hard to avoid. We were thinking about assigning a random PIN in the factory, so that it becomes a lot more difficult to hack the base which is using the default PIN 0000. However, marketing sent a very clear signal: Keep it simple for the users and so we kept the default 0000 PIN. However, we put a warning on the landing page after the user logs in and make the point, that choosing a different PIN does increase the security of the device a lot. For example, you can factory reset the device if you know the base PIN without having to have physical access to the base—and not even access to the room or even building (keep in mind this is a wireless device).

It is important to know that handsets can register only while the DECT base accepts registration. Essentially what happens is that the handset and the base use the PIN as a “salt” to generate a 128 bit shared secret that is stored both in the handset and the base. Later, when the handset wants to register again, it is using the shared secret and the base compares it with the stored secret. The generation of the shared secret is possible while the “registration is open”, probably a more precise wording would have been “the base is open to generate shares secrets” (again, I guess marketing would have stopped us here as well). The registration is open after a reboot for about ten minutes and after the registration was turned on explicitly from the web interface.

During that registration phase, everyone who knows the PIN can register a new handset. This is a dangerous phase; for example if you automate the PIN trying process you could probably easily try out the 10000 possible combinations. There is a warning sign on the web interface during that time.

The good news is that typically, the base should not be rebooted too often and within the booting period, the admin can check if there are unwanted handsets registered to the base. But as a minimum I think admins should change the PIN code to something better than 0000. And maybe we should open registration after a reboot only if the admin logs into the web interface and hits the registration button.

Again, I suspect marketing would stop us again here! So for now, we need to know that the default PIN is a bad thing, should be changed ASAP and you should not reboot the device too often, and if you have to, watch which handsets are registered to the base.

Where is my base?

Another popular problem is how to log into the base. Because the base does not have a display, it can be sometimes a little problem to get to the web interface. There are a couple of methods on how you can get this done.

1.       If you were able to register a handset, you can just use the display of the handset. In the menu, there is an icon “Settings” and at the very bottom there is “System Info”. On the first page you’ll see the MAC address and the IPv4 address of the base. Voila! On the other pages you can see more information like the software version, the DECT identifiers and so on.

2.       If you are registered to a SIP server such as the snom ONE PBX, you can check the web interface there to see what IP address has been registered.

3.       If you have access to the device that runs the DHCP server in your network, there is usually also a way what leases the DHCP has issued. For example, most SoHo routers show the DHCP table in their web interface. The snom m9 uses MAC addresses that start with 00041330xxxx, so as long as you don’t run too many m9 in your network, it should be easy to figure out which one you got.

4.       If you are running Windows 7, Windows Vista, Linux, MacOS or another operating system that supports IPv6, there is a another astonishing simple way to log into the web interface. You can use a link-local address which is based on the MAC address. Essentially you need to look up the last 4 digits of the MAC address and copy it onto the following link: http://[fe80::204:13ff:fe30:xxxx], where you have to copy the last 4 digits into the xxx area. Then you can go to the status screen and check out what IP address was assigned to the device. BTW this is also a great way to debug problems with DHCP, because you can for example get a PCAP trace from the device easily.

5.       If that all does not work for you, there is still the good old way to use Wireshark and filter for bootp. Then you will also see the DHCP traffic between the snom m9 and the DHCP server and drill into the packets to get its IP address.