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.