A while back, John Todd from Digium, had posted an entry on the Digium blog web site, regarding how to be a successfull Asterisk consultant. While I completely agree with John’s views on the matter, from obtaining a dCAP certificate to the involvement with the community – there are a few points missing from that post, at least in my view. I will try to add some additional information here, in the hopes that it may help you build your business.

Point 1 – Stay Focused

Most of us Asterisk consultants come from diversified areas of expertise. Most of us are plain old IP sysadmins or network managers who got thrown into the Asterisk world due to a requirement – got hooked on it and simply continued onwards. Some of us are developers, some web oriented, some core oriented, but developers yet. The diversity of most Asterisk consultants skill set can easily side track them.

When I say side track, I don’t meant that they don’t know what they are doing, I mean – it’s easy to try and swallow more than they can chew at one time. For example, example a sysadmin turning into an Asterisk consultant, after installing over 200 Asterisk systems. Now, a customer comes to him and says: “Well, I’m gonna give you the work, but I want you to also take over the various IT management aspects of the system.” – If at this point you will say: “YES” you are more of less dooming your business. You are an Asterisk consultant, no matter how a talented IT sysadmin you are, going about and taking both roles on your self would render you in a situation where you, at some point, will be in a situation where you are handling an extreme IT condition at that customer, rendering completely incapable of rendering services to your other customers. Remember, stay focused on what you do, you won’t run into a situation where you will be forced to hurt a customer.

Point 2 – Earning more is sometimes loosing money

This point relates directly to the previous one. Let us imagine that I’m an Asterisk developer with a background of Web development. When confronted with a project that may include both Asterisk and Web Development – the most logical answer would be “YES” – however, web developers tend to forget that they are working autonomously. Most web developers are backed up by teams of graphic artists, database developers, database managers and IT managers. Thus, a web application is much more than the web logic involved with it. Are you an all encompassing developer, capable of cater to all aspects of a web development project and an Asterisk project? if you have your own in house DBA and other resources, you should be fine, however, if you don’t – at some point in the project – you will be forced to outsource the work to a 3rd party – thus, lowering your net income on the project. So, by taking such a project you believe you will be earning more money, while in fact, at the end of the project you may end up in debt to 3rd party sub-contractors you hired.

Point 3 – Be true with yourself

Always be true and honest with yourself and always ask yourself: “is this really a deal that will advance me? or may it actually set me back?” – failing to answer these two questions for every project you are about to take on will end up with some disappointment. Remember, you can fool all people some of the time, you can fool a few people all the time – can you can’t fool yourself! You are your own worse judge, jury and executioner. If you end up doing a project that doesn’t feel right for you, or something with the various aspects of the project troubles your no a moral ground, at some point in time, it will creep up on you and bite you back in the ass.

Point 4 – Use it, don’t abuse it

We all deal with various aspects of the Asterisk project, an Open Source project at its core. It’s very easy to become side tracked by large sums of money, in order to either violate a GPL code or doing something which is completely negated to the Open Source spirit or the Asterisk community. Sure, you will abuse Asterisk and/or other Open Source Asterisk related projects, however, at some point, it will be discovered and your name will be smudged. For example, if you integrate ViciDial to a customer, tell them it’s ViciDial and don’t change its logo to something else. Same applies to FreePBX, A2Billing or other Asterisk related packages – at some point your customer will find out you integrated Open Source – and you will be branded a cheat.

For example, 2 weeks ago I was at a call center, where one of Israel’s leading Asterisk integrator had built a dialer platform for the call center. The call center manager told me that they paid a sum of about 120,000 Israeli Shekels (approx 30,000$) for that dialer. I was really interested to see the product, while the only thing I saw was a “logo” modified “ViciDial” with a couple of hooks into FreePBX (that also had its logo changed to the company logo). The customer was sure he was getting a personalised job, while actually, the entire amount of work done can be amounted to about 12-16 hours of work. Ok, so the hardware costs about 8000USD – still, 22,000$ for installing and modifying two pages on ViciDial – you can’t say that is right – is it?

Conclusion

Always be true to yourself, to your customers and to the community – you’ll never loose.

Over the past 12 months, I’ve been heavily involved in the development of high-speed dialers. While many companies published a prolific number of automatic dialers (power, predictive, broadcast) – none of these companies ever announced there top speed dialing capability.

An so I ask myself: “What is the reason not to release these numbers publicly?” – interesting, isn’t it. So, I decided to experiment myself and see if I would release public numbers for my dialer. I’ve designed my dialer to be capable of generating upto 35 calls concurrently. My questions was this: “While the dialer is fully capable these numbers in a test scenario, will this number be reached in real life?”

So, I started experimenting with my code – doing a very simple test. I’ve installed my dialer on a Dual Quad Core system, 8GB RAM, and a RAID-1 array as the storage. Now, I’ve setup the system to generate up to 35 calls every second, allowing the server to sustain a total of 180 concurrent calls – 360 channels.

What happend was actually this: the dialer generated about 180 dials within a period of about 8 seconds, and then, simply waited till some of the calls completed in order to generate additional calls. Ok, that is understandable, however, what is the throughput of the dialer? So, I decided to do another test, I filled up my queue with a total of 50,000 records. In addition, I’ve arranged with my carrier to terminate the calls to on of their SigValue systems, to sustain the enormous number of inbounds. In addition, I asked them to perform a small measurement of the average call inits per second. I was shocked with the result!

While the dialer simply peaked upon startup, after 20 seconds of operations it started normalizing at around 6 call initiations per second. But how can that be? how can it be that a dialer capable of dialing 35 calls is slowed down to crawl? – the reason is simple, the latency imposed by the PSTN/VoIP network, the time it takes for the calls to terminate and the actual time the call is left on the air, while the dial happens. All these factors together had given me the notion that there is no practical top speed, as it is in direct relation to the demographics of the dialer operations.

Having said that, is it possible to devise a formula to calcualte this number on a per demographic basis? maybe on a per PSTN/VoIP carrier type? maybe a combination of the both? will a formula such as that will enable for the better creation of broadcast/predictive dialer? – no use dialing tons of number into a demographic that can’t handle it, while at the other side of the spectrum, what demographics will benifit from the utilization of an automated dialer?