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.

Multiple Handsets

Having multiple handsets registered to one base is somewhat a strange situation. Usually in snom, one product has one handset and with the m9, we do have up to nine handsets. This raises a couple of questions in provisioning, calling into the base and calling out from the base station.

Provisioning becomes pretty much completely different and I know that many PBX devices have problems coming up with configurations that register multiple SIP identities. One MAC address is suddenly associated with multiple accounts. We were thinking to “virtualize” the configuration, so that you can essentially provision the device with multiple MAC addresses. However after some initial tests and thoughts we came to the conclusion that this would be even more complicated and we stick to the good old XML provisioning style that most users know from the 300-series. We also had the snom m3 product before, and there the configuration was also in one file with one MAC.

Calling into the device was also causing some problems. If you have multiple handsets, the question is which handset should ring. Essentially, we can up with two answers: the first one uses the home-based model (most of the traditional DECT phones are still sold in the residential area), where the incoming call rings all handsets that are registered to the base station. This is what you pretty much get when you have only one identity, multiple handsets and you don’t configure anything else on the device. The other answer is to use the PBX extension model, where the base is more or less just a router and routes the call to the handsets. Even internal calls are routed through the external PBX in this model; for example for call recording that is necessary anyway. In this model the base has multiple identities and each identity has one handset assigned. Each identity also has its own address book, own codec settings and so on. It is almost like the handsets are registered to different base stations.

The outbound model is similar to the inbound model. In the “home” model, every handset uses the same identity (not much choice here, there is only one identity). In the extension model, each handset uses its own identity and uses that for the outbound call.

There are some cracks in the extension model. For example, when it comes to the PIN, the handset cannot deny that it is registered to the same base like other handsets. If one knows the PIN for the base, essentially that handset has control over the base. In the beginning the DND feature required the entry of the PIN, which was obviously not very practical; also because it did mean that everyone who has the right to put him/herself on DND, also had the right to nuke the base configuration. Our recommendation is to keep the PIN an administrator secret and don’t give it out to the user.

The button on the base

As most of you have probably noticed, there is a button on the base next to the power supply. This button has two functions. The first function is to send a hardware reset to the base, so that no-matter-what-is-going-on the base reboots. This is triggered by the transition from not-pressed to pressed.

The other function which is not so well-known is that you can use this button to factory reset the device. This is triggered when the button is pressed while the system boots up. There is simply a piece of software that checks during the boot up sequence, if the button is pressed and if that is the case, it erases the configuration file(s). So in order to factory rese the device, and your base is running, you have to press the reset button and hold it down for about 30 seconds, until the device has performed a whole reboot cycle. You can see by the change of the LED when the reboot cycle has finished.

The point about the reset button is that if you have lost the password or you have totally screwed up the configuration, you can just use this hardware button to get the device into a state like it was when it came out of the factory (well, it does keep the firmware that you have loaded). Many routers and switches have the same functionality and it has become a widely used standard to “nuke” devices this way.

It is definitively a security relevant feature. For those of you who have the responsibility to run a reliable service for a company, you have to consider that physical access means that whoever has physical access can nuke the device. Because the base does not have to be in the same room where the users have their handset, you should consider putting the device into a location that cannot easily be accessed by walk-in people. For example, the perfect location would be the ceiling of a storage room in the middle of the building. If you put the base above the ceiling cladding (where all the cable runs anyway), it would be invisible and have a great connection into the whole office. The LLDP asset ID comes in handy when you wonder where you exactly played hide and seek with the m9 base station.

Not all versions did the factory reset to perfection. But at least 9.4.7 should do it well. We just found out that e.g. the address book survives the factory reset, this is something that 9.4.8 will take care about; but at least you have a safe way to recover the device in case you should have lost your password.

Why 802.1X makes sense

