The m9r on Ringcentral

A cloud-based business phone system uses the Internet to deliver all the features of an on-premise PBX—minus the costly setup and the bulky hardware. And since the Internet isn't bound to a specific location, a cloud-based PBX seamlessly integrates multiple locations and remote employees.

RingCentral is one such popular cloud based phone system, designed to help small businesses manage mobile, fax, and email communications. Its products include RingCentral Office, RingCentral Mobile, and RingCentral Fax.

So, today's blog shows how we got the snom m9r up and running with the RingCentral Office™ service.

Set up your RingCentral account: 

1. If you don’t already have a RingCentral account, sign up with the service on their website. Add the number of lines and select No Device as your phone. 
2. If you already have an account, use your existing lines or add new lines from the RingCentral service site using Add DigitalLines as shown in the figure below. Select Use Existing Device when prompted to choose a phone.

Record configuration information from RingCentral:

1. After purchasing your lines, log in as an administrator and go to My Settings > DigitalLines. You’ll find a list of the lines you purchased.
2. Locate each line you wish to use with your cordless phone. Make sure the E911 column displays the word Edit.
3. Otherwise, click Failed and provide the e911 data.
4. Click Setup Instructions for each line you’ll be provisioning on your cordless phone. Copy each of the five fields shown in the figure below.

m9r Account Setup:

1. On the m9r web portal, click on Identity 1
2. From the Server Type drop down select RingCentral Office™
3. Set Identity active to on
4. Enter your RingCentral User name in the Account field
5. Enter sip.ringcentral.com in the Registrar field
6. Enter sip:sip.ringcentral.com:5090 in the Outbound Proxy field
7. Enter your RingCentral Authorization ID in the Authentication Name field
8. Enter the provided RingCentral password in the Password field
9. Press Save to apply settings

DTMF Payload Setup:

1. Click on the Audio tab at the top
2. In the DTMF Payload Type field, change the default value to 101
3. Press Save to apply changes

Handset Assignment:

1. Click on the Handsets tab
2. Select all handset IPEIs that you want to be associated with your RingCentral account
3. Press Save to apply changes

Verify Registration:

1. Click on Status > Registration
2. Ensure that your configured account display 200 ok indicating a successful registration with the RingCentral Office™ service
3. Congratulations!! You are now ready to use the snom m9r with the RingCentral Office™ service

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.

The handset weight

You might that the weight of the handset is a simple topic. It is not. There are two groups that can just not be made happy with the same device.

Group number one believes that a handset should be as light as possible. This is because they don’t like to hold a heavy brick in their hands for too long. Exercise is a topic for the gym, and not everyone finds massive shoulder muscles attractive—especially on women.

The other group wants value, and from a psychological point of view it is understandable that more weight of a handset suggests there is more value inside. If it feels heavy, it must be good. Also it sounds much more massive when it drops on the floor.

Let’s take a look at the reasons behind the handset weight.

A cordless handset must pass a test called the “drop test”. We know that from the crash test for cars: If you want to sell a car it has to pass it. When the handset falls on the floor, it must not break. It is okay if it opens, as long as the user can still put it together. But plastic breaking off is not okay. The drop test is easier to pass if the device if the device is not so heavy, especially on inside components that don’t actually contribute to stability. A heavy battery can be a major problem for the drop test. What manufacturers do is to make certain parts like snap-ins stronger until it can pass the drop test. As a general rule, a lighter handset makes the drop test easier.

Weight generally speaking costs money. For example, devices have to be shipped from the factory into the warehouse, though that is not a major factor. Other cost factors are the plastic prices, which are also not a big point. We can say that more weight does mean more value, but not much.

A heavy battery is an important factor in Wifi phones, so that they can actually survive the day in the world of MB/s. DECT phones are much less power hungry, and even a cheap battery with a weight of an ounce can survive a week without seeing the charging station. It is technically no big problem to make a light DECT handset with a battery strong enough.

