A common source of echo in VoIP phone systems is the telephone handsets. Of course, non-VoIP phone systems have this source of echo too, but it often is not so evident because without the buffering the echo delay is not as long.

Old Bell 500 series telephones have a wad of cotton wool in the handset to prevent sound from traveling from the receiver, through the hollow handset body, to the transmitter.

But, many modern telephone handsets lack this important component. Here I show how I added cotton wool to the handset of a Linksys SPA-841 in order to reduce echo.

	Here is a typical SIP telephone, a Linksys SPA-841. It is not a bad phone, but there is a noticable echo.
	In order to add cotton wool, we must first open the handset. Notice the small foam-rubber plug in the centre. This plug conceals a screw.
	The plug should be gently removed using tweezers or needle-nose pliers. Once it is out, the screw can be removed.
	Even with the plug out, the two halves of the handset are held together with clips. Take a dull knife and gently pry them apart.
	Now that the handset is open, we see that there is no cotton whool. The piece of steel in the center is to give the handset more weight. Otherwise it would tend to slip out of the hand easily and would give the impression of poor quality.
	Here we have packed cotton whool around the transmitter and receiver. All that is left to do is reasemble the handset. If the clips broke when you pried it apart, a small drop of glue may be in order.

Since I modified my telephone in this way, it seems to have noticably less echo.

I have tried to modify other telephones in this way, but so far without success. I can find now screw and attempts to pry the two halves apart are unavailing. If you have suggestions about how common handsets can be opened, please put them in the comments section.

How to be a Good VoIP Provider for Asterisk Users

There is more to being a good VoIP telephony provider for Asterisk users than simply offering the best balance of price and reliability. Usability is also very important.

Provide a Simple Dialplan

It is all right to allow your users to dial numbers in a variety of ways, perhaps to conform to local practice in your target market. But make sure to allow your customers to dial numbers in full international format, starting with the country code, if they so choose. I suggest you follow the European Union practice and designate 00 as the prefix to indicate that the number will be dialed in international format.

This is important because otherwise your users will have to program Asterisk to divide numbers into classes and select the appropriate prefixes. Lets take Vitelity's dial plan as an example. Vitelity expects calls to the USA and Canada to be dialed as 10 digits, starting with the area code. (You can dial 1 first if you like.) But calls to other countries, including countries in the North American Number Plan must be dialed with a prefix of 011. So, a call to Jamaica, which would normally be dialed from the USA as 1-876-555-1212 must be dialed 011-1-876-555-1212. This means that we must give Asterisk a list of about two dozen NANP area codes which require special treatment.

Most European providers does this. Voip.ms does this too.

Allow us to Disable Recorded Fault Messages

Asterisk users frequently have several providers for outgoing calls so that if one fails or your account with it is out of money Asterisk can roll over to the next. They do this to improve reliability and to get better rates.

A common cause of failure is running out of funds. If you play an "you are out of funds" message, the caller will most likely hang up even though, had he waited, Asterisk might move on to another provider. You should simply reject the call with an appropriate error code.

Of course, such messages are helpful to those customers who are using your service directly from an ATA, but there should be a clearly explained way to turn them off, perhaps by indicating whether one is using an ATA or a PBX.

Whether or not you play a message, never, ever answer a call which you do not intend to put through. If you must play a message, play it as early audio.

The same goes for other problems which would provoke a recorded fault message. Don't play messages for all-routes-busy, cannot-be-completed-as-dialed or any other condition where another provider may be able to put the call through. True, you will make no money all the call, but you reduce the chance that the Asterisk administrator will cut you out of the route.

Provide Machine Readable Rate Tables

Many Asterisk users want to know exactly how much their calls will cost so that they can do least-cost routing. While web pages which give rates for such things as "Peru Landlines" or "UK Mobiles" are fine as an advertisement, a computer cannot take a phone number and automatically find the corresponding rate.

You should provide a rate table which lists your rates by prefix. By convention the longest match wins, so you can list a rate for a whole country or other region and then list longer prefixes begining with the same digits for those blocks which have other rates. For example:

1 1.05 ; United States
1808 1.46 ; United States - Hawaii
1907 1.25 ; United States Alaska

But, be sure your switch rejects the call gracefully, without playing any messages, for any 'holes' in your coverage.

Finally, make sure that your rate table can be downloaded by fetching a single URL. Customers hate having to write programs to scrape your website.

Let DID's Work Without Registration