As promised yesterday, today’s topic is the mystery of IEEE 802.1X. This standard comes from the Ethernet corner; many of you probably already know the wireless IEEE 802.11 standard for wireless LAN. And actually 802.1X is heavily used for wireless access points; this is where you have to enter your passwords before you can join a wireless LAN. For wired LAN I also developed my own simple formula for 802.1X: At makes sure nobody plugs a router into the network!

The story goes like this: One morning, the admin came back to work, and guess what: Nothing works. Why? There is a 2nd DHCP server in the network, and it should not be there! It took the admin one or two hours of hard work to figure that out, and the boss is already sending the first people home. Admin starts to sweat! The building has ten floors, and each floor has 100 rooms. Sending an email around who the heck has plugged a router into the network does not help—because everyone is offline from email!!! Admin starts opening doors on floor 1. First room: “Did you plug a router in?!” Nope. Next room. Nope, next, next, next. One hour later, next floor. Nope, nope, nope, next floor. Everybody gone home already, nobody even left for asking. Admin really starts to sweat. Top floor (okay here the story becomes unrealistic because in a real company there are no developers on the top floor). Admin spots a check 50 USD dollar router plugged into the network, takes it out. Voila! The network starts to work again. Too late, everybody already gone home!

I witnessed this situation three times already, believe it or not. First time it was in snom, and yes one of the developers wanted to test out a DSL router. It took only two hours to get that figured out. The second time was in a hotel, I was surprised that the first time I got a 192.168.x.x address and then later I got a 10.x.x.x address. The hotel management had to print out letters and slide it under the doors of all rooms, with apologies and if someone accidentally started a DHCP server. It was fun! It turned out someone was running a virtual machine and he forgot to turn the DHCP server off on one of the machines (wasn’t me). Well the third time was actually when I was travelling to Japan and I had my DSL router with me… How else can you work on VoIP phones in the hotel room? Must have plugged the cable into the wrong port… Anyway, it took hours until the hotel network was back… I put my router into the luggage later so that housekeeping could not blow the whistle!

So, long story short: A stupid tiny device can break the whole network or what? That’s where 802.1X comes in. It should simply not be allowed to plug unidentified devices into the network.

That’s why in many large networks, you first need to say who you are before you are allowed to enter the network. Actually, in many cases 802.1X is linked to VLAN as well. If you don’t authenticate, you’ll land in the general-purpose VLAN, where such things like multiple DHCP server can happen. This is typically the network that you get in the meeting room of large companies. But if you are able to authenticate properly, you land in “your” VLAN. That actually even makes LLDP superfluous. For our snom m9 device, it 802.1X is set up properly, the switch will automatically move the link into the voice VLAN. Neat!!!

802.1X has many ways for authentication. What we support on the m9 is the digest authentication, just like on the SIP registration. There are some other ways, especially certificate-based methods, but we figured that for right now a simple username/password-based authentication would solve the problem. So essentially what you have to provide, is a username and a password. This is sent to the switch even before LLDP kicks in, and as I said before, LLDP might not even be necessary any more after the device has successfully authenticated itself.

What is LLDP?

The first time I heard about LLDP was from a customer who (of course) said we needed this yesterday. First it sounded to me like it would be coming from the legal department, I guess I must have mixed it up with LLM or so. After using the search-engine-of-my-choice, I found the real meaning of the word: “Link Layer Discovery Protocol”. Still a little bit difficult to say what that exactly means, I dig deeper and came up with my own personal formula: It is DHCP for the VLAN! Okay, that makes sense!

We always had the problem how we should provision the VLAN. A DHCP option is too late (as some of our competitors did), because at this point the phone is already in a specific VLAN. CDP, the protocol from Cisco, was pretty proprietary (guess what the C stands for), so it was also not the best choice for an independent vendor who wanted to get this problem solved once and forever. I heard that even Cisco dropped CDP and decided to support LLDP instead. So LLDP would be our ticket to complete plug and play, including the VLAN, the associated priority bits (QoS in the LAN) and made it possible to have VoIP in the office with a quality that is as good or better as the good old ISDN! Even if the LAN is totally overloaded with messages from some freaked out devices (as long as they are freaking out in a different VLAN), the voice VLAN would continue operatios as if nothing has happened. Imagine someone on the phone screaming to the admin: "Our network is down! Do something!" And he says, "well you are talking over the network right now."