With the decision from Apple to make cell phones out of full metal, it has not become easier to convince people that light handsets are the way to go. I believe this is unfortunate. From a pure functional point of view, a paper-weight device would have been much “cooler” that a heavy device. My advice for the proponents for heavy handsets is to change the side regularly, so that both shoulder muscles end up with the same size. As for the m9, snom could resist to follow that trend and focus on the functionality aspect of the handset, where lighter is just better.

The memory monitor

Memory in embedded systems is a limited resource. The m9 has just 16 MB RAM on the base station, and even the upcoming m9r has only 32 MB RAM. That used to be a lot in the 1990s, but today this is almost nothing. Because of this, the design of the m9 had to keep the memory usage in mind. After the motto “what you see is what you get” the m9 has a memory monitor that checks the memory usage of the last 24 hours.

But what is free memory? That is a little bit hard to say in the Linux environment, because the operating system tends to keep things in memory that are not actually needed. In order to speed up later loading, this makes sense. But for the accurate measurement of how much memory is exactly free, the number might be misleading. The m9 reads every 6 minutes the file /proc/meminfo from the operating system, and then stores the number which is in the “MemFree” line. You get a picture like this:

As you can see, the memory is not a one-way street down to zero. The operating system sometimes frees some memory too, and then the graph jumps up again. However, when the graph gets into the area where only a few hundred KB are available, things get tight. This might happen if you have a busy system, and for example all accounts use Microsoft Lync registrations. Well there is a reason why the m9r has more memory.

Anyway if the m9 should really run out of memory, it does some desperate measures. It actually writes a file with some booting information, so that on the next reboot you can see on the status screen why the device was rebooted. After the writing of the file, it does reboot. This is ugly, however just hanging there doing nothing would be even worse.

Once that the system is running, the probability that the system is running out of memory is relatively low. Most of the memory is taken during the provisioning and registration phase and after making the first couple of calls. After that, the device has only a few reasons to allocate more memory. The goal with the m9 and with every other embedded device is that it should be running forever without ever running out of memory. The biggest practical obstacle for this is the software update. Unfortunately, updating software that is actually running is very difficult and as with the most embedded systems, the m9 requires a reboot after a software upgrade.

Voice over TCP

In the last blog, I was talking about SIP and TCP and it would have been a great idea to use TCP as the default transport layer for SIP. When it comes to media, TCP has some disadvantages.

The overall problem is delay. Voice is an application where you want as little delay as possible. The only other application that I can think of is online shooter games, where you literally need a low latency to survive against your online enemies. If you are behind a slow DSL line, you’ll probably get shot down before you can even see what is going on.

With voice you won’t get shot down, but the conversation gets bad when the delay is too long. The first obvious problem is that both parties start talking all the time, which makes a conversation very unnatural. The other big problem is that there is still some small echo coming back mostly from the handset cord from the other side. Even if it is very low, if you have a long delay, you can hear it and it feels uncomfortable. So with voice, you want as little delay as possible. 40 ms delay is great, 80 ms gets to the limit already.

The problem with TCP is that when packets get lost, the TCP subsystem has to repeat the last packet and that might take a long time. On the other side, when the packet finally arrives, the audio buffer has already an under run and it is better to just drop the packet and play the next one immediately. That is why it is better to use UDP for audio.

Video might actually be a different story. Packet loss for video is a much bigger problem than for audio. Because of the high compression for video, a lot packet really screws the screen up. For video it would make sense to use TCP transport layer even when there is a risk of packet loss.

All that said, there is still an increasing demand to use TCP for voice as well. The problem is that in many environments, the firewall blocks UDP traffic. This is either because the firewall is not able to support too many UDP sessions, but maybe it is because the firewall should actually block voice traffic (for example in the hotel). Then TCP might still be a possibility. The price is an increased average delay, but if you have the choice between a conversation with a long delay and no conversation, you might choose the long delay.

The support for that is still weak (so far only in Microsoft Lync environments as far as I know). However as more and more environments support it, your m9 might eventually pick TCP transport layer for voice eventually.

SIP, UDP and NAT

