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.