Digging deeper, LLDP is really primitive. There are just messages being sent every minute or so, there is no handshake, response, or anything that makes life complicated. From an engineering standpoint, that’s what you want to hear! After the switch realizes that the Ethernet link has come up and the connected device starts sending LLDP frames, it starts sending a few messages as well, so that the device has the chance to figure out what VLAN it should use. Coming from the SIP world, it sounded too good to be true!

Technically speaking, the phones don’t use LLDP; they are using LLDP-MED, which is an extension specifically for desktop phones. I think the MED must be standing for “Media Device”. But essentially it is just an extension of the LLDP core protocol. A few years ago when we started the topic, it was very difficult to get Ethernet switches that supported that and it was even more difficult to configure it. But I believe in the meantime you can even configure LLDP-MED in a convenient way through the web interface.

LLDP has some more advantages for IP phones like the snom m9. It also helps you to keep track what is connected where. Because the device reports its name, its firmware version, IP address, and an “asset ID”, the administrator can easily see through the management tools for the network, where the network devices are and to what port they are connected. The “asset ID” is actually a setting that you can set from the web interface, and it is very useful to indicate where the base it (e.g. “Room 4.1.2” or “2nd floor white cabinet”).

LLDP is actually related to 802.1X, which goes hand in hand with LLDP. But let me talk about this tomorrow. To be continued!

TFTP Server?!

Yesterday, I tried to hack my DVD player and set it to a different region code, so that I can see the movies that I bought when I was on the other side of the Atlantic. The attempt failed; however I was surprised how much technical detains you can find on such things like DVD players on the net, if you use the search-engine-of-your-choice for a few minutes! I must have missed a couple of years in DVD player development, this device that I bought has an Ethernet connection and yes, it is a beast with web browser, web radio and all kinds of stuff! So, I decided that today’s blog goes really into the technical details of the snom m9 under the hood. No reason to reverse-engineer it! I don’t think you have to “hack” anything on the m9; we try to make the features accessible for you as easy as possible (especally, dont try to change from US DECT to ROW dect, this will just screw the device up). But it is always good to know a few tricks that can make your life easier in case of trouble.

One of the major changes that came with the 9.4 version was the inclusion of a TFTP server. Yes, server! You might think, shouldn’t it be a client? The answer is the m9 as both a client and also a server. While the client is primarily used to pull down the configuration information and the firmware (if you don’t want to use the HTTP or HTTPS protocol), the server has a different function.

In contrast to the desktop phones, the m9 base does not have a display, so there must be a different way to recover the base station in case of trouble. Relying on the handsets is not an option, e.g. because the PIN go lost or there is some trouble going on with the handsets anyway. That’s why we included the TFTP server. In case of trouble you can use it to push the right firmware (back) on the device and don’t have to RMA it.

TFTP is very simple, but not very safe by nature. So keeping the TFTP server wide open all the time was not an option. Instead, the m9 opens the TFTP server only for 20 seconds after a fresh reboot and it only waits for the writing of one file: auth.txt. This file must contain the username and the password, which you would also use when logging into the web interface. For example, the file could look like this:

# Samle auth.txt file
username: admin
password: password

So in other words, in order to use the TFTP server you must know the username and the password. Once you got it, you can read and write all files in the file system. You are in full control! For example, you can make a backup of the files that are in the /nv directory (which stores all “non-volatile” files). One special file is the private key of the device. In the /nv directory you will find the privatekey.txt and certificate.txt, which contains the keys for the device (every device has a different one, and it depends on the MAC what is in the certificate). It is a good idea to grab the private key and also store it in a safe location. Because if you should forget about the username/password or some idiot changes it without letting you know, you can still unlock the TFTP server by writing the privatekey.txt file with the exact content of the private key. As you probably know, private keys are not supposed to leak out, so be sure you store it in a really safe place! Talking about security, you should also keep in mind that TFTP sends the packets unencrypted; so you must be sure that no one is running Wireshark in your network while playing with the TFTP server…

