Happy New Year 2012!

Time is racing, especially in the IT industry. 2011 was what it was, there were a lot of innovation but the overall economic environment wasn’t that great. Here are my predictions for 2012.

My first prediction is that the m9 will finally have a repeater that you can buy. Seems like the repeater had to go more than just the whole 9 nine yards and there are still eleven months to go in 2012. My hope is that it would not take so long.

My other prediction is that IPv6 will become a topic for VoIP. IPv6 had to go probably a hundred yards and back and forward and back again. But the pressure to move leave IPv4 behind is getting so big that people don’t have a choice any more. Check out http://ipv6.he.net/statistics, they have made some neat applications that show you the current picture. Hopefully people will realize that the m9 had IPv6 from day one and it is a great toy to try VoIP over IPv6.

Any my third prediction is that Microsoft Lync will take off on voice. I don’t know how many yards it did go, but for sure it was also a lot. When we started using it a couple of years ago (then known as LCS and OCS), there were many features missing to the degree of not being usable. Today, it is a different picture and people are realizing it. Certified or not, I am using my m9 on Lync every day and I am a happy user. Maybe the m9 even gets certified or tested or whatever the right description for that is. I am sure there are potentially more out there, and amid some dark projections for the business in 2012, I am sure that 2012 will be a good year for Lync and also for the snom m9.

I wish you all a happy new year 2012!

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.