Writing about SIP and NAT could fill another blog. This problem was neglected in the SIP standard. Maybe this was done to push the need for IPv6; however for sure whoever had this idea did not make our life easier over the last ten years. NAT remains a major pain in the neck for the whole VoIP world.

For those who don’t know NAT: This is “network address translation” and it deals with problem that there are less IPv4 addresses in the world than there are telephone numbers in the USA. The trick is to abuse the port numbers for addressing purposes. Essentially what it does is to put 16 bit behind the 32 bit IPv4 address, so that we have 48 bits for addressing a service in the Internet. That is the same number of bits that we have for Ethernet addresses, where so far that number was sufficient. That trick worked well enough to keep the service providers upgrade to IPv6.

The other major problem in SIP was that it mandated the support for the UDP transport protocol. This is not only a pain in the neck for the poor programmers who have to deal with message repetition all the time (and which may explain the poor code quality found in many products). This is also a problem for the message size. Try to send a UDP packet with more than 1500 bytes; you will get a lot of “funny” effects. This is called UDP fragmentation. The problem behind it is that the packet cannot be sent in one packet over the network, so it has to be split and reassembled on the other side. While the splitting up usually works, most of the cheap routers available in the real world don’t reassemble the packets and even many SIP devices are not able to do the same job. In other words: If you have a very long name and you name is included in the SIP packet, your phone will probably not ring. Okay, most people don’t have names with 1000 characters; however with the advance of SIP there are so many extensions that make the packet longer. And you end up with packets that don’t make it through NAT. Nice.

Life could have been so easy. All that the SIP authors should have done would be to use TCP transport layer. Then on the signaling side we would not have fragmentation problems and even NAT would work without major glitches. The argument that servers don’t scale well with TCP is frankly from another world, looking at HTTP and Email traffic today (all on TCP).

The m9 supports UDP (including fragmentation, thanks to Linux), TCP and TLS. Whenever you can, my suggestion is to use TCP or TLS to minimize the trouble with NAT. Especially when operating the m9 behind a cheap router. Luckily, most SIP server software today supports TCP. Some of them even don’t support UDP any more (like Microsoft Lync), which is good news.

For the media side, even if SIP would have used only TCP, NAT would have always been a problem. For media, you want short delays. That means you want to send the packet directly between the devices if possible. And that means you have to use UDP. So even if your signaling is working okay, you would still have to fear that your voice connection would not make it. There is a solution for that called ICE, but that is a topic for another long blog post.

Where is my handset?!

Mobility is a feature, but it can also be a problem. Where did I put the handset? Because the handset does not have a cord to the base station, it is easy to displace it. The m9 has a couple of features to locate the handset.

The first one you might have seen in the web interface. There is a button called “locate handsets”. What this button does it to call all registered handsets. So if still both of your ears work properly, you will be able to figure out where your handsets are (an amazing feature of the brain to locate audio sources in the room).The problem with this procedure is that it is quite disturbing, especially at night. If you belong to those who use the m9 at home, you want another way to locate your handset in the dark.

The answer is that the handsets shortly turns the handset key backlight on, so that you can see it.

This can be disturbing. The answer to that problem is to just put you handset down with the keyboard to the table, and then the visual disturbance should be minimized. You can also turn the blinking off from the handset menu. I believe there was a bug in the old versions; hopefully it was fixed in the meantime.

It is debatable what should be the default. Apart from the visual disturbance, it actually does suck battery power. Right now the default is to it on. I assume that is a kind of feature advertisement. For those who don’t need it, it is probably a good idea to turn it off.

The other way to locate your specific handset is to just call it from another phone.

What’s a link-local URL?!

IPv6 is still pretty much unknown in the IT world. When m9 customers log into the web interface and navigate on the status screen, they are stumbling upon a thing called the “IPv6 Link-Local URL”.

