Hosting Small Conferences with Skype
If you can't afford to build your own conferencing facility, or don't need to have more than 5 to 10 people on a single call, you can use Skype to host small conference calls without the need for a centralized conference bridge. This makes sense for business communication where there are typically fewer people on a call (except for large conference calls), as well as for small classes and social groups. Most businesses already have some sort of conferencing capability, either via an in house conference bridge or PBX, or via a hosted conferencing service such as WebEx.
I recommend Skype for hosting small conferences and as a backup to the Asterisk/Gizmo configuration described above. Unfortunately, it won't work well for larger calls. Skype does offer the ability to host large conference calls via HighSpeedConferencing, but I would not rely on this as a primary service because it may not be able to accommodate a surge in demand if a lot of people decide to do this at the same time. As of this writing, this is an experimental service with fairly limited capacity relative to potential demand.
Social Uses for this Platform
Organizations may also want to budget some extra capacity so that users can create their own party lines for personal use. Radio Handi, provides this service to the general public. It enables people to create voice communities for any subject, location or peer group. However, we don't have enough capacity to answer calls if the scenario I am describing happens, which is why we are freely sharing information about how to build conferencing platforms.
Organizations can build a "lite" version of what we built at Radio Handi by creating a list of extensions or conference rooms for public use. Think of these like meeting rooms for clubs and organizations.
For example, a school could set up a server specifically for extracurricular organizations and publish a list of extensions for each of them, as well as to publish a list of floating rooms that can be used for any purpose. Students could then dial into these whenever they wanted, and use them either for their stated purpose, or just to kill time.
The latter is an important point. In a quarantine situation, people may be expected to stay at home for days or even several weeks until a local outbreak has subsided. People will get bored and, if there is a high rate of mortality in the community at large, become quite fearful, especially if wildly exaggerated rumors begin to circulate. Enabling people to form social networks and stay in constant contact will help maintain morale and prevent panic. It will also make it easier for people to resist the temptation to break quarantine until it is really safe to do so.
Online gathering places are not a long-term substitute for a classroom, family reunion, or the corner pub, but in a pandemic we may be expected to isolate ourselves from people outside our family for several weeks. Online gathering places can be used as a way to pass time, keep working or going to school, and to boost morale in an otherwise difficult and possibly quite frightening situation.
It will cost most organizations little or nothing to prototype these solutions (closer to nothing if they scavenge existing computers). A school with several hundred students will need only a few standard computers and a local ISP to give them a good deal on hosting. Total cost: a few thousand dollars at most for the computers. Potential benefit: lives saved.
I hope that the flu pandemic does not come to pass. But even if this threat never materializes you can use these systems for day-to-day activities: to host after-hours classes, to allow sick kids to dial-in from home, to create after-hours venues for students, and who knows what else. The main cost of building these systems is time and experimentation, so once you've got them working, you'll be able to use them for many things, and you'll have this in your back pocket if a pandemic happens.
Appendix: Common Problems and Solutions
A full troubleshooting guide is beyond the scope of this article, but this will give you an idea of the problems you are likely to encounter. I also recommend the book Asterisk: The Future of Telephony for detailed configuration and troubleshooting guidance.Also see Asterisk's web site (www.asterisk.org) for more information.
Not Enough Bandwidth Going into Conference Server
You should plan on provisioning 100kbps of bandwidth per concurrent caller. Thus, a 100 user conference bridge will need 10mbps of constant connectivity. In reality, you should probably double this number. Fortunately, bandwidth at collocation facilities is pretty cheap so you should order more than you think you will need.
As a point of reference, Server Beach offers 10mbps of unmetered connectivity for an extra $80/month per server (check for current rates). Thus, a fast dual-CPU machine will cost about $300 per month including connectivity, and will handle about 50 to 100 callers per server (for an average monthly cost of $3 to $6 per concurrent caller).
You can reduce bandwidth requirements substantially by using low bandwidth codecs such as G.729 or Speex, but these also require a lot of computation, which will reduce the number of concurrent calls a given server can handle. Generally, I recommend planning on 40 to 50 users per box, with G.711 mu-Law as the standard codec. You'll use more bandwidth (about 5Mb when the server is running 50 calls), but you're less likely to overload the CPU. Unfortunately, there is no way to predict the exact behavior of a particular server, so you'll just need to set it up and test it to see how many calls your box can handle.
Improperly Configured Asterisk Server
Be sure to disable features you do not need, specifically you will want to disable high compression codecs such as G.729 and GSM. High compression codecs such as GSM reduce the amount of bandwidth needed per call substantially, by 50% or more in many cases. However, this comes at a cost. These codecs require a lot of computation and require Asterisk to transcode, or convert, audio from compressed to uncompressed form and back (especially for conferencing, because every audio stream must be uncompressed so that the conference bridge can blend the different audio streams). Transcoding is bad, because it will reduce your system's capacity from 50 to 100 callers (or more for listen-only conferences) to 20 to 30 callers or less on a slow PC. Order more bandwidth and use the standard G.711 codec. It requires about 80kbps to 100kbps for each call. Also, be sure that the Asterisk application is given higher priority over other applications running on the machine (and avoid having the Asterisk server host other applications such as a web server).
Improper sip.cof Settings
Asterisk is very picky about the SIP configuration since this determines how it will handle incoming calls. The example configurations should get you up and running with Gizmo pretty easily. If you want to use another SIP provider, for public telephone network interconnect for example, be sure to follow their configuration instructions exactly, and test, test, test, and test.
Improper Dial Plan Settings
Asterisk's dial plan, which determines how calls will be handled once answered, is very powerful but also easy to break. I recommend sticking with a simple default dial plan that answers all incoming calls exactly the same way:
- Answer call
- Play a greeting and prompt user for three or four digit extension
- Send call to Meet Me conference (same as three or four digit extension number)
- Play error message if incorrect extension entered, go back to step 2
If you do not really know what you are doing, I do not recommend setting up direct inward dialing where you may have SIP phone numbers routed directly to specific conference rooms or extensions. This is a convenient feature for users, but it is very easy to botch the configuration and not notice it. It is better to force callers to dial a few digits into an auto-attendant, that way all you need to do to verify that the system is answering calls correctly is to call in and if you hear the greeting, you know its working.
Brian McConnell is an inventor, author, and serial telecom entrepreneur. He has founded three telecom startups since moving to California. The most recent, Open Communication Systems, designs cutting-edge telecom applications based on open standards telephony technology.
Return to the O'Reilly Emerging Telephony