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.