For most customers using SIP phones directly with your service, periodic registration is the best way for them to inform you of their current IP address. However, Asterisk switches frequently have fixed IP addresses and DNS names. So, let your customers specify a SIP or IAX2 address to which to send the calls. This eliminates the constant chatter of registrations. When there are no calls there is no load on your network and servers and no load on ours.

For an example of a provider that does this well, take a look at how voip-user.org has users configure their second and subsequent incoming numbers. Call With Us allows this to, though they do not explain how to do it.

Make it Easy to Check One's Balance

Your Asterisk-using customers are quite likely to want to check their balances automatically and gather all of their provider balances into one place. Make it easy for them to do so. Provide a way for them to do this with a single URL fetch.

Voicepulse for Asterisk and Call With Us do this well. Most other providers make you scrape their websites in order to determine your balance automatically

Treat Customer Suggestions as Free Labour

If your service is weak in some of these areas, knowledgeable customers may point it out to you. Train your staff to recognize these customers and forward their suggestions to your system administrators for consideration. While it may cost more to fix the problem than you will ever make from that customer, a more usable service will help you to attract additional customers.

Is open source telephony a serious option?

I was recently asked whether anyone would every really consider replacing a tired old PBX with an open source system and whether we had any experience with Asterisk. Here is the answer I wrote, based on our experience here at a small college in New England:

The design of all VoIP systems is much newer than that of your "tired old PBX". No matter what you pick to replace it, it will probably will not be as reliable as your old PBX. (I am assuming that you want to replace your PBX because of its limitations rather than because it is failing.) Why might a new IP PBX be less reliable?

In my limited experience, traditional, expensive PBXs work reliably not because of superb design and quality control but because they have been around long enough that all of the bugs which cause major malfunctions during typical use have been patched. Hundreds of other bugs, many of which require obscure work-arounds remain. A traditional PBX may supposedly have lots of advanced features which are never implemented because the bugs stop one in one's tracks.

The design of a traditional PBX is also staggeringly conservative. The management interface on a Northern Telecom Meridian I is a throwback to mediocre 1970's design. There is no cursor movement, no menues to scroll through, to configuration screens to open. It is many times more primative than the Unix or MS-Windows command-line interface which so many dread. There is no user-accessible file system and no provision for uploading data. The few commands that are available spawn endless questionnaires with prompts consisting solely of obscure acronyms and abbreviations with no way to backtrack to change an answer. Mass data loading invariably requires the writing of scripts which run on a personal computer. There scripts connect to the telephone switch and pretend to be a human being running the crude interface through its paces at high speed. Of course, this is many times easier than tracing wires and connecting resisters to change programming, but by modern standards it is painful.

In contrast, IP PBX's are based on modern computing experience. Configurations can be generated from databases or edited using web interfaces. Dozens of useful features which hardly anyone had the energy or nerve to set up on traditional PBX's can be set up easily. Bugs get fixed. New features get added. But this comes at the price of sometimes destabilizing the core function of ringing telephones and transmitting sound. In other words, switching to an IP PBX brings many of the same problems as switching from a mini computer to personal computers brought.

You ask if you should trust something as important as your telephone system to open source. I think first I should clear up a possible misconception. The fact that open source telephony software is free does not mean that it is of low quality or that it was written by amateurs. Quite the opposite. The authors of large, successful open source projects tend to be or to become the outstanding experts in their fields. They invariably care deeply about the quality of the product. Nor are they amateurs with limited resources. They are often the employees of hardware manufacturers and telephone companies. Their employers are willing to give their work away for free because for them software is simply a nuisance. If they share the enormous effort require to write it, they can more quickly get back to the business or selling hardware or telephone calls.

This does not mean that you can simply take the last thing that the Asterisk developers released, install it, and be happy. They are not telephone system vendors. They will not set it up for you or fix it when it breaks. They provide one of the components needed to build a telephone system much like auto-parts manufacturers build alternators, bearings, and engines.

What you need is a complete VoIP phone system. This system might use Asterisk as one of its components. It will almost certainly have some open source components. An IP PBX of any size requires expert setup and maintenance. It is the expert selection and proper interconnection of components that makes any PBX work, not the origin of the components.

You ask about our experience with Asterisk. Asterisk is in limited trial here. We have connected a server running Asterisk to our pre-existing Northern Telecom Meridian 1 using two bridged T1 lines. The Meridian 1 sees it as an outgoing toll trunk. Problems with Asterisk have been very few. Connecting Asterisk to the Meridian 1 with all the PRI function we wanted working was extremely difficult even with the help of experienced consultants.