In the /nv directory, you typically find those files:

• adrbook: This directory contains the address book entries.

• ata-app: This is the main application that e.g. runs the SIP stack and the web server
• ata-ctrl: This thing is responsible for getting the m9 up and running. This one runs the TFTP server and other network services.
• ata-media: This program is responsible for the RTP processing.
• base-type.txt: Here the m9 keeps track what DECT version it is (e.g. us or row for USA and the rest of the world)
• base.bin: This contains the firmware for the DECT module
• base.txt: The short version text for the DECT module. If this one is different from the one being reported during the boot phase, the m9 will perform a software update for the DECT base station.
• certificate.txt: This file contains the certificate for the device.
• dectvoice.ko: This is the driver for the DECT module.
• dhcp.info: Here is some additional information that cannot be stored in the resolv.conf file.
• handset.bin: This is the firmware for the handset
• handset.txt: Short description for the handset firmware.
• handset17.bin: Because there are two handset versions out there, this one contains the firmware for the new “17” version handset.
• handset17.txt: Short version name.
• html: This directory contains all the HTML templates for the web server.
• mac.txt: This file stores the MAC address for the device.
• privatekey.txt: This file contains the private key for the device.
• random.txt: Here the m9 stores the last random number, so that every reboot cycle comes up with a new random number.
• rc.snom: This is the bootup script for the device
• resolv.conf: This links actually to /etc/resolv.conf and is used by the standard programs to find out about DNS
• rfpi.txt: This file stores the RFPI number for the base (DECT stuff)
• serial.txt: Stores a serial number from production.
• settings.xml: This file contains all the settings for the device.
• version: In this file, the m9 keeps track which firmware version has been loaded.

I would copy all files that are there, so that later, if you are experiencing trouble, you can always copy the files back and resume from this point. If you like, you can also put your own certificates and private key on the device this way. Playing with the MAC or the RFPI does not make sense to me; I don’t think you will get anything out of this. But it might be fun to change the HTML pages, for example if you have a customer who should not see everything.

Finding your handset

When you use the m9 in a dark room, you might have noticed that it turns the background light for the keys on from time to time. This is not a bug; this is supposed to find your handset in a dark room. Not sure if this is useful in y typical office environment, but it is useful e.g. when you use it at home. It does put additional load on the battery though. There is a way to turn it off (in the menu, choose Preferences and then Display, Backlight). When I select “Activate” the lights go steady, however not sure if that feature got lost in translation or there is a smart reason for calling it this way. Anyway.

Another way to find the handset is to log into the web interface of the m9, and there you go to the DECT tab. There is a button called “locate handsets”. This will ring all handsets that are currently registered to the base station. This is not what you want to do at home when the kids are sleeping; but for the administrator trying to find out which handsets are registered this is a good way.

The other classic to find your handset is to call it directly. We know this from finding your cell phone. Good news is that the DECT handset has a good chance to stay up for a longer time, a couple of days if you don’t decide to leave the backlight on all the time.

All methods have in common that the handset battery must be okay and the device must be turned on. There is little we can do about that!

IPv6

The snom m9 is actually one of the first SIP devices that I know that support IPv6 and IPv4 at the same time. IPv6 will become very important over the next few years, and to me it looks like most of the VoIP industry is still ignoring this fact to a very large extend. IPv6 does not only make IP addresses a lot cheaper; it does also make NAT obsolete, which is one of the biggest problems in the deployment of VoIP in the Internet. And IPv6 was specified when VoIP was already there, so the engineers had the chance to put some other specifics about real time communications into the protocol that will make our life a lot easier.

