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.