Using this setup we have considerably reduced our expensive for oversees calling. We intend to explore other applications for Asterisk including replacing our aging voice mail system.

If you would like to talk to somebody about a full-blow Asterisk installation, you might try contacting the IT department of Manchester, Connecticut. I have hard that they recently installed an Asterisk telephone system with about 150 sets in city offices. The request for bid (found at http://lists.digium.com/pipermail/asterisk-biz/2004-October/000807.html) contains the contact information for their CIO.

Finally, I should point out that Asterisk is by no means the only open source VoIP building block. It is simply the most well-known. There are a number of well-regarded components, such as OpenSER which are frequently used instead of or in combination with Asterisk. It is also quite common to use open source components in combination with other non-open source components.

Join the DUNDi cloud, call Europe!

Do you have an Asterisk box and an underutilized T1? Or do you have a large number of DID numbers on your PBX? Why not join a DUNDi cloud and trade access to your numbers or to your local calling area for access to other organizations' numbers and local calling areas?

DUNDi is a protocol which allows Asterisk servers to share information about to numbers to which each can route calls. Forum postings suggest that DUNDi is fairly widely used between PBXs within single organizations. But it is hard to find organizations interested in using DUNDi for toll bypass. One can find many references to a DUNDi-Test network, but requests to join go unanswered.

One person who was frustrated by this situation is Anthony Messina of Messinet Secure Services. He decided to organize a new DUNDi cloud for PSTN access. This cloud has grown from two or three nodes a year ago to about 30 now.

Looking at the CDR from a medium-sized PBX which tries to route calls through this DUNDi cloud before trying other means, I see that it has handled calls to Illinois, Pennsylvania, Georgia (USA), Hawaii, Italy, France, Germany, and UK. Of course, the cloud does not provide complete coverage of any of these areas, but in the last 10 months this PBX still had managed to route out almost 5000 minutes over DUNDi! This is even more amazing when one considers that at the start of this period the cloud was quite small.

What to start sharing? Visit http://messinet.com/project/dundi and find yourself a peer.

My VoIP network

I run a VoIP network for my friends and family. There are phones at about 10 locations. Four of the locations have Asterisk servers.

Three of the Asterisk servers are run in a redundant configuration. SIP query DNS to get the list of servers for our domain and try connecting to them in the order specified by the domain's SRV record. It does not matter to which server the SIP phone ultimately connects because the servers are connected by DUNDi. When one of the phones is called, the server which receives the call uses DUNDi to determine with which server the phone is registered and routes the call to that server over IAX2.

These three main Asterisk servers have trunks to the PSTN. They also collect call detail records which they share with one another.

The fourth Asterisk server runs on the same Linksys WL-500G Premium which serves as the gateway router at my parents' house. It servers the SIP phones in their house. It has a much more limited configuration. It relies on the main servers for connection to the PSTN and does not keep its own call detail records.

In future postings I can describe:

* PSTN providers used
* Least Cost Routing
* Collecting and displaying CDR
* Inexpensive SIP phones used

If you would like to hear about any of these topics, please post a comment.

Inexpensive home Asterisk server

I have a new Asterisk server at home. It is a Contec IPC-BX/M600(PCW). This is a wall-mount PC. It is about a foot square and about two inches thick. There is no power brick. The power cord plugs directly into the box. It has a 400MHz processor which should be fast enough for home or small-office use. It has only 64MBytes of RAM, so you need some swap, particularly when compiling Asterisk.

I bought this marvel new on E-Bay for about $55 including shipping. I added a laptop hard disk for storage.

Power consumption is reasonable, about 15 watts when idle.

Yet another VoIP blog

There is already no shortage of IP telephony blogs. Many of them are valuable and interesting. Many of them are written from the standpoint of a observer watching the facinating new devices and services which appear on the market.

My blog will take a different direction. It will be written from the standpoint of a telephony hobbyist. It will be about my attempts to use Asterisk and surplus equipment to create a telephone system for my family and friends.

I hope to cover such topics as hacking Linksys ATA's and creating a custom Asterisk dialplan from scratch.

IP telephony has been my hobby for two years now. For a year now it is also part of my work at a small college in New England. So, I may tell about our experience intergrating Asterisk with a Nortel Meridian phone switch.