I believe right now only a few guys are using the IPv6 feature. At least I know only one! Most of the features were so far tested only in the lab environment. It would be great to get more feedback, because honestly lab testing is good and necessary but often the real life out there looks different.

For example we had a discussion if in the world of IPv6, we would still need a DHCP client. As you know, in IPv6 there are router advertisements going through the network, so that every device can just pick an address and go ahead. Specifically, how would you find the DNS server? The m9 supports the multicast DNS server discovery method, but it was not clear how much that would be done really in the real life. So at the end of the day we decided to put in a DHCPv6 client in, where the DHCP server can explicitly set the DNS server and also other parameters that we know from DHCPv4.

Also, we were discussing how you would find the provisioning server in IPv6. Because there is nothing like an option 66 and we don’t even know if there would be a DHCP server at all, we decided to go another route and use DNS to locate the provisioning server. So we added another stage that tries to resolve “m9.snom.provisioning.local” and fetch the provisioning data from there. This method also works for IPv4, and as long as you are able to control the DNS server that is a beautiful way of controlling where you fetch your configuration from.

Apart from that, I was surprised to see how stuff like SRTP and SIP/TLS was working pretty much the same in IPv6 than in IPv4. It makes me optimistic that once that the transition from Ipv4 to IPv6 is at full speed, the m9 should do the upgrade without even a reboot of the base station. I would love to hear your stories.

WLAN version DECT?

Isn’t DECT a dead-end technology? With WiFi and WLAN practically everywhere today, it seems there is no reason to have a different technology for handsets any more.

Well, that’s what we thought before we started the DECT adventure. However, in Europe DECT was very popular already, practically everyone at home was already using DECT for many years and it felt natural that DECT and VoIP had to go together. I think the biggest advantage about DECT is that it takes only very little power. DECT was designed for low power! A handset can sit there, not sending a single signal out for a whole day and just (from time to time) listen if there is a call coming in. That is extremely power efficient, and this explains why DECT devices usually have a standby time for a week or so. BTW it also has the side effect that there is only very little radiation sent out by the mobile devices, some people get crazy thinking about brain cancer from using the cell phone too much and the whole electro smog story.

Apart from being able to build devices with cheap batteries, the other big benefit for DECT is that it runs not in a free spectrum. That means it is very well with the interference. Because nobody else is allowed to disturb the signals, the quality of service in DECT is much better. After all, it is the good old TDM world! If you have successfully allocated a channel, you can use it exclusively for your voice stream. It is old-fashioned, but in the wild world of wireless that is an advantage IMHO.

Of course DECT is digital. It is no comparison to the analog cordless devices that were popular in residential devices not too long ago. Digital has also the advantage that things like Caller-ID are a no-brainer, dialing can be very fast, and you can even have such features like picture Caller-ID or use your address book from the base station.

Oh and another thing that DECT has which I believe is very difficult in WiFi, is the handover. DECT allows that you walk from one base station to another and keep the call alive. This is something the m9 does not support yet, but it is so cool that we are working on it.

And I think last not least, the number of DECT base stations that you need to cover and office if far less than the number of WiFi access points (think two or three dimensional!), so even if companies have to roll out multiple infrastructure elements, from a number perspective the problem is not too big.

Welcome to the snom m9 blog

I wanted to share with you what we are doing on the snom m9 side, what kind of new features we have, how to use DECT in VoIP, what we discovered, tips and tricks and so on. I thought it would be useful for those who are using this device, have to install it, have to maintain it. There is still the snom forum, if you have questions about how to get it working. But a blog is probably a better way for sending infomation out into the Internet. Of course you are also welcome to comment.

The m9 is not a new product any more, and it did take some firmware versions to get it into a shape that you can use in everyday's life. That's why the title "the whole 9 yards" seems approriate to me. At least it was not 9 years!

I work for snom. So don't blame me for saying too many good things about the snom m9! But apart from the usual marketing stuff you find in blogs written by company employees, I hope I can provide some interesting information as well.