Generally speaking, link-local means that the address is only visible on the link, which means something like “interface” or “LAN”. For example, if your device would have to Ethernet ports, you could have two links, and you could actually have the same link local address on each of the links. It would not generate an IP address conflict, because the LAN will not route packets that are link local. While you usually have different MAC addresses for each physical interface, this case will be rather improbable. However, when VLANs are coming into the game, it is actual quiet probably that you will have the same link-local address twice on the device—one time for the regular LAN and another time for the VLAN. Hint: This will still not happen with the m9, because when a VLAN is used, the whole device will move into that VLAN.

Link-local addresses can actually also happen on IPv4. Those addresses use those 169.254.x.x addresses that you might have found on your computer when the DHCP server was not responding. They are not as popular as they are on IPv6. In IPv6 you actually need link-local addresses to get a “real” IPv6 address. DHCPv6 uses the link-local address in order to grab more IPv6 addresses.

We put the link-local IPv6 address on the status screen for two reasons. First of all, we want to let everybody know, that the device has an IPv6 address and they can try this out just by clicking on the link. The other thing is that this address does not change—it depends on the MAC address, so it is pretty constant. That means if you store the link, you can always log into the device without having to know what the IPv4 address is or even without having an IPv4 address. We even wanted to print the link-local URL on the label on the bottom of the base station, so that people can just enter that link to access the device.

Generally speaking, in IPv6 it is absolutely normal to have more than one IP address. Apart from the link local addresses, IPv6 routers may send advertisements around (called RA—router advertisements) which announce subnets. The device may grab an address in the subnet and use it, without the involvement of a central server like a DHCP server. This is called stateless configuration. The problem with the stateless configuration is that is does not include a DNS server, which is also pretty important in IPv6 (who wants to enter those long IP addresses). That’s when the m9 sends out the DNS requests to a special DNS multicast address, called “all link local DNS servers”. Then when someone answers, it tries to stick to it.

The m9 always tries to grab another IP address from a DHCPv6 server. As stated before, DHCPv6 is quite different from DHCPv4, especially the fact that is was designed for multiple (redundant) DHCPv6 servers in the local link (this should make sure that the network is very robust when server should go down). At the end of the DHCPv6 process, there is still an IP address—an IPv6 address.

If you have IPv6 RA or DHCPv6, you would find the additional addresses also on the status screen right below the link local address. If you want to get more information about the IPv6 configuration on your m9, you can still use the Diagnostics screen, for example to probe the /proc/net/if_inet6 file.

The M9R

Soon the m9r will hit the market. This is not just a regular internal product update, which is quite common in the IT industry and usually invisible to the user, the letter “r” suggests that it is more than that.

First of all, the letter probably stands for “range”. The m9 handset uses a new chip set which has an improved antenna performance. That means the range will be improved. Though the majority of customers will not really need this, it addresses those who are on the edge.

The other thing is that it will support the “repeater”. Even with the improved range, you can still double the distance by using a repeater in large offices and warehouses. Though I honestly think that the good old m9 also supports the router. Maybe the m9r is because the router is so close, we can already smell it.

Then there is more memory (which also has the “r” in it). More memory is always good to have, though the software does not need it at this point. But you never know what future software updates bring, and it never hurts to have more memory. Especially the handset has more memory; we were always very tight with memory there. Try to program something with a color display if all you have is 64 KB RAM. I believe now it is 128, still not the same of what you have on your smart phone, but at least twice as much as before. And also the base has now 32 MB RAM, so that we can probably take it easier with adding memory hungry features.

The other reason for the letting is the improved speaker (the letter at the end). This results in a better handsfree mode and a better playback for the ring tone.

Another thing that was changed is that the combo now has only one handset. This is sad because most people won’t realize they can register more than one handset per station. I guess the overall marketing rationale behind it was to get the overall price down. People can be very short-sighted when comparing prices.

The m9r continues exactly from where the m9 was. Regarding the maturity of the product this time it means there will be no big surprises. So the bottom line is that the m9r is a hardware upgrade, not a software upgrade.

Hosted plug and play

Today I have a business idea.

