The m9r is out

The m9r is out for a while now. While it took some time to get the m9 to where it is today (thus the blog name “the whole 9 yards”), the introduction of the snom m9r was so smooth that it was practically unnoticed.

The m9r was modified only in areas that have very low risk of bringing in instability. More memory never hurts in the computer industry, and on the handset side there were improvements with the handset plastic and acoustic. Also the antenna design was improved, giving the m9 a longer range than the m9 had before.

I believe that is okay. Stability is very important for the users of DECT phones; fancy features are expected on smart phones but for a DECT device, customers essentially want no surprises. The m9r is essentially like a facelift in the car industry, when they change the bumpers and throw in a few more extras.

The big question will be if we should come out with m9r firmware releases that take advantage of the increased memory. For example, I saw the comments on ZRTP: We did not include ZRTP on the regular builds because it takes up too much memory for stable operations in the m9. But we could include that in the m9r builds where memory is not such a problem. For now, we do this only for special builds and prefer to keep both variants with the same software. It does not only make our life easier, it also important for the m9 users that they continue to have access to the latest firmware.

M9 and snom ONE

More than two years ago, snom decided to add another product to its portfolio: the snom ONE software, formerly known as pbxnsip. The product names had both single-digit numbers in it, and this seemed to be a good starting point for a close integration.

The m9 supported the pbxnsip software already for a longer time; so supporting snom ONE was a simple task. For a certain time, both server types were available; however over time they were merged into the snom ONE server type.

Having two products from the same company implies that the interoperability works slightly better than with other vendors. For a DECT handset, the potential for doing this is not as high as for a desktop phone, but there are optimizations that should make the usage of the m9 as easy as possible.

For of all and probably most important, the plug and play mechanisms of the snom ONE are supported in the snom m9. The m9 supports the multicast discovery of the snom ONE, and both devices trust the snom Root CA, so that a certificate-based client and server authentication and secure provisioning is possible. In other words: Enter the MAC address of the m9 in to the extensions where handsets should be deployed, plug the m9 in and you should be all set. There is only one little glitch left, which is the assignment of the mobile parts to the extensions; but most people should be able to figure this out when looking at the display of the handset.

The provisioning makes sure that the connection between m9 and snom ONE is as secure as possible. Both TLS and SRTP are being used by default. The encryption on the wire is probably better than the encryption on the air (DECT). The snom ONE also provisions the PIN for registering the handset to the base; this is a common pitfall when the PIN is not four digits as the DECT base supports only four digits.

Because the m9 also sends RTCP-XR reports, the voice quality reporting per each call should help monitoring the connection quality on the wire. However as the connection in the air is digital, signal strength has not been taken into account and this would IMHO be difficult to achieve. A weak signal does not mean that the user experiences degraded voice quality. The quality degradation is actually quite abrupt; to have a fair evaluation about the bit error rate the handset would have to send quality reports back to the base; which I believe is not a feature in DECT.

On the feature side, there is not too much to provision. The handsets don’t have any buttons that could be programmed. M9 users have to use star codes to get things done. The only exception to this is calling the mailbox. Establishing a conference is done locally on the base, so that one does not count.

M9 and Asterisk

Asterisk is the most popular open source PBX. There must be millions of Asterisk-based installations out there. When comparing Asterisk with other PBX from Cisco, Avaya, Mitel, or others, the thing that is most obvious to me is it level of interoperability that invited and still invites many manufacturers of devices and software to integrate with Asterisk. This is the counterpart of the closed system where the warranty ends if you bring your own device.

We see that many of the snom m9 devices are used in environments that use some kind of Asterisk. While snom has its own PBX snom ONE, snom devices are still highly interoperable with all kinds of PBX in the market. It makes a lot of sense for snom to make the interoperability with Asterisk as smooth as possible.

The m9 has a slightly different concept than the desktop phones: Instead of having a seemingly millions of different configuration options, it has one drop-down per identity that determined the interoperability mode with the used registrar. Instead of having to figure out how to set each option right for your installation, the m9 comes with a pre-programmed list of servers. When selecting Asterisk, a few things like ICE and presence publication are automatically disabled. So just select the right dropdown and you should be all set picking the right settings for Asterisk.

