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.