When I bought a Kindle from Amazon, I was pleasantly surprised that I did not have to set anything up. The only thing I needed to tell the device was the password for my Wi-Fi access point (it would have been scary if that step was also not necessary any more). But apart from that, take it out of the box, it was already charged, and as soon as the Wi-Fi password was on the device, I was ready to do my first purchase. Okay, go figure why this device cost only 199 USD.

Anyway, why don’t we do the same thing with the m9? Broadband is available widely, and all it would take would be someone who gets access to snom Active and sell the m9 on Amazon. After scanning the MAC address, all that would be necessary to set up a DID for the device, enter the according provisioning data into snom Active, maybe perform a test run to make sure everything is all right, and put the device into the hands of the parcel-service-of-your-choice. Even people who don’t know what VoIP is would be able to use this device as a telephone.

It does not even have to be a real DID. For example, callcentric offers “virtual” DID numbers that cannot be dialed from the PSTN. This reduces costs for the service and makes it possible to just try the service out. Customers are still able to call each other on the network. This could make sense for people who have parents in far-away countries.

Ideally, the person who sells the m9 would already have the customer’s credit card number, so that recurring revenues AKA telephone charges could be charged every month. There are a lot of service providers that could do that. This would address a different customer base that the people who are using a softphone on their PC or smart phone. Think about grandma.

Why power over Ethernet makes sense

Imagine a world where every country would have its own Ethernet connector. In this world mean that every switch would have a version for each country, possibly its own pin assignment, maybe even different speeds for the data. Vendors would have to produce for each country, keep inventory for each country and possibly also get certified with the Ethernet watch for each country. There are some people who see positive things with this, but at the end of the day it would mean that mediocre companies could lock competition out and I just can’t spot anything positive in this.

This world is a reality in the world of power plugs. There are plug for the USA, for Australia, for the UK, for Germany, for Switzerland, for France, and possibly even more countries in the world and they are all incompatible. Isn’t that crazy? I guess the standards were done at times when politicians thought that locking down their country would be a good thing.

There are other areas today where the industry purposefully introduced such country specific localization. Remember the last time you bought a DVD on your trip to far-away-country and wanted to play it back at home. Didn’t work! The DVD companies don’t like it when you purchase your DVD in China and play in back in Germany. This happened even without politicians I believe. It was just a way to maximize the turnover with countries where people are willing to pay more and countries where people on average are willing to pay only less.

What does that all have to do with the m9? There are two things here as well.

The first is the power plug. The m9 also has to deal with the problem that different regions have different power plugs. So far we have three regions: USA, Australia and the rest of the world. For USA, the m9 comes with the two-bar power plug that we all know. Australia comes with the old UK-style power plug (also known from your last trip to Hong Kong) and some special certifications if you want to sell the device in Australia (like the lower ring tone). The rest of the world comes with a number of plugs that you can use in your specific country. snom also uses this to differentiate the price (like everyone in this industry does). So next time when you buy an m9 in the USA, don’t be surprised if it does not fit into the power plug in Europe.

The second thing is the frequency. USA could not allocate the same spectrum like most of the other countries. I am not sure if that was really a technical problem, or the USA wanted to make sure that there would be a different price level possible in the USA area. Anyway, that’s why there are two versions of the m9 handset today. snom had no choice, just follow the industry.

What happened in the cell phone industry might also soon happen in the VoIP world. Like practically all cell phones today use USB for charging the device, vendors will stop sullying power supplies and instead point to Power over Ethernet. This will make the global supply easier; actually it will enforce more global competition, it will be more difficult to lock devices to a specific region, and at the end of the day customers will benefit from a global standard with a huge volume behind it.

PoE can not only be used for powering DECT base stations, it can actually be used for a lot more devices. I think they are working on powering laptops on PoE, of course desktop phones and video camers. But even things like LED lights start to use PoE. When you build a new house, consider running an CAT5 cable to the ceiling instead of a regular power cable. It might all help to get the volume up and the prices down.

I was personally never a fan of PoE. But thinking about it, I might actually become a fan these days.

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!