We even brainstormed what we can do to improve the interoperability with Asterisk, but not much came to our mind. Newer versions of Asterisk support TLS and SRTP; on the forums we saw some hiccups with long TCP packets that seem to be fixed with the latest Asterisk version. On the m9 side, it seems there is nothing else that we can do to make this work better.

One interesting development where the Asterisk and snom m9 combination could become interesting is IPv6. Both Asterisk and the snom m9 are on the leading edge when it comes to IPv6. I personally know about an Asterisk snom m9 IPv6 deployment; it seems that this is working well.

When it comes to Asterisk interoperability, it seems that the m9 is in a good shape and we are running out of ideas what to do next. Improvements are more of a general nature that applies to all PBX systems. If anybody has an idea how the Asterisk integration can be improved, it would be interesting to get that feedback.

Another IPv6 Day

On June 6^th, there was another IPv6 day. As the snom m9 is one of the few devices that I know of which supports IPv6, that day was a special day for us. We know that a few folks are using IPv6 with the m9, but honestly it would be great to get more feedback if we are done with the IPv6 support.

It seems the biggest change was that Google added an AAAA record for the email server address. That screwed a lot of email clients up, and I am not sure if Google kept the records or just had set a very long TTL, so that the problem did not go away on the next day. Actually, if the m9 would have been exposed to IPv6 and the SIP server also supports IPv6, the transition should have been very smooth. The user should not have even noticed it. I don’t believe many m9 users actually had that experience.

My biggest concern is that the firewall manufacturers will advertise NAT as a security feature also for IPv6 and the purchase departments are too clueless to find out that this is nonsense. The idea of a 50 USD router with the IPv6-ready logo sticker on the gift box scares me. Probably we only have to wait until some smart-ass lawyer sues a router manufacturer because they exposed “private” IPv6 address to the public, and a badly configured PC in the LAN gets hacked (that’s why we have stickers on the microwave telling us not to put mister hamster into the device). Then all legal departments of the router manufacturers in the world will take over and mandate that addresses in the LAN are not exposed to the public, evil internet. I even hear that they are now trying to put that functionality into the Linux kernel, so they say, to make sure that at least the NAT implementation is not as buggy as with IPv4. If that should happen, the whole exercise with IPv6 was for nothing and we will still associate VoIP with on way audio: Can you hear me? Maybe not hearing the other side is a security feature, for some people. Not for me.

No more DECT from Polycom?!

Just one day after the news that the Polycom DECT handsets are now certified for Microsoft Lync, Polycom sold the cordless unit to a private equity firm for half the price that they paid five years ago. Polycom was perceived as a major player in the DECT IP world, do we have to be concerned that this is the beginning of the end of DECT?

I don’t think that this move was so much about DECT. Most of the price that Polycom paid for the unit was actually for WLAN-based technology. I cannot agree more, WLAN-based handsets are an endangered species. In an age where it is almost impossible to get a smart phone without camera and WLAN, making WLAN handsets is destined to a very small market niche. The list of failed vendors trying to make a WLAN-based handset is long. Voice remains a very important application in the LAN (wireless or not), and DECT continues to provide a solution that fits the needs. Looking from the outside I would say that the DECT handsets were so much embedded into the cordless unit that they had no choice but to sell it off as well.

Selling the business unit does not mean that the unit gets shut down. It will be interesting to see what the next moves are in the WLAN and in the DECT space. My guess: They just OEM a smart phone and put software on it for the WLAN part, and continue what they did before on the DECT side.

Virtual LAN

Everybody is talking about virtualization today. Virtual servers, virtual classes, virtual anything. There is one more thing: The virtual LAN.

It must have been around the end of the 1990s when they introduced VLAN. It was a big topic, because many Ethernet devices could not deal with it; it is not 100 % backward compatible with the good old LAN. The core problem was that the packet got 4 bytes longer, and that could break the MTU, so that the last bytes did not make it any more.

