I am constantly monitoring our Help Desk tickets. I am looking for improvement ideas, common mistakes (for example if many people make the same mistake, we must change something in the product) and generally anything that can improve our products and services.

That’s why I was able to discover some surprising things, one of the most important in my perspective being related to our customer’s education related to production systems management. I will discuss about VoipNow, because it’s more complex, but everything below can be considered best practice (in my opinion, of course).

Is VoipNow Hard to Manage?

If you follow some basic rules, no. But otherwise it might turn into a nightmare. Unlike a typical hosting system, VoipNow is more complex because it interacts with more third parties. Due to the real-time nature of voice communications, it’s also affected by network conditions.

A VoipNow system interacts with SIP phones and with SIP carriers. Overall, SIP is a mature, standardized protocol, but there are lots of standards that cover it. Some of these standards are in a “proposed” state, which means that they will change in the future, before adoption (if they are ever adopted).

Recommend Phones!

Due to this situation, phones usually implement basic features in the same way, but there are some differences with more complicated features.

Lesson number one: Try to recommend only two, three phones to your customers (maybe from the same vendor — entry level, medium and high-end). Test all features of these phones with VoipNow and make sure that you know how to support them.

Careful with carriers!

Because it’s easy to enter into this market, there are lots of guys that get an Asterisk server, some SIP trunking reseller accounts and offer origination/termination. No serious carrier will use Asterisk for SIP trunking services. Asterisk is a PBX, not a product designed for this purpose. To make it easier to understand, if someone wants to bring down your provider, it can do it in several seconds with a clever DOS attack.
How to identify such “carriers”? First check if they offer IAX. If they do, then things are quite clear, avoid them. Also you can check the SIP agent in SIP packages (not bulletproof, can be changed). And of course, you can simply ask.

Second lesson learned: Take care when you choose your providers, otherwise you will have extreme problems starting like strange SIP that translate to call drops, no audio, etc.

Pay attention to your customer’s infrastructure

Sometimes, your customers call you claiming poor voice quality, impossibility to place calls or no incoming calls. You will notice that some customers call you very often, while others don’t call you at all. The problem is not the server and usually not even the setup of the phones, but the router used by your customers. Many providers make a huge mistake: they simply ping the customer’s IP address and find out that it’s OK. Well, any router will answer fast to ICMP packages on the external interface, but this does not mean that it will pass packages between the internal and external interface as fast. There are two problems about cheap routers: their processor resources cannot sustain the packet flow, meaning that some packages are delayed with hundreds of milliseconds. Even if this happens only for 5% of packages, it’s enough for voice to sound like hell. The second issue is about memory, to do NAT translation routers maintain an internal translation table. Because they deal with UDP (which is connectionless) protocol for SIP signaling, the timeout on the table entries is quite high. When the customer has several phones and some other applications in the internal network that access Internet, this table rapidly fills up. With a full NAT translation table, most likely phones will not work ok.

Third lesson learned: If your customer is using NAT, things get a little more complicated. It does not mean that they will have to get a very expensive router, but they should purchase something decent, according to the size of their company. Of course, problems might also occur due to the customer’s Internet connection, but this is usually less likely.

Don’t push new VoipNow versions in production without testing!

Any serious provider must have a test bed. This might be a low cost virtual machine where he must install all new software versions before upgrading the production machines. It’s required due to many reasons. First, with each release we fix bugs and wrong system behavior. If you relayed on a behavior that was changed, your customers would be affected. We document all changes in the release notes. Always read the release notes. If you did not understand something, you can simply ask support. Secondly, we fix SIP issues. We regularly discover scenarios when VoipNow was not fully compliant with SIP standards. As we fix such issues, problems might appear with providers that are not 100% by the book. You should test the new release with your providers! And thirdly, we might introduce issues. This is not exactly our dream, but it happens.

Lesson number four: Always use a test bed to test new releases before upgrading. This guarantees that you do not expose your customers to trouble.

Schedule your production server upgrades

Even if you perform the upgrade on your own, you can schedule your production server upgrades with our support. This basically insures that we are available when you want to upgrade. This is particularly important for our default SUS support plan, which is not 24/7. The SUS plan has a 24 hours answer guarantee, which might be too much. The average response time on SUS is around 4 hours, but after releases this time increases as we get many more tickets and support is operating on its limits. Of course, it will not help at all to open a ticket like “Help, emergency, my server is not working. Just upgraded!”, because it looks like you haven’t followed step four.

Lesson number five: Schedule the upgrades when your production system is less used and make sure that support is available when you upgrade your critical servers.

Backup, backup, backup

It’s surprising that so many providers do not care about backups. I am not talking about disaster recovery that involves carefully managed plans. I am referring to simple backups. VoipNow includes a backup function. Remember, if you backup on the same machine, the backup might be useless. Always backup to a remote machine and ideally save backups on another location also. Without a backup you expose your entire business because you are not able to recover even from simple events, like a HDD failure (always use RAID, BTW). I don’t think that you will get many sign-ups if you put on your website a big logo “No backups”.

Lesson number six: Be paranoid about backups. Without backups you cannot be called a service provider.

Make your Help Desk support tickets meaningful

If you do not fill in your public server IP, your license key and you fail to describe the exact issue with replication steps, known history and relevant traces, it will take a longer time for your ticket to be addressed. Many people report things like “My server does not work. Help, I lost a few customers!” When the engineer looks at the ticket, he will start by asking more questions and precious time is lost. So you will lose even more customers. Such tickets are extremely frustrating for our people too, just imagine a highly trained guy spending 30% of his time just babysitting, rather than solving problems. Also, don’t abuse the ticket emergency level. I have seen cases when for a simple question someone assigned a Critical level. When our support people see this, they are instructed to change the ticket’s emergency level to Lowest. It’s not a disrespectful attitude; just imagine that when you have a true life and death issue, someone is spending the time handling an inquiry about how to access voicemail.

Lesson number seven: Don’t expect someone to know your server or ticket history. If you refer to something in the past, specify the event exactly. This way you escalate your ticket’s priority!

Use VoipNow for what it was designed

VoipNow Professional is a Unified Communications system designed to offer rich services to customers. It is not a SIP trunking product. Even in these circumstances, many of our customers use it to deliver SIP trunking services. They still offer a more robust service than providers that use an Asterisk server because the SIP server in VoipNow can handle many thousands SIP messages per second, but still we do not recommend this. In order to satisfy these demands, we will introduce in the next month a product designed for SIP trunking, able to scale to any number of calls per second you wish. Of course, it’s taking advantage of 4Grid. You can build your entire SIP infrastructure on it and it is a complement to VoipNow Professional.

Lesson number eight: Use the right product for the job. We will never satisfy feature requests that shift VoipNow’s focus.

I hope that you found it useful. Do you have ideas for other articles like this? What do you think it will help you? Don’t hesitate to comment. 🙂