The year of the hosted PBX

So I have Verizon FiOS at home for more than half a year now. For those who are not familiar with that offering: This is a triple-play solution with TV, Internet and phone which comes to my home over a fiber. TV works beautifully, we can enjoy video on demand and the phone includes a flat rate for domestic (US) calls.

The phone service comes “of course” in the form of a analog telephone line. That part is disappointing. So they dig a fiber to my home, all just to convert everything into analog and then back to digital (practically all phones are digital today anyway)? That’s stupid. Anyway, still understandable because my home has an analog telephone line in each room, and typical Verizon customers don’t like to rip this out of the wall and replace it with Ethernet. So do I. What I did was getting a cheap analog DECT handset and connected to the line in the basement. All the telephone lines are useless in my house. DECT goes through walls.

But of course that’s not all. Guess what, I also have a couple of m9 handsets in my house.

They are registered to various locations. Practically for all snom offices, I have a registration. Some of the registrations are even using Lync; others are using snom ONE. My home deployment even stands the “wife test”: She actually uses it. If I would count the minutes, I would actually say that she uses the m9 more than the analog DECT line. Number one on her telephone usage list is the cell phone, no surprises here.

Anyway, the surprising thing is that the voice quality for our VoIP at home service is out of question rock solid. I should have started measuring the QoS reports, but it feels like we never missed a single packet. FiOS has a large upload capacity (a few MBit per second), which is a problem in other installations where uploading data has only very limited bandwidth. I think that is the difference to the situation a few years ago. People were dreaming about hosted PBX, and the concept hade a lot of sense; but the bandwidth was simply not widely available. That has changed.as the Apple folks would say “the times, they are changing”.

Essentially I am a user of hosted PBX with the snom m9. It works great, and it makes a lot of sense. This is something people will find out this year.

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.