Admins can just run a physical LAN cable and then split it up into different “virtual” LAN, which behave pretty much like physical LAN. The main difference is that that physically available bandwidth now needs to be shared with the different LANs. This raises the question which packets get routed first, in case that not everything fits into the LAN. With the introduction of VLAN, you can also say bye-bye to the idea that there is a fixed bandwidth like 100 MB/sec. That’s why they introduced priority bits, so that you can have up to eight different priorities. And that’s something that is useful when it comes to VoIP; because you want to make sure that voice packets don’t get dropped when there is a lot of traffic.

This actually works quite well. I remember someone called me up on the VoIP phone, screaming “the LAN is down!!!” After a short moment, I asked “how can you talk to me if the LAN is down”, and then I realized that we actually were using the VLAN. It turned out that there was a loop in the LAN, but fortunately on a lower priority than the voice VLAN, so that even under such a bad situation the voice packets made it. Voice is more important than data.

VLAN typically have 12 bits, and 3 bits for the priority. There is a lot of stuff around those bits, for example the question who is allowed to be in a VLAN, what quality is allowed in which VLAN, and so on. Switches have to work together with the devices, and if you want to have a waterproof system, there is a lot of work to do to have everything set up properly. What most people do is to pick just a VLAN number like 128, and just hope that nobody abused the VLAN for bad stuff. In most LAN that is okay, the setup is easy and the gain from that is good.

However, talking about the cloud, VLAN are also available in the cloud. When service providers offer metropolitan Ethernet, 4096 VLAN are not enough anymore. So they came up with another VLAN type, which can have millions of different VLAN, so that the service provider can offer a couple of VLAN to their customer. IMHO that is very cool. The virtual LAN extended into the Internet. Rent a DHCP server in the cloud! Fortunately, there is a backward compatibility into the on-premises VLAN, so that existing devices don’t have to worry about it. And the quality of service can also be guaranteed, so that voice packets don’t drop.

Of course everything works fine with the m9.

EULA?

For those who update the m9 recently, you might have noticed that you have to accept the “end user license agreement” before you can actually do something in the web interface of the snom m9. What’s going on here?!

Generally speaking, when customers purchase software, they have to accept to the terms and conditions for using that software. This is standard practice for software in the IT industry and there are actually no big surprises here. However, on a VoIP phone that is not so popular yet.

Some vendors prefer to ship a EULA paper. In my opinion, that is a waste of resources. If they are hidden in a stack of other paper documents in the gift box, it also does not help to make the situation more transparent.

The snom m9 is a product that is heavily geared towards software. Most of the value that comes with the device is software, and so it is logical that the software rules also apply to the device. However, it is still a little bit unusual to have to accept a license agreement on the first login.

There are examples of modern devices that do the same thing. For example, when you purchase an Apple device, you have to go through the various steps of setting the device up. This includes the acceptance of the end user license. The good news about accepting the EULA is that you are actually officially allowed to use the software. I was always wondering if someone would be allowed to use it without a license agreement.

It does not only allow the customer to use the software; it also makes clear under what circumstances that is allowed. For example, it would not okay to use the snom m9 software or some parts of it on a “clone” device (if that would ever become available). I think that is quite understandable: snom does not program all that stuff so that competitors purchases one device with legal software on it and then copy it onto their own platform. The EULA makes that clear.

The other thing is that the snom m9 does from time to time reach out into the Internet to check for provisioning data or to tell the snom server, what software versions are running on the device itself and on the registered servers. While the central provisioning (snom Active) has obviously the advantage that you can plug a device into the network without touching and if its configuration data, the reporting of software versions is important for making decisions where to focus development on. Many vendors don’t even mention that in their EULA, the snom m9 EULA clarifies that as well.

Other topics in the EULA circle around the standard lawyer topics warranty and liability. The warranty deals only with the software part (who can claim to have bug free software?), the hardware warranty is a different topic and depends on the country where the device was actually purchased. The liability part is a necessity in today’s business life to make sure than small glitches in the software do not end up in huge payments for the company. If you are running a company yourself, you will know the topic. Then there are other parts which you find in all EULA that discourage people from selling the product into countries where they should not be. Although it is hard to imagine for me how you would turn an m9 into a missile, from a legal point of view, it is better to have that covered in the EULA as well.

The acceptance of the EULA might seem to be another bureaucratic move. However in today’s business life it has become a necessity and the good news is that it is in electronic form: no trees needed to be chopped down to make it happen.