Install Ilbc Codec Asterisk Definition

Install Ilbc Codec Asterisk Definition Rating: 10,0/10 2015votes

Jar File Download examples (example source code) Organized by topic. Jar File Download; a /. We assume that you already have a computer with Asterisk installed and configured. So you can make test calls from the telephones connected to your PBX. View and Download Yealink SIP-T48G administrator's manual online.

Install Ilbc Codec Asterisk DefinitionInstall Ilbc Codec Asterisk Definition

John Todd “There’s more than one way to do it.” I’ve been working with Asterisk for nine years, and this motto becomes more true with each release, each added feature, and each clever person who attacks a telecommunications problem with this incredibly flexible toolkit. I had the fantastic opportunity to work as the community manager for the Asterisk project at Digium for two years, which gave me one of the best vantage points for seeing the scope and imagination of the worldwide development effort pushing Asterisk forward. The depth and breadth of Asterisk is staggering—installations with hundreds of thousands of users are now commonplace. I see Asterisk making deep inroads into the financial, military, hospital, Fortune 100 enterprise, service provider, calling card, and mobile environments. In fact, there really aren’t any areas that I can think of where Asterisk isn’t now entrenched as the default choice when there is a need for a generalized voice tool to do “stuff.” Asterisk has been emblematic of the way that open source software has changed business—and changed the world. My favorite part of any Asterisk project overview or conference talk is answering questions from someone new to Asterisk.

As I continue to answer “Yes, it can do that,” I watch as the person’s eyes grow wide. The person starts to smile when he really starts to think about new things to do that his old phone or communication system couldn’t possibly have done. Radio integration? Streaming MP3s into or out of phone calls? Emailing recorded conference calls to the participants? Integration of voice services into existing Java apps?

Instant messages? Yes, yes, yes, yes. The affirmative answers just keep flowing, and at that point, the best thing to do is to sit the person down and start showing him quick demonstrations of how Asterisk can be quickly deployed and developed.

Then, I typically point the person toward the first edition of this book,, and set him loose. In just a few hours of development (or longer, of course), companies can change the way they deliver products to customers, nonprofits can overhaul how their users interact with the services they offer, and individuals can learn to build a perfectly customized call-handling system for their mobile and home phones.

Asterisk scales up and down from individual lines to vast multiserver installations across multiple continents, but the way to start is to install the package, open up some of the configuration files, and start looking at examples. From the basic beginnings of a PBX that Mark Spencer coded in 1999, the Asterisk project, with the help of thousands of developers, has moved from simply connecting phone calls and has matured into a platform that can handle voice, video, and text across dozens of virtual and physical interface types. The creation and growth of Asterisk were the inescapable results of the convergence of the four horsemen of the proprietary hardware apocalypse: open source development ideas, the Internet, Moore’s Law, and the plummeting costs of telecommunications. Even hardware vendors who may be frightened of Asterisk from a competitive standpoint are using it in their labs and core networks: almost all devices in the Voice-over-IP world are tested with Asterisk, making it the most compatible system across vendors. At a recent communications conference I attended, the question “Who uses Asterisk?” was posed to the 1000-plus crowd.

Nearly 75 percent raised their hands. Asterisk is a mature, robust software platform that permeates nearly every area of the telecommunications industry and has firmly cemented itself as one of the basic elements in any open source service delivery system.

I tell people that it’s reasonable for anyone delivering services both via phone and web to want to add an “A” for Asterisk to the LAMP (Linux, Apache, MySQL, [Perl/Python/PHP]) acronym, making it LAAMP. (LAMA-P was another option, but for some reason nobody seems to like that versionI don’t know why.) The expansion of this book to include more examples is something I’ve been looking forward to for some time. Asterisk is accessible because of the ease with which a novice can understand basic concepts.

Then it continues to succeed as the novice becomes a pro and starts tapping the “other ways to do it” with more sophisticated implementations, using AGI with Java, Perl, or Python (or one of the other dozen or so supported languages), or even writing her own custom apps that work as compile-time options in Asterisk. But the first step for anyone, no matter what his or her skill level, is to look at examples of basic apps others have written. Leif, Jim, and Russell have not only put together a fantastic compendium of Asterisk methods, but they have also provided an excellent list of examples that will let the novice or expert quickly learn new techniques and “more than one way to do it.” Asterisk 1. X is fantastically powerful and can solve nearly any voice problem you might have. For those of you building the most complex installations, there is even more interesting work—which will be realized quite soon—in development. The currently-in-development Asterisk SCF (Scalable Communications Framework) is being built as an adjunct open source project to allow Asterisk 1. X systems to scale in even more powerful ways—stay tuned, or better yet, get involved with the project as a developer.

If you’re an experienced Asterisk developer or integrator, I’m sure this book will have a few “Hey, that’s a neat way to do it!” moments for you, which is one of the joys of Asterisk. If this is your first project with Asterisk, I’d like to welcome you to the huge community of users and developers dedicated to making Asterisk better.

This book will take you from a vague idea of doing something with computers and voice communication to the point where you’re able to stun everyone you know with your phone system’s sophisticated tricks. You’re encouraged to participate in the online mailing lists, IRC chatrooms, and yearly AstriCon conference that provide up-to-the-second news and discussion surrounding the project. Without your interest, input, and code, Asterisk wouldn’t exist.

Open source projects are hungry for new ideas and excellent contributions: I encourage you to be a participant in the Asterisk community, and I look forward to seeing your questions and examples in the next edition of this book. Table of Contents This is a book for anyone who uses Asterisk. Asterisk is an open source, converged telephony platform, which is designed primarily to run on Linux. Asterisk combines more than 100 years of telephony knowledge into a robust suite of tightly integrated telecommunications applications.

The power of Asterisk lies in its customizable nature, complemented by unmatched standards compliance. No other PBX can be deployed in so many creative ways. Applications such as voicemail, hosted conferencing, call queuing and agents, music on hold, and call parking are all standard features built right into the software. Moreover, Asterisk can integrate with other business technologies in ways that closed, proprietary PBXs can scarcely dream of. Asterisk can appear quite daunting and complex to a new user, which is why documentation is so important to its growth. Documentation lowers the barrier to entry and helps people contemplate the possibilities.

Produced with the generous support of O’Reilly Media, is the third edition of what was formerly called. We decided to change the name because Asterisk has been so wildly successful that it is no longer an up-and-coming technology. Asterisk has arrived.

This book was written for, and by, members of the Asterisk community. Audience This book is intended to be gentle toward those new to Asterisk, but we assume that you’re familiar with basic Linux administration, networking, and other IT disciplines. If not, we encourage you to explore the vast and wonderful library of books that O’Reilly publishes on these subjects. We also assume you’re fairly new to telecommunications (both traditional switched telephony and the new world of Voice over IP). However, this book will also be useful for the more experienced Asterisk administrator.

We ourselves use the book as a reference for features that we haven’t used for a while. This is where we chop up the kindling and light the fire. Welcome to Asterisk! Discusses the file structure of an Asterisk system. Covers obtaining, compiling, and installing Asterisk. Describes some initial configuration tasks for your new Asterisk system.

This chapter goes over some of the configuration files required for all Asterisk installations. Provides guidance on configuring Asterisk to allow devices such as telephones to connect and make calls. Introduces the heart of Asterisk, the dialplan. Discusses how to configure Asterisk to connect to other systems, such as other Asterisk servers, Internet telephony service providers, or the plain old telephone network. Covers the usage of one of the most popular applications included with Asterisk, the voicemail system.

Focuses on issues that an Asterisk administrator should be aware of when deploying a system outside of North America. Goes over some more advanced dialplan concepts. Describes the usage of two popular telephony features included with Asterisk, call parking and paging. Covers techniques for routing calls between different administrative domains on the Internet. Discusses how to build call queues in Asterisk. Introduces the concept of device states and how they can be used as presence indicators.

Covers how to build a menuing system using the Asterisk dialplan. Discusses various ways that Asterisk can be integrated with a database. Goes over how Asterisk can be used to build applications that act on input provided by a caller. Provides instructions on how to connect to external services including LDAP, calendars, IMAP for voicemail, XMPP, Skype, and text-to-speech. Discusses the various options for integrating sending and receiving faxes with an Asterisk system. Introduces a network API for monitoring and controlling an Asterisk system.

Introduces the Asterisk API that allows call control to be implemented in any programming language. Discusses a number of approaches for clustering multiple Asterisk servers together once the demands of a deployment exceed the capabilities of a single server. Covers a peer-to-peer protocol native to Asterisk that can be used for call routing. Introduces some of the interfaces available for logging and monitoring an Asterisk system.

A survey of some of the web interfaces that complement an Asterisk installation. Discusses some common security issues that Asterisk administrators should be aware of. In conclusion, we discuss some of the things we expect to see from open source telephony in the near future. Explores the technologies in use in traditional telecom networks. This used to be a chapter in old versions of this book.

Although not directly relevant to Asterisk we felt that it might still be useful to some readers, so we’ve left it in the book as an appendix. Delves into all the particularities of Voice over IP. This was also a chapter in old versions of this book. Contains information you should be aware of and take into consideration when planning an Asterisk deployment. Using Code Examples This book is here to help you get your job done. In general, you may use the code in this book in your programs and documentation.

You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.

We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “ Asterisk: The Definitive Guide, Third Edition, by Leif Madsen, Jim Van Meggelen, and Russell Bryant (O’Reilly). Copyright 2011 Leif Madsen, Jim Van Meggelen, and Russell Bryant, 978-0-596-51734-2.” If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us. How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc.

1005 Gravenstein Highway North Sebastopol, CA 95472 (800) 998-9938 (in the United States or Canada) (707) 829-0515 (international or local) (707) 829-0104 (fax) We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at: To comment or ask technical questions about this book, send email to: For more information about our books, conferences, Resource Centers, and the O’Reilly Network, see our website at: Find us on Facebook: Follow us on Twitter: Watch us on YouTube. Acknowledgments To David Duffett, thanks for the excellent chapter on internationalization, which would not have been served well by being written by us North Americans. Next, we want to thank our fantastic editor, Michael Loukides, for your patience with this third edition, which took too long to get off the ground, and many long months to finally get written.

Mike offered invaluable feedback and found incredibly tactful ways to tell us to rewrite a section (or chapter) when it was needed, and make us think it was our idea. Mike built us up when we were down, and brought us back to earth when we got uppity. You are a master, Mike, and seeing how many books have received your editorial oversight contributes to an understanding of why O’Reilly Media is the success that it is. Thanks also to Rachel Head (nee Rachel Wheeler), our copyeditor, who fixes all our silly grammar, spelling, and style mistakes (and the many Canadianisms that Leif and Jim feel compelled to include), and somehow leaves the result reading as if it was what we wrote in the first place. Copyeditors are the unsung heroes of publishing, and Rachel is one of the very best. Download Hercules Psx Ita. Also thanks to Teresa Elsey, our production editor, and the rest of the unsung heroes in O’Reilly’s production department. These are the folks that take our book and make it an O’Reilly book.

During the course of writing this book, we had the pleasure of being able to consult with many people with specific experience in various areas. Their generous contributions of time and expertise were instrumental in our research. Thanks to Randy Resnick, organizer of the VoIP User Group; Kevin Fleming of Digium; Lee Howard, author of iaxmodem and hylafax; Joshua Colp of Digium; Phillip Mullis of the Toronto Asterisk Users Group; Allison Smith, the Voice of Asterisk; Flavio E. Goncalves, author of books on Asterisk, OpenSER, and OpenSIPS; J.

Oquendo, Security Guru; Tzafrir Cohen, font of knowledge about security and lots of other stuff; Jeff Gehlbach, for SNMP; Ovidiu Sas, for your encyclopedic knowlege of SIP; Tomo Takebe, for some SMDI help; Steve Underwood, for help with fax and spandsp; and Richard Genthner and John Covert, for helping with LDAP. A special thanks should also go to John Todd for being one of the first to write comprehensive Asterisk how-tos, all those years ago, and for all the many other things you do (and have done) for the Asterisk community. Leif Madsen It sort of amazes me where I started with Asterisk, and where I’ve gone with Asterisk. In 2002, while attending school, a bunch of my friends and myself were experimenting with voice over the Internet using Microsoft’s MSN product. It worked quite well, and allowed us to play video games while conversing with each other—at least, until we wanted to add a third participant. So, I went out searching for some software that could handle multiple voices (the word was conferencing, but I didn’t even know that at the time, having had little exposure to PBX platforms). I searched the Internet but didn’t find anything in particular I liked (or that was free).

I turned to IRC and explained what I was looking for. Someone (I wish I knew who) mentioned that I should check out some software called Asterisk (he presumably must have thought I was looking for MeetMe(), which I was).

Having the name, I grabbed the software and started looking at what it could do. Incredibly, the functionality I was looking for, which I thought would be the entirety of the software, was only one component in a sea of functionality. And having run a BBS for years prior to going to college, the fact that I could install a PCI card and connect it to the phone network was not lost on me. After a couple of hours of looking at the software and getting it compiled, I started telling one of my teachers about the PCI cards and how maybe we could get some for the classroom for labs and such (our classroom had 30 computers at 10 tables of 3).

He liked the idea and started talking to the program coordinator, and within about 30 minutes an order had been placed for 20 cards. Pretty amazing considering they were TDM400Ps decked out with four daughter cards, and they had only heard about them an hour prior to that.

Then the obsession began. I spent every extra moment of that semester with a couple of computers dedicated to Asterisk use. In those two months, I learned a lot. Then we had a co-op break. I didn’t find any work immediately, so I moved home and continued working on Asterisk, spending time on IRC, reading through examples posted by John Todd, and just trying to wrap my head around how the software worked.

Luckily I had a lot of help on IRC (for these were the days prior to any documentation on Asterisk), and I learned a lot more during that semester. Seeing that the people who took a great interest in Asterisk at the time had a strong sense of community and wanted to contribute back, I wanted to do the same. Having no practical level of coding knowledge, I decided documentation would be something useful to start doing. Besides, I had been writing a lot of papers at school, so I was getting better at it. One night I put up a website called The Asterisk Documentation Assigned (TADA) and started writing down any documentation I could. A couple of weeks later Jared Smith and I started talking, and started the Asterisk Documentation Project (), with the goal of writing an Asterisk book for the community.

That project became the basis of the first edition of this book, Asterisk: The Future of Telephony. Nine years later, I’m still writing Asterisk documentation and have become the primary bug marshal and release manager for the Asterisk project, spoken at every single AstriCon since 2004 (at which Jared and I spoke about the Asterisk Documentation Project; I still have the AsteriskDocs magnet his wife made), and become a consultant specializing in database integration (thanks Tilghman for func_odbc) and clustering (thanks Mark Spencer for DUNDi). I really love Asterisk, and all that it’s allowed me to do.

First, thanks to my parents Rick and Carol, for the understanding and support in everything I’ve done in my life. From the first computer they purchased for far too much money when I was in grade 6 (I started taking an interest in computers in grade 2 using a Commodore 64, and they got me a computer after a parent-teacher interview a few years later) to letting me use the home phone line for my BBS endeavors (and eventually getting me my own phone line), and everything else they have ever done for me, I can never thank them enough. I love you both more than you’ll ever imagine. Thanks to my Grandma T for letting me use her 286 during the years when I didn’t have a computer at home, and for taking me shopping every year on my birthday for 15 years. To my beautiful wife, Danielle, for setting the alarm every morning before she left for work, letting me sleep those extra 10 minutes before starting on this book, and understanding when I had to work late because I went past my 9 A.M.

Stop-writing time, thank you and I love you so much. There are so many people who help me and teach me new things every day, but the most influential on my life in Asterisk are the following: Mark Spencer for writing software that has given me a fantastic career, John Todd for his early examples, Brian K. West for his early help and enthusiasm on IRC, Steve Sokol and Olle Johansson for flying me to my first AstriCon (and subsequent ones!) and letting me be part of the first Asterisk training classes, Jared Smith for helping start the documentation project and doing all the infrastructure that I could never have done, Jim Van Meggelen for joining in early on the project and teaching me new ways to look at life, and Russell Bryant for being an amazing project leader and easy to work with every day, and for not holding a grudge about the bush. Jim Van Meggelen When we set out to write the very first edition of this book over five years ago, we were confident that Asterisk was going to be a huge success. Now, a half-decade later, we’ve written this third edition of what the worldwide Asterisk community calls “The Asterisk Book,” and we’ve matured from revolutionaries into Asterisk professionals. Asterisk has proven that open source telecom is a lasting idea, and the open source telecom landscape is nowadays complemented by more than just Asterisk. Projects like Freeswitch, sipXecs (from SipFoundry), OpenSER/Kamailio/OpenSIPS, and many, many more (and more to come) help to round out the ecosystem.

I want to take this opportunity to thank my very good friend Leif Madsen, who has been with me through all three editions. In our daily lives we don’t always have many opportunities to work with each other (or even grab a pint, these days!), and it’s always a delight to work with you. I also want to thank Russell Bryant, who joined us for this edition, and whose dedication to this project and the Asterisk project in general is an inspiration to me. You’re a Renaissance man, Russell. To Jared Smith, who helped found the Asterisk Documentation Project and coauthored the first two editions with Leif and me (but has since moved on to the Fedora project), I can only say: Asterisk’s loss is Fedora’s gain. I would like to thank my business partners at Core Telecom Innovations and iConverged LLC, without whom I could not do all the cool things I get to do in my professional career. I would like to thank all my friends in the improv community, for helping me to keep laughing at all the challenges that life presents.

Thanks to all my family, who bring love into my life. Finally, thanks to you, the Asterisk community. This book is our gift to you. We hope you enjoy reading it as much as we’ve enjoyed writing it. Russell Bryant I started working on Asterisk in 2004.

I was a student at Clemson University and was working as a co-op engineer at ADTRAN in Huntsville, Alabama. My first job at ADTRAN was working in the Product Qualification department. I remember working with Keith Morgan to use Asterisk as a VoIP traffic generator for testing QoS across a router test network. Meanwhile, a fellow co-op and friend, Adam Schreiber, introduced me to Mark Spencer. Over the next six months, I immersed myself in Asterisk. I learned as much as I could about Asterisk, telephony, and C programming.

When Asterisk 1.0 was released in the fall of 2004, I was named the release maintainer. At the beginning of 2005, I was hired by Digium to continue my work on Asterisk professionally. I have spent the past six amazing years working with Digium to improve Asterisk.

I have worked as a software developer, a software team lead, and now as the engineering manager of the Asterisk development team. I am extremely grateful for the opportunity to contribute to so many areas of the Asterisk project.

There are many people that deserve thanks for the support they have provided along the way. To my wife, Julie, I cannot thank you enough for all the love and support you have given me. Thank you for keeping my life balanced and happy.

You are the best. To my parents, thank you for giving me so many great opportunities in my life to explore different things and find what I really enjoy. You taught me to work hard and never give up. To Leif and Jim, thank you for your invitation to contribute to this book. It has been a fun project, largely due to the pleasure of working with the two of you. Thanks for the laughs and for your dedication to this book as a team effort. I have learned a lot from many people at Digium.

There are three people who stand out the most as my mentors: Mark Spencer, Kevin P. Fleming, and David Deaton. Thank you all for going the extra mile to teach me along the way. I am extremely grateful. To the software development team at Digium, thank you for being such an amazing team to work with.

Your dedication and brilliance play a huge part in the success of Asterisk and make Digium a great place to work. To Travis Axtell, thank you for your help in my early days of learning about Linux and for being a good friend. To my dogs, Chloe and Baxter, thanks for keeping me company while I worked on the book every morning. To all of my friends and family, thank you for your love, support, and fun times. To the entire Asterisk community, thank you for using, enjoying, and contributing to Asterisk. We hope you enjoy the book! — Mahatma Gandhi When we first set out—nearly five years ago—to write a book about Asterisk, we confidently predicted that Asterisk would fundamentally change the telecommunications industry.

Today, the revolution we predicted is all but complete. Asterisk is now the most successful private branch exchange (PBX) in the world, and is an accepted (albeit perhaps not always loved) technology in the telecom industry. Unfortunately, over the past five years the telecom industry has continued to lose its way. The methods by which we communicate have changed. Whereas 20 years ago phone calls were the preferred way to converse across distances, the current trend is to message via text (email, IM, etc.).

The phone call is seen as a bit of a dead thing, especially by up-and-coming generations. Asterisk remains pretty awesome technology, and we believe it is still one of the best hopes for any sort of sensible integration between telecom and all the other technologies businesses might want to interconnect with. With Asterisk, no one is telling you how your phone system should work, or what technologies you are limited to. If you want it, you can have it. Asterisk lovingly embraces the concept of standards compliance, while also enjoying the freedom to develop its own innovations. What you choose to implement is up to you—Asterisk imposes no limits.

Naturally, this incredible flexibility comes with a price: Asterisk is not a simple system to configure. This is not because it’s illogical, confusing, or cryptic; on the contrary, it is very sensible and practical. People’s eyes light up when they first see an Asterisk dialplan and begin to contemplate the possibilities.

But when there are literally thousands of ways to achieve a result, the process naturally requires extra effort. Perhaps it can be compared to building a house: the components are relatively easy to understand, but a person contemplating such a task must either a) enlist competent help or b) develop the required skills through instruction, practice, and a good book on the subject. Asterisk and VoIP: Bridging the Gap Between Traditional and Network Telephony Voice over IP (VoIP) is often thought of as little more than a method of obtaining free long-distance calling. The real value (and—let’s be honest—challenge as well) of VoIP is that it allows voice to become nothing more than another application in the data network.

It sometimes seems that we’ve forgotten that the purpose of the telephone is to allow people to communicate. It is a simple goal, really, and it should be possible for us to make it happen in far more flexible and creative ways than are currently available to us. Technologies such as Asterisk lower the barriers to entry. The Zapata Telephony Project When the Asterisk project was started (in 1999), there were other open-source telephony projects in existence. However, Asterisk, in combination with the Zapata Telephony Project, was able to provide public switched telephone network (PSTN) interfaces, which represented an important milestone in transitioning the software from something purely network-based to something more practical in the world of telecom at that time, which was PSTN-centric.

The Zapata Telephony Project was conceived of by Jim Dixon, a telecommunications consulting engineer who was inspired by the incredible advances in CPU speeds that the computer industry has now come to take for granted. Dixon’s belief was that far more economical telephony systems could be created if a card existed that had nothing more on it than the basic electronic components required to interface with a telephone circuit.

Rather than having expensive components on the card, digital signal processing (DSP) [] would be handled in the CPU by software. While this would impose a tremendous load on the CPU, Dixon was certain that the low cost of CPUs relative to their performance made them far more attractive than expensive DSPs, and, more importantly, that this price/performance ratio would continue to improve as CPUs continued to increase in power. Like so many visionaries, Dixon believed that many others would see this opportunity, and that he merely had to wait for someone else to create what to him was an obvious improvement.

After a few years, he noticed that not only had no one created these cards, but it seemed unlikely that anyone was ever going to. At that point it was clear that if he wanted a revolution, he was going to have to start it himself. And so the Zapata Telephony Project was born. Since this concept was so revolutionary, and was certain to make a lot of waves in the industry, I decided on the Mexican revolutionary motif, and named the technology and organization after the famous Mexican revolutionary Emiliano Zapata. I decided to call the card the “tormenta” which, in Spanish, means “storm,” but contextually is usually used to imply a big storm, like a hurricane or such. [] Perhaps we should be calling ourselves Asteristas.

Regardless, we owe Jim Dixon a debt of thanks, partly for thinking this up and partly for seeing it through, but mostly for giving the results of his efforts to the open source community. As a result of Jim’s contribution, Asterisk’s PSTN engine came to be. Over the years, the Zapata Telephony interface in Asterisk has been modified and improved. The Digium Asterisk Hardware Device Interface (DAHDI) Telephony interface in use today is the offspring of Jim Dixon’s contribution.

Massive Change Requires Flexible Technology Every PBX in existence suffers from shortcomings. No matter how fully featured it is, something will always be left out, because even the most feature-rich PBX will always fail to anticipate the creativity of the customer. A small group of users will desire an odd little feature that the design team either did not think of or could not justify the cost of building, and, since the system is closed, the users will not be able to build it themselves. If the Internet had been thusly hampered by regulation and commercial interests, it is doubtful that it would have developed the wide acceptance it currently enjoys.

The openness of the Internet meant that anyone could afford to get involved. So, everyone did. The tens of thousands of minds that collaborated on the creation of the Internet delivered something that no corporation ever could have. [] As with many other open source projects, such as Linux and so much of the critical software running the Internet, the development of Asterisk was fueled by the dreams of folks who knew that there had to be something more than what traditional industries were producing. These people knew that if one could take the best parts of various PBXs and separate them into interconnecting components—akin to a boxful of LEGO bricks—one could begin to conceive of things that would not survive a traditional corporate risk-analysis process.

While no one can seriously claim to have a complete picture of what this thing should look like, there is no shortage of opinions and ideas. [] Many people new to Asterisk see it as unfinished.

Perhaps these people can be likened to visitors to an art studio, looking to obtain a signed, numbered print. They often leave disappointed, because they discover that Asterisk is the blank canvas, the tubes of paint, the unused brushes waiting. [] Even at this early stage in its success, Asterisk is nurtured by a greater number of artists than any other PBX.

Most manufacturers dedicate no more than a few developers to any one product; Asterisk has scores. Most proprietary PBXs have a worldwide support team comprising a few dozen real experts; Asterisk has hundreds. The depth and breadth of the expertise that surrounds this product is unmatched in the telecom industry. Asterisk enjoys the loving attention of old telco guys who remember when rotary dial mattered, enterprise telecom people who recall when voicemail was the hottest new technology, and data communications geeks and coders who helped build the Internet. These people all share a common belief—that the telecommunications industry needs a proper revolution. [] Asterisk is the catalyst.

Asterisk: The Hacker’s PBX Telecommunications companies that choose to ignore Asterisk do so at their peril. The flexibility it delivers creates possibilities that the best proprietary systems can scarcely dream of. This is because Asterisk is the ultimate hacker’s PBX. The term hacker has, of course, been twisted by the mass media into meaning “malicious cracker.” This is unfortunate, because the term actually existed long before the media corrupted its meaning. Hackers built the networking engine that is the Internet. Hackers built the Apple Macintosh and the Unix operating system.

Hackers are also building your next telecom system. Do not fear; these are the good guys, and they’ll be able to build a system that’s far more secure than anything that exists today. Rather than being constricted by the dubious and easily cracked security of closed systems, the hackers will be able to quickly respond to changing trends in security and fine-tune the telephone system in response to both corporate policy and industry best practices. Like other open source systems, Asterisk will be able to evolve into a far more secure platform than any proprietary system, not in spite of its hacker roots, but rather because of them. The Asterisk Community One of the compelling strengths of Asterisk is the passionate community that developed and supports it. This community, led by the fine folks at Digium, is keenly aware of the cultural significance of Asterisk and has an optimistic view of the future.

One of the more powerful side effects of the Asterisk community’s energy is the cooperation it has spawned among telecommunications, networking, and information technology professionals who share a love for this phenomenon. While these cadres have traditionally been at odds with each other, in the Asterisk community they delight in each others’ skills. The significance of this cooperation cannot be underestimated. If the dream of Asterisk is to be realized, the community must continue to grow—yet one of the key challenges that the community currently faces is a rapid influx of new users. The members of the existing community, having birthed this thing called Asterisk, are generally welcoming of new users, but they’ve grown impatient with being asked the kinds of questions whose answers can often be obtained independently, if one is willing to devote some time to research and experimentation.

Obviously, new users do not fit any particular kind of mold. While some will happily spend hours experimenting and reading various blogs describing the trials and tribulations of others, many people who have become enthusiastic about this technology are completely uninterested in such pursuits. They want a simple, straightforward, step-by-step guide that’ll get them up and running, followed by some sensible examples describing the best methods of implementing common functionality (such as voicemail, auto attendants, and the like). To the members of the expert community, who (correctly) perceive that Asterisk is like a web development language, this approach doesn’t make any sense.

To them, it’s clear that you have to immerse yourself in Asterisk to appreciate its subtleties. Would one ask for a step-by-step guide to programming and expect to learn from it all that a language has to offer? Clearly, there’s no one approach that’s right for everyone. Asterisk is a different animal altogether, and it requires a totally different mind-set. As you explore the community, though, be aware that it includes people with many different skill sets and attitudes. Some of these folks do not display much patience with new users, but that’s often due to their passion for the subject, not because they don’t welcome your participation. Asterisk-Biz Anything commercial with respect to Asterisk belongs in this list.

If you’re selling something Asterisk-related, sell it here. If you want to buy an Asterisk service or product, post here. Asterisk-Dev The Asterisk developers hang out here. The purpose of this list is the discussion of the development of the software that is Asterisk, and its participants vigorously defend that purpose. Expect a lot of heat if you post anything to this list not specifically relating to programming or development of the Asterisk code base.

General coding questions (such as queries on interfacing with AGI or AMI) should be directed to the Asterisk-Users list. Warning The Asterisk-Dev list is not second-level support! If you scroll through the mailing list archives, you’ll see this is a strict rule.

The Asterisk-Dev mailing list is about discussion of core Asterisk development, and questions about interfacing your external programs via AGI or AMI should be posted on the Asterisk-Users list. Asterisk-Users This is where most Asterisk users hang out. This list generates several hundred messages per day and has over ten thousand subscribers. While you can go here for help, you are expected to have done some reading on your own before you post a query. Asterisk Wiki Sites The Asterisk Wiki (which exists in large part due to the tireless efforts of James Thompson— thanks James!) is a source of much enlightenment and confusion. Another important resource is the community-maintained repository of VoIP knowledge at, which contains a truly inspiring cornucopia of fascinating, informative, and frequently contradictory information about many subjects, just one of which is Asterisk. Since Asterisk documentation forms by far the bulk of the information on this website, [] and it probably contains more Asterisk knowledge than all other sources put together (with the exception of the mailing list archives), it is a popular place to go for Asterisk knowledge.

An important new wiki project is the official Asterisk Wiki, found. While not yet as full of content as, this wiki will be more formally supported and is therefore more likely to contain information that is kept current and accurate. The Asterisk Documentation Project The Asterisk Documentation Project was started by Leif Madsen and Jared Smith, but several people in the community have contributed. The goal of the documentation project is to provide a structured repository of written work on Asterisk. In contrast with the flexible and ad hoc nature of the Wiki, the Docs project is passionate about building a more focused approach to various Asterisk-related subjects. As part of the efforts of the Asterisk Docs project to make documentation available online, this book is available at the website, under a Creative Commons license. The Business Case It is very rare to find businesses these days that do not have to reinvent themselves every few years.

It is equally rare to find a business that can afford to replace its communications infrastructure each time it goes in a new direction. Today’s businesses need extreme flexibility in all of their technology, including telecom. In his book Crossing the Chasm (HarperBusiness), Geoffrey Moore opines, “The idea that the value of the system will be discovered rather than known at the time of installation implies, in turn, that product flexibility and adaptability, as well as ongoing account service, should be critical components of any buyer’s evaluation checklist.” What this means, in part, is that the true value of a technology is often not known until it has been deployed. How compelling, then, to have a system that holds at its very heart the concept of openness and the value of continuous innovation. [] It should be noted that these folks need not leave disappointed. Several projects have arisen to lower the barriers to entry for Asterisk. By far the most popular and well known is the FreePBX interface (and the multitude of projects based on it).

These interfaces (check out for an idea of how many there are) do not make it easier to learn Asterisk, because they separate you from the platform or dialplan configuration, but many of them will deliver a working PBX to you much faster than the more hands-on approach we employ in this book. — Doctor Who Asterisk is very different from other, more traditional PBXs, in that the dialplan in Asterisk treats all incoming channels in essentially the same manner. In a traditional PBX, there is a logical difference between stations (telephone sets) and trunks (resources that connect to the outside world). This means, for example, that you can’t install an external gateway on a station port and route external calls to it without requiring your users to dial the extension number first. Also, the concept of an off-site resource (such as a reception desk) is much more difficult to implement on a traditional PBX, because the system will not allow external resources any access to internal features. [] Asterisk, on the other hand, does not have an internal concept of trunks or stations. In Asterisk, everything that comes into or goes out of the system passes through a channel of some sort.

There are many different kinds of channels; however, the Asterisk dialplan handles all channels in a similar manner, which means that, for example, an internal user can exist on the end of an external trunk (e.g., a cell phone) and be treated by the dialplan in exactly the same manner as that user would be if she were on an internal extension. Unless you have worked with a traditional PBX, it may not be immediately obvious how powerful and liberating this is. Figure 2-1 illustrates the differences between the two architectures. Modules Asterisk is built on modules. A module is a loadable component that provides a specific functionality, such as a channel driver (for example, chan_sip.so), or a resource that allows connection to an external technology (such as func_odbc.so). Asterisk modules are loaded based on the /etc/asterisk/modules.conf file. We will discuss the use of many modules in this book.

At this point we just want to introduce the concept of modules, and give you a feel for the types of modules that are available. It is actually possible to start Asterisk without any modules at all, although in this state it will not be capable of doing anything. It is useful to understand the modular nature of Asterisk in order to appreciate the architecture. Insignificant This module is ancient history. If you use it, be aware that you are mostly on your own when it comes to any sort of community support. Unreliable This module is new or experimental, and is not suitable for production.

Useful This module is current, maintained, popular, and recommended. Usable This module works but may be incomplete or unpopular, and/or is not recommended by the authors.

New This module is quite new, and its completeness and popularity are difficult to gauge at this time. Deprecated This module has been replaced by something that is considered superior. Limited This module has limitations that may make it unsuitable to your requirements. Essential This module is one you’ll never want to be without. And now, without further ado, let’s take a look at the modules, grouped by module type. Name Purpose Popularity/Status bridge_builtin_features Performs bridging when utilizing built-in user features (such as those found in features.conf). New bridge_multiplexed Performs complex multiplexing, as would be required in a large conference room (multiple participants).

Currently only used by app_confbridge. New bridge_simple Performs simple channel-to-channel bridging.

New bridge_softmix Performs simple multiplexing, as would be required in a large conference room (multiple participants). Currently only used by app_confbridge. Name Purpose Popularity/Status pbx_ael Asterisk Extension Logic (AEL) offers a dialplan scripting language that looks like a modern programming language. Usable [] pbx_config This is the traditional, and most popular, dialplan language for Asterisk.

Without this module, Asterisk cannot read extensions.conf. Useful pbx_dundi Performs data lookups on remote Asterisk systems. Useful pbx_loopback Performs something similar to a dialplan include, but in a deprecated manner. Insignificant [] pbx_lua Allows creation of a dialplan using the Lua scripting language.

Useful pbx_realtime Provides functionality related to the Asterisk Realtime Architecture. Useful pbx_spool Provides outgoing spool support relating to Asterisk call files. Test Modules Test modules are used by the Asterisk development team to validate new code. They are constantly changing and being added to, and are not useful unless you are developing Asterisk software. If you are an Asterisk developer, however, the Asterisk Test Suite may be of interest to you as you can build automated tests for Asterisk and submit those back to the project, which runs on several different operating systems and types of machines.

By expanding the number of tests constantly, the Asterisk project avoids the creation of regressions in code. By submitting your own tests to the project, you can feel more confident in future upgrades.

More information about installing the Asterisk Test Suite is available in this blog post:. More information about building tests is available in this document: or you can join the #asterisk-testing channel on the Freenode IRC network. Modules Asterisk modules are usually installed to the /usr/lib/asterisk/modules folder. You will not normally have to interact with this folder; however, it will be occasionally useful to know where the modules are located.

For example, if you upgrade Asterisk and select different modules during the menuselect phase of the install, the old (incompatible) modules from the previous Asterisk version will not be deleted, and you will get a warning from the install script. Those old files will need to be deleted from the modules folder. This can be done either manually or with the “uninstall” make ( make uninstall) target.

Hardware Asterisk is capable of communicating with a vast number of different technologies. In general, these connections are made across a network connection; however, connections to more traditional telecom technologies, such as the PSTN, require specific hardware. Many companies produce this hardware, such as Digium (the sponsor, owner, and primary developer of Asterisk), Sangoma, Rhino, OpenVox, Pika, Voicetronix, Junghanns, Dialogic, Xorcom, beroNet, and many others. The authors prefer cards from Digium and Sangoma; however, the products offered by other Asterisk hardware manufacturers may be more suitable to your requirements. The most popular hardware for Asterisk is generally designed to work through the Digium Asterisk Hardware Device Interface (known as DAHDI).

These cards will all have different installation requirements and different file locations. In, we will discuss DAHDI in more detail; however, we will limit our discussion to DAHDI only. You will need to refer to the specific documentation provided by the manufacturers of any cards you install for details on those cards. Previous Release Methodologies When we had just Asterisk 1.2 and 1.4, all new development was carried out in trunk (it still is), and only bug fixes went into the 1.2 and 1.4 branches. The Asterisk 1.2 branch has been marked as EOL (End of Life), and is no longer receiving bug fixes or security updates.

Prior to the 1.6. X branches, bug fixes were carried out only in trunk and in the 1.4 branch. Because all new development was done in trunk, until the 1.6 branch was created people were unable to get access to the new features and functionality. This isn’t to say the new functionality wasn’t available, but with all the changes that can happen in trunk, running a production server based on it requires a very Asterisk-savvy (and C code–savvy) administrator. To try to relieve the pressure on administrators, and to enable faster access to new features (in the time frame of months, and not years), a new methodology was created.

Branches in 1.6 would actually be marked as 1.6.0, 1.6.1, 1.6.2, etc., with the third number increasing by one each time a new feature release was created. The goal was to provide new feature releases every 3–4 months (which would be branched from trunk), providing a shorter and clearer upgrade path for administrators. If you needed a new feature, you’d only have to wait a few months and could then upgrade to the next branch. Tags from these branches look like this. So, so far we have branches, which are 1.2, 1.4, 1.6.0, 1.6.1, and 1.6.2 (there is no 1.6 branch). Within each of those branches, we create tags (releases), which look like 1.2.14, 1.4.30, 1.6.0.12, 1.6.1.12, and 1.6.2.15. Unfortunately, it ended up not working out that 1.6.

X branches were created from trunk every 3–4 months: the development process has led to a minimum release time of 6–8 months. Not only that, but the 1.6. X numbering methodology adds problems of its own. People got confused as to what version to run, and that the 1.6.0, 1.6.1, and 1.6.2 branches were all separate major version upgrades. When you increase the number from 1.2 to 1.4, and then to 1.8, it is obvious that those are distinct branches and major version changes. With 1.6.0, 1.6.1, and 1.6.2, it is less obvious. The New Release Methodology The development team learned a lot of things during the 1.6.

The idea surrounding the releases was noble, but the implementation ended up being flawed when put into real use. So, with Asterisk 1.8, the methodology has changed again, and will look a lot more like that used in the 1.2 and 1.4 releases. While the development team still wants to provide access to new features and core changes on a more regular basis (every 12 months being the goal), there is recognition that it is also good to provide long-term support to a stable, popular version of Asterisk. You can think of the Asterisk 1.4 branch as being a long-term support (LTS) version.

The 1.6.0, 1.6.1, and 1.6.2 branches can be thought of as feature releases that continue to receive bug fixes after release, but are supported for a shorter period of time (about a year). The new LTS version is Asterisk 1.8 (what this book is based on); it will receive bug fixes for four years and an additional year of security releases after that, providing five years of support from the Digium development team. During the long-term support phase of Asterisk 1.8, additional branches will be created on a semi-regular basis as feature releases. These will be tagged as versions 1.10, 1.12, and 1.14, respectively. Each of these branches will receive bug fixes for a period of one year, and security releases will continue to be made for an additional year before the branches are marked as EOL. The current statuses of all Asterisk branches, their release dates, when they will go into security release–only mode, and when they will reach EOL status are all documented on the Asterisk wiki. — Helen Keller In this chapter we’re going to walk through the installation of Asterisk from the source code.

Many people shy away from this method, claiming that it is too difficult and time-consuming. Our goal here is to demonstrate that installing Asterisk from source is not actually that difficult to do. More importantly, we want to provide you with the best Asterisk platform on which to learn. In this book we will be helping you build a functioning Asterisk system from scratch. In this chapter you will build a base platform for your Asterisk system. Given that we are installing from source, there is potentially a lot of variation in how you can do this.

The process we discuss here is one that we’ve used for many years, and following it will provide you with a suitable foundation for Asterisk. As part of this process we will also explain installation of some of the software dependencies on the Linux platform that will be needed for topics covered later in this book (such as database integration). We will show instructions for installing Asterisk on both (a Red Hat–based distribution) and (a Debian-based distribution), which we believe covers the vast majority of Linux distributions being installed today.

We’ll try to keep the instructions general enough that they should be useful on any distribution of your choice. [] We have chosen to install on CentOS and Ubuntu because they are the most popular options, but Asterisk is generally distribution-agnostic. Asterisk will even install on Solaris, BSD, or OS X [] if you like. We won’t be covering them in this book, though, as Asterisk is most heavily developed on the Linux platform.

Asterisk Packages There are also packages that exist for Asterisk that can be installed using popular package- management programs such as yum or apt-get. You are welcome to experiment with them. Prebuilt packages may not always be kept up-to-date, though, so for the latest version we always recommend installing from source. You can find package instructions. Some commands you see in this chapter will be split into separate rows, each labeled for the distribution on which the command should be performed. Commands for which distributions are not specified are for common commands that can be run on both distributions.

Asterisk-Based Projects Many projects have been created that use Asterisk as their underlying platform. Some of these, such as Trixbox, have become so popular that many people mistake them for the Asterisk product itself. These projects generally will take the base Asterisk product and add a web-based administration interface, a complex database, and a rigid set of constraints on how changes can be made to the configuration. We have chosen not to cover these projects in this book, for several reasons.

• This book tries, as much as possible, to focus on Asterisk and only Asterisk. • Books have already been written about some of these Asterisk-based projects.

• We believe that if you learn Asterisk in the way that we will teach you, the knowledge will serve you well, regardless of whether you eventually choose to use one of these prepackaged versions of Asterisk. • For us, the power of Asterisk is that it does not attempt to solve your problems for you. These projects are an excellent example of what can be built with Asterisk. They are truly amazing.

However, if you are looking to build your own Asterisk application (which is really what Asterisk is all about), these projects will impose limitations on you, because they are focused on simplifying the process of building a business PBX, not on making it easier to access the full potential of the Asterisk platform. Some of the most popular Asterisk-based projects include. CentOS Server CentOS means “Community Enterprise Operating System,” and it is based on Red Hat Enterprise Linux (RHEL). For more information about what CentOS is and its history, see.

You will need to download an ISO from the CentOS website, located. Select either the i386 or x86_64 directory for 32-bit or 64-bit hardware, respectively. You will then be presented with a list of mirrors that appear to be close to you physically. Choose one of the mirrors, and you will be presented with a list of files to download. Likely you will want the first available selection, which is the first ISO file of a set.

You will only need the first ISO file of the set as we’ll be installing additional software with yum. Once you’ve downloaded the ISO file, burn it to a CD or DVD and start the installation process. If you’re installing into a virtual machine (which we don’t recommend for production use, [] but can be a great way to test out Asterisk), you should be able to mount the ISO file directly and install from there. Base system installation Upon booting from the CD, type linux text and then press Enter. [] At this point the text installation interface will start.

You will be asked whether you want to test the media. These instructions assume you’ve already done so, and therefore can skip that step. CentOS will then welcome you to the installation. Press Enter to continue. Choose your language and make a keyboard selection.

[] If you’re in North America, you will probably just select the defaults. If you’ve previously formatted your hard drive, you will be asked to initialize the drive, which will erase all data. The installer will ask if you want to remove the existing partitioning scheme and create a new one. Select Remove all partitions on selected drives and create default layout.

If a more appropriate option exists, select that instead. In the drive window, verify that the correct disk drive is selected. (Pressing Tab will cycle through the selections on the screen.) Once the drive window is selected, you can scroll up and down (presuming you have multiple drives) and select which hard drive you wish to install to. Toggle the selections by pressing space bar.

Verify that the correct drive is selected, press Tab until the OK button is highlighted, and press Enter. A message confirming that you want to remove all Linux partitions and create the new partition scheme will be presented. You will be asked to review the partitioning layout. Feel free to modify the partition scheme if you prefer something different (see the following sidebar for some advice on this); however, the default answer No is fine for light production use where storage requirements will be low. Separating the /var Mount Point to Its Own Partition On a system dedicated to Asterisk, the directory with the largest storage requirement is /var. This is where Asterisk will store recordings, voicemails, log files, prompts, and a myriad of constantly growing information.

In normal operation, it is unlikely that Asterisk will fill the hard disk. However, if you have extensive logging turned on or are recording all calls, this could, in theory, occur. (This is likely to happen several months after you’ve completed the install and to take your entire staff by surprise.) If the drive the operating system is mounted on fills up, there is the potential for a kernel panic. By separating /var from the rest of the hard drive, you significantly lower the risk of a system failure.

Note Having a full volume is still a major problem; however, you will at least be able to log into the system to rectify the situation. At the Review and modify the partitioning layout screen, you can create a separate volume for /var. Selecting Yes will bring up the Partitioning tool. To partition the drive accurately, you need to know what the hard drive size is; this may not jibe with what is stamped on the outside of the drive because you have to tell the tool how to chop up the drive.

A limitation of the tool is that there is no option to say “use all available space”; that is, you can’t simply could use 500 MB on the / partition and then say “use the rest for /var”. The workaround is to make a note of the size it has selected for / currently, as that is the full space, subtract 500 MB from that, and make that the size for the / partition. The subtracted amount will then be reserved for /var. A message will appear asking if you’d like to configure the eth0 network interface on your system. Be sure the Activate on boot and Enable IPv4 support options are enabled, then select OK.

If your network provides automatic IP provisioning via DHCP, you can just select OK. Otherwise, select Manual address configuration, enter the appropriate information, and then select OK. Next, you’ll be asked to provide a hostname.

You can either allow the DHCP server to provide one for you (if your network assigns hostnames automatically) or enter one manually, then select OK. You will be presented with a list of time zones. Highlight your local time zone and select OK. At this point, you will be asked for a root password.

Enter a secure password and type it again to confirm. After entering your secure password, select OK. Next up will be the package selection. Several packages that you don’t need to install (and that require additional ISO files you probably haven’t downloaded) are selected by default. Deselect all options in the list using the space bar, then select the Customize software selection option. Once you’ve done that, select OK.

You will then be presented with the Package Group Selection screen. Scroll through the whole list, deselecting each item. If any packages are selected, you’ll be prompted for additional CDs that you have not downloaded. We’ll be installing additional packages with the yum application after the operating system is installed. Once you’ve deselected all packages, select OK.

A dependency check will then be performed and a confirmation that installation is ready to begin will be presented. Select OK to start the installation. The filesystem will then be formatted, the installation image transferred to the hard drive, and installation of the system packages performed.

Upon installation, you will be asked to reboot. Remove any media in the drives and select the Reboot button.

Base system update Once you’ve rebooted your system, you need to run the yum update command to make sure you have the latest base packages. To do this, log in using the username root and the password you created during installation. Once logged in, run the following: # yum update Is this ok [y/N]: y When prompted to install the latest packages, press y and wait for the packages to update. If you’re asked to accept a GPG key, press y. When complete, reboot the system as it is likely the kernel will have been updated []: # reboot. Enabling NTP for accurate system time Keeping accurate time is essential on your Asterisk system, both for maintaining accurate call detail records and for synchronization with your other programs.

You don’t want the times of your voicemail notifications to be off by 10 or 20 minutes, as this can lead to confusion and panic from those who might think their voicemail notifications are taking took too long to be delivered. The ntpd command can be used to ensure that the time on your Asterisk server remains in sync with the rest of the world: # yum install ntp. Is this ok [y/N]: y. # ntpdate pool.ntp.org # chkconfig ntpd on # service ntpd start The defaults shipped with CentOS are sufficient to synchronize the time and keep the machine’s time in sync with the rest of the world. Adding a system user The Ubuntu server install process asks you to add a system user other than root, but CentOS does not.

In order to be consistent in the book and to be more secure, we’re going to add another system user and provide it sudo access. [] To add the new user, execute the adduser command: # adduser asteriskpbx # passwd asteriskpbx Changing password for user asteriskpbx. New UNIX password: Retype new UNIX password: Now we need to provide the asteriskpbx user sudo access. We do this by modifying the sudoers file with the visudo command. You’ll need to install visudo the first time you use it: # yum install sudo With the sudo-related applications and file installed, we can modify the sudoers file.

Execute the visudo command and look for the lines shown below: # visudo ## Allows people in group wheel to run all commands%wheel ALL=(ALL) ALL With the%wheel line uncommented as shown in our example, save the file by pressing Esc, then typing:wq and pressing Enter. Now open the /etc/group file in your favorite editor ( nano is easy to use) and find the line that starts with the word wheel. Modify it like so: wheel:x:10:root,asteriskpbx Save the file, log out from root by typing exit, and log in as the asteriskpbx user you created.

Test your sudo access by running the following command: $ sudo ls /root/ [sudo] password for asteriskpbx: After typing your password, you should get the output of the /root/ directory. If you don’t, go back and verify the steps to make sure you didn’t skip or mistype anything. The rest of the instructions in this chapter will assume that you’re the asteriskpbx user and that you have sudo access. One last thing needs to done, which will allow you to enter commands without having to enter the full path.

By default only root has /sbin/ and /usr/sbin/ in the default system PATH, but we’ll add it to our asteriskpbx user as well since we’ll be running many applications located in those directories. Start by opening the hidden file.bash_profile located within the asteriskpbx home directory with an editor.

We’re then going to append:/usr/sbin:/sbin to the end of the line starting with PATH: $ vim ~/.bash_profile PATH=$PATH:$HOME/bin:/usr/sbin:/sbin As previously, save the file by pressing Esc and then typing:wq and pressing Enter. With the operating system installed, you’re ready to install the dependencies required for Asterisk. The next section deals with Ubuntu, so you can skip ahead to the section, which provides an in-depth review of the installation process. Alternatively, if you’ve already reviewed the information in that section, you may want to refer back to the for a high-level review of how to install Asterisk. Ubuntu Server Ubuntu Server is a popular Linux distribution loosely based on Debian. There is also a popular desktop version of the software.

The Ubuntu Server package contains no GUI and is ideal for Asterisk installations. To get the latest version of Ubuntu Server, [] visit and select the Server tab at the top of the page. You will be provided with a page that contains information about Ubuntu Server Edition.

Clicking the orange Download button in the upper-right corner will take you to a page where you can select either the 32-bit or 64-bit version of Ubuntu Server. After selecting one of the options, you can press the Start download button. Once you’ve downloaded the ISO file, burn it to a CD and start the installation process. If you’re installing into a virtual machine (which we don’t recommend for production use, but can be a great way to test out Asterisk), you should be able to mount the ISO file directly and install from there. Base system installation Upon booting from the CD, you will be presented with a screen where you can select your language of choice.

By default English is the selected language, and after a timeout period, it will be automatically selected. After selecting your language, press Enter. The next screen will give you several options, the first of which is Install Ubuntu Server.

Select it by pressing Enter. You will then be asked which language to use for the installation (yes, this is slightly redundant). Select your language of choice (the default is English), and press Enter. You will be presented with a list of countries. Once you’ve found your country and highlighted it, press Enter.

You will then be asked if you would like to use the keyboard layout detector. If you know which keyboard type you have, you can select No and then pick it from a list of formats. If you are utilizing the keyboard layout detector, you will be prompted to press a series of keys. If you use the keyboard detector and it does not detect your keyboard correctly (typical when installing into a virtual machine via a remote console), you can go back and select from a list manually. Once you’ve picked your keyboard, the installation will continue by attempting to set up your network automatically. If all goes well, you will be prompted to enter a hostname for your system. You can pick anything you want here, unless your network requires your system to a have a specific hostname.

Input it now and then press Enter. The installer will attempt to contact a Network Time Protocol (NTP) server to synchronize your clock. Ubuntu will then try to autodetect your time zone and present you with its choice.

If correct, select Yes, otherwise, select No and you’ll be presented with a list of time zones to select from. Select your time zone, or select from the worldwide list if your time zone is not shown. Once you’ve selected your time zone, press Enter to continue. The installer will then ask you some questions about partitioning your system. Typically the default is fine, which is to use the guided system, utilizing the entire disk, and to set up the Logical Volume Manager (LVM). Press Enter once you’ve made your selection.

Then you’ll be asked which partition to install to, which likely is the only one on your system. Press Enter to continue, at which point you’ll be asked to confirm the changes to the partition table. Select Yes and press Enter to continue. You will now be asked how much space to use (the default value will be to use the entire disk).

Press Enter once you’ve entered and confirmed the amount of space you want to use. The installer will then request one last confirmation before making the changes to the disk. Select Yes to write the changes to disk. The installer will now format the hard disk, write the partitioning scheme to disk, copy the files, and perform the file installation. When the file installation is complete, you’ll be asked to enter the Full name of the new user, from which a username will be generated. The system will suggest a username, but you are free to change the username to whatever you like. After entering your username, you’ll be asked to supply a password, and then asked to confirm the password you’ve entered.

Ubuntu does a good job of providing a secure system by not providing direct access to root, but rather using the sudo application, which allows you to run commands as root without being the root user. Enter a username, [] such as asteriskpbx, and a secure password to continue. You’ll use these to log into the system once the installer ends. The installer will then ask you if you want to encrypt your home directory. This is not necessary and will add CPU overhead. Note The rest of the installation instructions will assume that asteriskpbx was chosen as the username.

If your system is behind a web proxy, enter the proxy information now. If you’re not behind a proxy, or don’t know if you are, simply press Enter. You will then be asked if you want to install updates automatically. The default is to perform no automatic updates, which is what we recommend. Should a system reboot occur, an update to the kernel will render Asterisk nonstartable until you recompile it [] (which won’t make you popular). It is better practice to identify updates on a regular basis and perform them manually in a controlled manner. Normally, you would want to advise your users of the expected downtime and schedule the downtime to happen after business hours (or while a redundant system is running).

Select No automatic updates and press Enter. Since we’ll be installing our dependencies with apt-get, we only need to select one package during the install: OpenSSH server. SSH is essential if you wish to perform remote work on the system. However, if your local policy states that your server needs to be managed directly, you may not want to install the OpenSSH server. Warning Pressing the Enter key will accept the current selections and move on with the install. You need to use space bar to toggle your selections.

After you’ve selected OpenSSH server, press Enter. If this is the only operating system on the machine (which it likely is), Ubuntu will give you the option to install the GRUB bootloader on your system.

It provides this prompt in order to give you the option of skipping the GRUB installation, as it will modify the master boot record (MBR) on your system. If there is another operating system it has failed to detect that has information loaded into the MBR, it’s nice to be able to skip modifying it. If this is the only operating system installed on your server, select Yes. When the system has finished the install, you’ll be asked to remove any media in the drives and to reboot the system by selecting Continue, at which point the installation will be complete and the system will reboot. Base system update Now that we’ve completed installing Ubuntu Server, we need to perform a system update with apt-get to make sure we have the latest packages installed. You’ll be presented with a login prompt where you’ll log in with the username and password you created in the installer (e.g., asteriskpbx).

Once logged in, run the following command: $ sudo apt-get update [sudo] password for asteriskpbx. Reading package lists.

Done $ sudo apt-get upgrade Reading state information. Do you want to continue [Y/n]? Enable NTP for accurate system time Keeping accurate time is essential on your Asterisk system, both for maintaining accurate call detail records as well as for synchronization with your other programs. You don’t want the times of your voicemail notifications to be off by 10 or 20 minutes, as this can lead to confusion and panic from those who might think their voicemail notification took too long to be delivered: $ sudo apt-get install ntp The default on Ubuntu is to run a time sync server without ever changing the time on your own machine.

This won’t work for our needs, so we’ll need to change the configuration file slightly. Because of this, we need to guide you through using a command line editor.

The nano editor is already installed on your Ubuntu machine and is remarkably easy to use []: $ sudo nano /etc/ntp.conf Your terminal will switch to full-screen output. Use your arrow keys to move down to the section that looks like # By default, exchange time with everybody, but don't allow configuration. Restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify nopeer noquery Add two new lines after this section, to allow ntpd to synchronize your time with the outside world, such that the above section now looks like # By default, exchange time with everybody, but don't allow configuration. Restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify nopeer noquery restrict -4 127.0.0.1 restrict -6::1 That’s everything we need to change, so exit the editor by pressing Ctrl+ X. When prompted whether to save the modifications, press Y; nano will additionally ask you for the filename. Just hit Enter to confirm the default /etc/ntp.conf. Now restart the NTP daemon: $ sudo /etc/init.d/ntp restart With the operating system installed, you’re ready to install the dependencies required for Asterisk.

The next section provides an in-depth review of the installation process. If you’ve already reviewed the information in, you may want to refer back to for a high-level review of how to install Asterisk. Software Dependencies The first thing you need to do once you’ve completed the installation of your operating system is to install the software dependencies required by Asterisk. The commands listed in have been split into two columns, for Ubuntu Server and CentOS Server. These packages will allow you to build a basic Asterisk system, along with DAHDI and LibPRI. Not every module will be available at compile time with these dependencies; only the most commonly used modules will be built. If additional dependencies are required for other modules used later in the book, instructions will be provided as necessary.

Warning Please be aware that the dependency information on CentOS 64-bit does not take into account that 32-bit libraries should not be installed. If such libraries are installed, you will end up with additional packages that use disk space and can cause conflicts if the system attempts to compile against a 32-bit library instead of its 64-bit counterpart.

In order to resolve this problem, add.x86_64 to the end of each package name when installing it. So, for example, instead of executing yum install ncurses-devel, you will execute yum install ncurses-devel.x86_64.

This is not necessary on a 32-bit platform. Ubuntu CentOS sudo apt-get install build-essential subversion libncurses5-dev libssl-dev libxml2-dev vim-nox sudo yum install gcc gcc-c++ make wget subversion libxml2-devel ncurses-devel openssl-devel vim-enhanced These packages will get you most of what you’ll need to get started with installing Asterisk, DAHDI, and LibPRI. Note that you will also require the software dependencies for each package that we indicate needs to be installed.

These will be resolved automatically for you when you use either yum or apt-get. We have also included the OpenSSL development libraries, which are not strictly necessary to compile Asterisk, but are good to have: they enable key support and other encryption functionality. We have installed vim as our editor, but you can choose anything you want, such as nano, joe, or emacs. Asterisk contains a script that will install the dependencies for all features in Asterisk. At this time it is complete for Ubuntu but does not list all required packages for CentOS. Once you have downloaded Asterisk using the instructions in, use the following commands if you would like to run it: $ cd ~/src/asterisk-complete/asterisk/1.8 $ sudo./contrib/scripts/install_prereq install $ sudo./contrib/scripts/install_prereq install-unpackaged.

Downloading What You Need There are several methods of getting Asterisk: via the Subversion code repository, via wget from the downloads site, or via a package-management system such as apt-get or yum. We’re only going to cover the first two methods, since we’re interested in building the latest version of Asterisk from source. Typically, package-management systems will have versions that are older than those available from Subversion or the downloads site, and we want to make sure we have the most recent fixes available to us, so we tend to avoid them. Tip The official packages from Digium do tend to stay up to date. There are currently packages for CentOS/RHEL available. Before we start getting the source files, let’s create a directory structure to house the downloaded code. We’re going to create the directory structure within the home directory for the asteriskpbx user on the system.

Once everything is built, it will be installed with the sudo command. We’ll then go back and change the permissions and ownership of the installed files in order to build a secure system. To begin, issue the following command: $ mkdir -p ~/src /asterisk-complete/asterisk Now that we’ve created a directory structure to hold everything, let’s get the source code.

Choose one of the following two methods to get your files. Getting the Latest Version Asterisk is a constantly evolving project, and there are many different versions of the software that you can implement. In, we talked about Asterisk versioning.

The concept of how Asterisk is versioned is important to understand because the versioning system for Asterisk has undergone a few changes of methodology over the years. So, if you’re not up to speed on Asterisk versioning, we strongly recommend that you go back and read. Having said all that, in most cases all you need to do is grab the latest version from the website. We will be installing and using Asterisk 1.8 throughout this book. Getting the Source via Subversion Subversion is a version control system that is used by developers to track changes to code over a period of time. Each time the code is modified, it must first be checked out of the repository; then it must be checked back in, at which point the changes are logged. Thus, if a change creates a regression, the developers can go back to that change and remove it if necessary.

This is a powerful and robust system for development work. It also happens to be useful for Asterisk administrators seeking to retrieve the software. To download the source code to the latest version of Asterisk 1.8, use these commands: $ cd ~/src/asterisk-complete/asterisk $ svn co You can now skip directly to.

LibPRI LibPRI is a library that adds support for ISDN (PRI and BRI). The use of LibPRI is optional, but since it takes very little time to install, doesn’t interfere with anything, and will come in handy if you ever want to add cards to a system at a later point, we recommend that you install it now.

Check out the latest version of LibPRI and compile it like so: $ cd ~/src/asterisk-complete/ $ mkdir libpri $ cd libpri/ $ svn co $ cd 1.4. $ make $ sudo make install. DAHDI-tools and DAHDI-linux DAHDI is actually a combination of two separate code bases: DAHDI-tools, which provides various administrator tools such as dahdi_cfg, dahdi_scan, etc.; and DAHDI-linux, which provides the kernel drivers. Unless you’re only updating one or the other, you’ll be installing both at the same time, which is referred to as DAHDI-linux-complete. The version numbering for DAHDI-linux-complete will look something like 2.4.0+2.4.0, where the number to the left of the plus sign is the version of DAHDI-linux included, and the version number to the right of the plus sign is the DAHDI-tools version included. There are also FreeBSD drivers for DAHDI, which are maintained by the community.

These drivers are available. Another dependency is required for installing DAHDI, and that is the kernel source. It is important that the kernel version being used match exactly that of the kernel source being installed. You can use uname -a to verify the currently running kernel version.

• CentOS: sudo yum install kernel-devel-`uname -r` • Ubuntu: sudo apt-get install linux-headers-`uname -r` The use of uname -r surrounded by backticks ( `) is for filling in the currently running kernel version so the appropriate package is installed. The following commands show how to install DAHDI-linux-complete 2.4.0+2.4.0. There may be a newer version available by the time you are reading this, so check downloads.asterisk.org first.

If there is a newer version available, just replace the version number in the commands: $ cd ~/src/asterisk-complete/ $ mkdir dahdi $ cd dahdi/ $ svn co 2.4.0+2.4.0 $ cd 2.4.0+2.4.0 $ make $ sudo make install $ sudo make config. Setting File Permissions In order to run our system more securely, we’ll be installing Asterisk and then running it as the asteriskpbx user. After installing the files into their default locations, we need to change the file permissions to match those of the user we’re going to be running as. Base Configuration Now that we’ve got Asterisk installed, we can get our system up and running. The purpose here is to get Asterisk loaded up and ready to go, as it isn’t doing anything useful yet. These are the steps that all system administrators will need to start out with when installing a new system. If the commands that need to be run differ on CentOS and Ubuntu, you will see a table with rows labeled for each distribution; otherwise, you will see a single command that should be run regardless of which Linux distribution you have chosen.

Note This section applies only to CentOS users, so if you’re using Ubuntu, you can skip to the next section. In CentOS, the Security-Enhanced Linux (SELinux) system is enabled by default, and it often gets in the way of Asterisk. Sometimes the issues are quite subtle, and at least one of the authors has spent a good number of hours debugging issues in Asterisk that turned out to be resolved by disabling SELinux. There are many articles on the Internet that describe the correct configuration of SELinux, but we’re going to disable it for the sake of simplicity. Note While disabling SELinux is not the ideal situation, the configuration of SELinux is beyond the scope of this book, and frankly, we just don’t have enough experience with it to configure it correctly.

To temporarily switch off SELinux, perhaps in order to verify whether an issue you’re having is being caused by SELinux, run the following command as root: $ sudo echo 0 >/selinux/enforce You can reenable SELinux by doing the same thing, but replacing the 0 with a 1: $ sudo echo 1 >/selinux/enforce To disable SELinux permanently, modify the /etc/selinux/config file: $ cd /etc/selinux/ $ sudo vim config Change the SELINUX option from enforcing to disabled. Note Alternatively, you can change the value of enforcing to permissive, which simply logs the errors instead of enforcing the policy. When you’re done modifying the configuration file, you’ll have the following: # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled.

SELINUX=disabled # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted # SETLOCALDEFS= Check local definition changes SETLOCALDEFS=0 Since you can’t disable SELinux without rebooting, you’ll need to do that now: $ sudo reboot.

Initial Configuration In order to get Asterisk up and running cleanly, we need to create some configuration files. We could potentially install the sample files that come with Asterisk (by executing the make samples command in our Asterisk source) and then modify those files to suit our needs, but the make samples command installs many sample files, most of them for modules that you will never use. We want to limit which modules we are loading, and we also believe that it’s easier to understand Asterisk configuration if you build your config files from scratch, so we’re going to create our own minimal set of configuration files. [] The first thing we need to do (assuming it does not already exist) is create the /etc/asterisk/ directory where our configuration files will live: $ sudo mkdir /etc/asterisk/ $ sudo chown asteriskpbx:asteriskpbx /etc/asterisk/. Using make samples to Create Sample Configuration Files for Future Reference Even though we are not going to use the sample configuration files that come with Asterisk, the fact is that they are an excellent reference. If there is a module that you are not currently using but wish to put into production, the sample file will show you exactly what syntax to use, and what options are available for that module.

Running the sudo make samples command in your Asterisk source directory [] is harmless on a new system that has just been built, but it is very dangerous to run on a system that already has configuration files, as this command will overwrite any existing files (which would be a disaster for you if you do not have a current backup). If you’ve run the sudo make samples command, you will want to move the files that it has created in /etc/asterisk/ to another folder.

We like to create a folder called /etc/asterisk/unused/ and put any sample/unused configuration files in there, but feel free to store them wherever you like. We’re now going to step through all the files that are required to get a simple Asterisk system up and running. Indications.conf and asterisk.conf The first file needed is indications.conf, a file that contains information about how to detect different telephony tones for different countries.

There is a perfectly good sample file that we can use in the Asterisk source, so let’s copy it into our /etc/asterisk/ directory: $ cp ~/src/asterisk-complete/asterisk/1.8/configs/indications.conf.sample /etc/asterisk/indications.conf Because we’re running Asterisk as non-root, we need to tell Asterisk which user to run as. This is done with the asterisk.conf file. We can copy a sample version of it from the Asterisk source to /etc/asterisk: $ cp ~/src/asterisk-complete/asterisk/1.8/configs/asterisk.conf.sample /etc/asterisk/asterisk.conf The asterisk.conf file contains many options that we won’t go over here (they are covered in ), but we do need to make an adjustment. Near the end of the [options] section, there are two options we need to enable: runuser and rungroup. Open the asterisk.conf file with an editor such as nano or vim: Uncomment the runuser and rungroup lines, and modify them so that they each contain asteriskpbx as the assigned value.

Open the /etc/asterisk/asterisk.conf file with vim: $ vim /etc/asterisk/asterisk.conf Then modify the file by uncommenting the two lines starting with runuser and rungroup and modifying the value to asteriskpbx. Runuser= asteriskpbx rungroup= asteriskpbx We now have all the configuration files required to start a very minimal version of Asterisk. [] Give it a shot by starting Asterisk up in the foreground: $ /usr/sbin/asterisk -cvvv.

Tip We are specifying the full path to the asterisk binary, but if you modify your PATH system variable to include the /usr/sbin/ directory you don’t need to specify the full path. See for information about modifying the $PATH environment variable. Asterisk will start successfully without any errors or warnings (although it does warn you that some files are missing), and present to you the Asterisk command-line interface (CLI). At this point there are no modules, minimal core functionality, and no channel modules with which to communicate, but Asterisk is up and running. Executing the module show command at the Asterisk CLI shows that there are no external modules loaded: *CLI>module show Module Description Use Count 0 modules loaded We’ve done this simply to demonstrate that Asterisk can be run in a very minimal state, and doesn’t require the dozens of modules that a default install will enable. Let’s stop Asterisk with the core stop now CLI command: *CLI>core stop now. The Asterisk Shell Command Asterisk can be run either as a daemon or as an application.

In general, you will want to run it as an application when you are building, testing, and troubleshooting, and as a daemon when you put it into production. The command to start Asterisk is the same regardless of whether you’re running it as a daemon or an application: asterisk However, without any arguments, this command will assume certain defaults and start Asterisk as a background application. In other words, you never want to run the command asterisk on its own, but rather will want to pass some options to it to better define the behavior you are looking for. The following list provides some examples of common usages. H This command displays a helpful list of the options you can use. For a complete list of all the options and their descriptions, run the command man asterisk.

-c This option starts Asterisk as an application (in the foreground). This means that Asterisk is tied to your user session. In other words, if you close your user session by logging out or losing the connection, Asterisk dies. This is the option you will typically use when building, testing, and debugging, but you would not want to use this option in production. If you started Asterisk in this manner, type core stop now at the CLI prompt to stop Asterisk and exit.

-v, -vv, -vvv, -vvvv, etc. This option can be used with other options (e.g., -cvvv) in order to increase the verbosity of the console output. It does exactly the same thing as the CLI command core set verbose n where n is any integer between 0 and 5 (any integer greater than 5 will work, but will not provide any more verbosity). Sometimes it’s useful to not set the verbosity at all. For example, if you are looking to see only startup errors, notices, and warnings, leaving verbosity off will prevent all the other startup messages from being displayed. -d, -dd, -ddd, -dddd, etc. This option can be used in the same way as -v, but instead of normal output, this will specify the level of debug output (which is primarily useful for developers who wish to troubleshoot problems with the code).

You will also need to enable output of debugging information in the logger.conf file (which we will cover in more detail in ). -r This command is essential if you want to connect to the CLI of an Asterisk process running as a daemon. You will probably use this option more than any other for Asterisk systems that are in production. This option will only work if you have a daemonized instance of Asterisk already running. To exit the CLI when this option has been used, type exit.

-T This option will add a timestamp to CLI output. -x This command allows you to pass a string to Asterisk that will be executed as if it had been typed at the CLI. As an example, to get a quick listing of all the channels in use without having to start the Asterisk console, simply type asterisk -rx 'core show channels' from the shell, and you’ll get the output you are looking for. -g This option instructs Asterisk to dump a core file if it crashes. We recommend you try out a few combinations of these commands to see what they do.

Modules.conf So, we’ve managed to get Asterisk running, but it’s not able to do anything useful for us yet. To tell Asterisk what modules we expect it to load, we’ll need a modules.conf file. Create the file modules.conf in your /etc/asterisk/ directory with the following command (replace the >>with >if you instead want to overwrite an existing file): $ cat >>/etc/asterisk/modules.conf Type (or paste) the following lines, and press Ctrl+ D on a new line when you’re finished:; The modules.conf file, used to define which modules Asterisk should load (or; not load).; [modules] autoload=yes. • Use the cat program to redirect output to the file you want (use >>to append, or >to overwrite). • Paste or type the content you want to add to the file. • Press Ctrl+ D to complete your changes. File created and content added.

The autoload=yes line will tell Asterisk to automatically load all modules located in the /usr/lib/asterisk/modules/ directory. If you wanted to, you could leave the file like this, and Asterisk would simply load any modules it found in the modules folder. With your new modules.conf file in place, starting Asterisk will cause a whole slew of modules to be loaded. You can verify this by starting Asterisk and running the module show command: $ asterisk -c *CLI>module show Module Description Use Count res_speech.so Generic Speech Recognition API 0 res_monitor.so Call Monitoring Resource 0. Func_math.so Mathematical dialplan function 0 171 modules loaded We now have many modules loaded, and many additional dialplan applications and functions at our disposal. We don’t need all these resources loaded, though, so let’s filter out some of the more obscure modules that we don’t need at the moment. Musiconhold.conf The musiconhold.conf file defines the classes for music on hold in your Asterisk system.

By defining different classes, you can specify different hold music to be used in various situations, such as different announcements to be played while holding in a queue, or different hold music if you have multiple PBXs hosted on the same system. For now, we’ll just create a default music on hold class so that we have at a minimum some hold music when placing callers on hold: $ cd /etc/asterisk/ $ cat >>musiconhold.conf; musiconhold.conf [default] mode=files directory=moh Ctrl+ D We’ve created a musiconhold.conf file and defined our [default] hold music class. We’re also assuming you installed the hold music from the menuselect system; by default there is at least one music on hold package installed, so unless you disabled it, you should have music in at least one format. Additional information about musiconhold.conf can be found in the section. Make menuselect menuselect is a text-based menu system in Asterisk used to configure which modules to compile and install.

The modules are what give Asterisk its power and functionality. New modules are constantly being created. In the installation sections, we conveniently skipped over using the menuselect system in order to keep the instructions simple and straightforward.

However, it is important enough that we have given menuselect its own section. In addition to specifying which modules to install, menuselect also allows you to set flags that can aid in debugging issues (see ), set optimization flags, choose different sound prompt files and formats, and do various other nifty things. Uses for menuselect We would need a whole chapter in order to fully explore menuselect, and for the most part you won’t need to make many changes to it.

However, the following example will give you an idea of how menuselect works, and is recommend for any installation. By default Asterisk only installs the core sound prompt files, and only in GSM format. Also, the three music on hold files available for download are only selected in.wav format. [] We’re going to want extra sound prompts installed instead of just the default core sound prompts, and in a better-sounding format than GSM. We can do this with the menuselect system by running make menuselect in the Asterisk source directory.

Before exploring that, though, let’s talk about the different menuselect interfaces. Tip The minimum screen size for the curses interface is 80x27, which means it may not load if you’re using the default terminal size for a simple distribution installation.

This is not a problem when you’re using SSH to reach the server remotely, as typically your terminal can be resized, but if you’re working at the terminal directly you may need to have screen buffers installed to enable a higher resolution, which is not recommended for a system running Asterisk. The solution is to use the newt-based menuselect system. Using menuselect Run the following commands to start menuselect: $ cd ~/src/asterisk-complete/asterisk/1. Rar Passport Knacker Boerse Im. 8. / $ make menuselect You will be presented with a screen such as that in. You can use the arrow keys on your keyboard to move up and down. The right arrow key will take you into a submenu, and the left arrow key will take you back.

You can use the space bar or Enter key to select and deselect modules. Pressing the q key will quit without saving, while the x key will save your selections and then quit.

Module Dependencies Modules that have XXX in front of them are modules that cannot be compiled because the configure script was not able to find the dependencies required (for example, if you don’t have the unixODBC development package installed, you will not be able to compile func_odbc []). Whenever you install a dependency, you will always need to rerun configure before you run menuselect, so that the new dependency will be properly located. The dependant module will at that point be available in menuselect.

If the module selection still contains XXX, either the configure script is still unable to find the dependency or not all dependencies have been satisfied. Once you’ve started menuselect, scroll down to Core Sound Packages and press the right arrow key (or Enter) to open the menu. You will be presented with a list of available options. These options represent the core sound files in various languages and formats. By default, the only set of files selected is CORE-SOUNDS-EN-GSM, which is the English-language Core Sounds package in GSM format.

Select CORE-SOUNDS-EN-WAV and CORE-SOUNDS-EN-ULAW (or ALAW if you’re outside of North America or Japan []), and any other sound files that may be applicable in your network. Note The reason we have multiple formats for the same files is that Asterisk can play back the appropriate format depending on which codec is negotiated by an endpoint. This can lower the CPU load on a system significantly. After selecting the appropriate sound files, press the left arrow key to go back to the main menu. Then scroll down two lines to the Extra Sound Packages menu and press the right arrow key (or Enter). You will notice that by default there are no packages selected.

As with the core sound files, select the appropriate language and format to be installed. A good option is probably to install the English sound files in the WAV, ULAW, and ALAW formats. Once you’ve completed selecting the sound files, press the x key to save and exit menuselect. You then need to install your new prompts by downloading them from the Asterisk downloads site. This is done simply by running make install again: $ sudo make install $ sudo chown -R asteriskpbx:asteriskpbx /var/lib/asterisk/sounds/ The files will be downloaded, extracted, and installed into the appropriate location ( /var/lib/asterisk/sounds// by default).

Your Asterisk server will need to have a working Internet connection in order to retrieve the files. Note When we say updating your system, that is quite different from upgrading your system. Updating your system is the process of installing new minor versions of the same branch. For example, if your system is running Asterisk 1.8.2 and you need to upgrade to the latest bug fix version for the 1.8 branch, which was version 1.8.3, you’d be updating your system to 1.8.3. In contrast, we use the term upgrade to refer to changes between Asterisk branches (major version number increases). So, for example, an upgrade would be going from Asterisk 1.4.34 to Asterisk 1.8.0. When performing an update, you follow the same instructions outlined in the section.

Tip Additionally, if you’ve checked out a new directory for this version of Asterisk (versus running svn up on a checked-out branch), and previously used menuselect to tweak the modules to be compiled, you can copy the menuselect.makeopts file from one directory to another prior to running./configure. By copying menuselect.makeopts from the old version to the new version, you save the step of having to (de)select all your modules again. The basic steps are: $ cd ~/src/asterisk-complete/asterisk/1.8. / $./configure $ make $ make install. Tip You don’t need to run sudo make install because we’ve already set the directory ownership to the asteriskpbx user. You should be able to install new files directly into the appropriate directories.

Upon installation, however, you may get a message like the following: WARNING WARNING WARNING Your Asterisk modules directory, located at /usr/lib/asterisk/modules contains modules that were not installed by this version of Asterisk. Please ensure that these modules are compatible with this version before attempting to run Asterisk.

Chan_mgcp.so chan_oss.so chan_phone.so chan_skinny.so chan_skype.so codec_g729a.so res_skypeforasterisk.so WARNING WARNING WARNING This warning message is indicating that modules installed in the /usr/lib/asterisk/modules/ directory are not compatible with the version you’ve just installed. This most often occurs when you have installed modules in one version of Asterisk, and then installed a new version of Asterisk without compiling those modules (as the installation process will overwrite any modules that existed previously, replacing them with their upgraded versions). To get around the warning message, you can clear out the /usr/lib/asterisk/modules/ directory prior to running make install. There is a caveat here, though: if you’ve installed third-party modules, such as commercial modules from Digium (including chan_skype, codec_g729a, etc.), you will need to reinstall those if you’ve cleared out your modules directory. It is recommended that you keep a directory with your third-party modules in it that you can reinstall from upon update of your Asterisk system. So, for example, you might create the /usr/src/asterisk-complete/thirdparty/1.8 directory as follows: $ cd ~/src/asterisk-complete/ $ mkdir thirdparty/ $ mkdir thirdparty/1.8/ Downloading third-party modules into this directory allows you to easily reinstall those modules when you upgrade.

Just follow the installation instructions for your module, many of which will be as simple as rerunning make install from the modules source directory or copying the precompiled binary to the /usr/lib/asterisk/modules/ directory. Upgrading Asterisk Upgrading Asterisk between major versions, such as from 1.2 to 1.4 or from 1.6.2 to 1.8 is akin to upgrading an operating system. Once a phone switch is in production, it is terribly disruptive for that system to be unavailable for nearly any length of time, and the upgrade of that phone system needs to be well thought-out, planned, and tested as much as possible prior to deployment. And because every deployment is different, it is difficult, if not impossible, for us to walk you through a real system upgrade. However, we can certainly point you in the right direction for the information you require in order to perform such an upgrade, thereby giving you the tools you need to be successful. A production Asterisk system should never be upgraded between major versions without first deploying it into a development environment where the existing configuration files can be tested and reviewed against new features and syntax changes between versions. For example, it may be that your dialplan relies on a deprecated command and should be updated to use a new command that contains more functionality, has a better code base, and will be updated on a more regular basis.

Commands that are deprecated are typically left in the code for backward-compatibility, but issues reported about these deprecated commands will be given lower priority than issues to do with the newer preferred methods. There exist two files that should be read prior to any system upgrade: CHANGES and UPGRADE.txt, which are shipped with the Asterisk source code. These files contain details on changes to syntax and other things to be aware of when upgrading between major versions. The files are broken into different sections that reference things such as dialplan syntax changes, channel driver syntax changes, functionality changes, and deprecation of functionality, with suggestions that you update your configuration files to use the new methods.

Another thing to consider when performing an upgrade is whether you really need to perform the upgrade in the first place. If you’re using a long-term support (LTS) [] version of Asterisk and that version is happily working along for you, perhaps there is no reason to upgrade your existing production system. An alternative to upgrading the entire system is simply to add functionality to your system by running two versions simultaneously on separate systems. By running separate boxes, you can access the functionality added to a later version of Asterisk without having to disrupt your existing production system. You can then perform the migration more gradually, rather than doing a complete system upgrade instantly.

Two parts of Asterisk should be thoroughly tested when performing an upgrade between major versions: the Asterisk Manager Interface (AMI) and the Asterisk Gateway Interface (AGI). These two parts of Asterisk rely on testing your code to make sure any cleanup of syntax changes in either the AMI or the AGI, or added functionality, does not interfere with your existing code. By performing a code audit on what your program is expecting to send or receive against what actually happens, you can save yourself a headache down the road.

The testing of call detail records (CDRs) is also quite important, especially if they are relied upon for billing. The entire CDR structure is really designed for simple call flows, but it is often employed in complex call flows, and when someone reports an issue to the tracker and it is fixed, it can sometimes have an effect on others who are relying on the same functionality for different purposes.

Asterisk 1.8 now includes channel event logging (CEL), which is a system designed to get around some of the limitations of CDR in more complex call flows (such as those that involve transfers, etc.). More information about CEL is available in. Upgrading Asterisk can be a successful endeavor as long as sufficient planning and testing are carried out prior to the full rollout.

In some cases migrating to a separate physical machine on which you’ve performed testing is preferred, as it can give you a system to roll back to in case of some failure that can’t be resolved immediately. It’s the planning, and particularly having a backup plan, that is the most important aspect of an Asterisk upgrade.

Conclusion In this chapter we looked at how to install an operating system (one of Ubuntu or CentOS) and Asterisk itself. We did this securely by installing via sudo and running Asterisk as the non-root user asteriskpbx. We are well on our way to building a functional Asterisk system that will serve us well. In the following chapters we will explore how to connect devices to our Asterisk system in order to start placing calls internally and how to connect Asterisk to outside services in order to place phone calls to endpoints connected to the PSTN and accept calls from those endpoints.

Option Value/Example Notes astetcdir /etc/asterisk The location where the Asterisk configuration files are stored. Astmoddir /usr/lib/asterisk/modules The location where loadable modules are stored. Astvarlibdir /var/lib/asterisk The base location for variable state information used by various parts of Asterisk. This includes items that are written out by Asterisk at runtime. Astdbdir /var/lib/asterisk Asterisk will store its internal database in this directory as a file called astdb. Astkeydir /var/lib/asterisk Asterisk will use a subdirectory called keys in this directory as the default location for loading keys for encryption.

Astdatadir /var/lib/asterisk This is the base directory for system-provided data, such as the sound files that come with Asterisk. Astagidir /var/lib/asterisk/ agi-bin Asterisk will use a subdirectory called agi-bin in this directory as the default location for loading AGI scripts. Astspooldir /var/spool/asterisk The Asterisk spool directory, where voicemail, call recordings, and the call origination spool are stored. Astrundir /var/run/asterisk The location where Asterisk will write out its UNIX control socket as well as its process ID (PID) file. Astlogdir /var/log/asterisk The directory where Asterisk will store its log files.

Option Value/Example Notes verbose 3 Sets the default verbose setting for the Asterisk logger. This value is also set by the -v command-line option. The verbose level is 0 by default. Debug 3 Sets the default debug setting for the Asterisk logger. This value is also set by the -d command-line option.

The debug level is 0 by default. Alwaysfork yes Forking forces Asterisk to always run in the background. This option is set to no by default. Nofork yes Forces Asterisk to always run in the foreground. This option is set to no by default. Quiet yes Quiet mode reduces the amount of output seen at the console when Asterisk is run in the foreground. This option is set to no by default.

Timestamp yes Adds timestamps to all output except output from a CLI command. This option is set to no by default. Execincludes yes Enables the use of #exec in Asterisk configuration files. This option is set to no by default.

Console yes Runs Asterisk in console mode. Asterisk will run in the foreground and will present a prompt for CLI commands. This option is set to no by default. Highpriority yes Runs the Asterisk application with real-time priority. This option is set to no by default. Initcrypto yes Loads keys from the astkeydir at startup. This option is set to no by default.

[] nocolor yes Suppresses color output from the Asterisk console. This is useful when saving console output to a file. This option is set to no by default.

Dontwarn yes Disables a few warning messages. This option was put in place to silence warnings that are generally correct, but may be considered to be so obvious that they become an annoyance. This option is set to no by default. Dumpcore yes Tells Asterisk to generate a core dump in the case of a crash.

This option is set to no by default. [] languageprefix yes Configures how the prompt language is used in building the path for a sound file. By default, this is yes, which places the language before any subdirectories, such as en/digits/1.gsm. Setting this option to no causes Asterisk to behave as it did in previous versions, placing the language as the last directory in the path, (e.g. Internal_timing yes Uses a timing source to synchronize audio that will be sent out to a channel in cases such as file playback or music on hold.

This option is set to yes by default and should be left that way; its usefulness has greatly diminished over the last few major versions of Asterisk. Systemname my_ system _name Gives this instance of Asterisk a unique name. When this has been set, the system name will be used as part of the uniqueid field for channels. This is incredibly useful if more than one system will be logging CDRs to the same database table.

By default, this option is not set. Autosystemname yes Automatically sets the system name by using the hostname of the system. This option is set to no by default. Maxcalls 100 Sets a maximum number of simultaneous inbound channels.

No limit is set by default. Maxload 0.9 Sets a maximum load average.

If the load average is at or above this threshold, Asterisk will not accept new calls. No threshold is set by default. Maxfiles 1000 Set the maximum number of file descriptors that Asterisk is allowed to have open.

The default limit imposed by the system is commonly 1024, which is not enough for heavily loaded systems. It is common to set this limit to a very high number. The default system-imposed limit is used by default.

Minmemfree 1 Sets the minimum number of megabytes of free memory required for Asterisk to continue accepting calls. If Asterisk detects that there is less free memory available than this threshold, new calls will not be accepted.

This option is not set by default. Cache_record_files yes When doing recording, stores the file in the record_cache_dir until recording is complete. Once complete, it will be moved into the originally specified destination. The default for this option is no.

Record_cache_dir /tmp Sets the directory to be used when cache_record_files is set to yes. The default location is a directory called tmp within the astspooldir. Transmit_silence yes Transmits silence to the caller in cases where there is no other audio source. This includes call recording and the Wait() family of dialplan applications, among other things.

The default for this option is no. [] transcode_via_sln yes When building a codec translation path, forces signed linear to be one of the steps in the path.

The default for this option is yes. Runuser asterisk Sets the system user that the Asterisk application should run as. This option is not set by default, meaning that the application will continue to run as the user that executed the application.

Rungroup asterisk Sets the system group that the Asterisk application should run as. This option is not set by default. Lightbackground yes When using colors in the Asterisk console, it will output colors that are compatible with a light-colored background. This option is set to no by default, in which case Asterisk uses colors that look best on a black background.

Documentation_language en_US The built-in documentation for Asterisk applications, functions, and other things is included in an external XML document. This option specifies the preferred language for documentation. If it is not available, the default of en_US will be used. Hideconnect yes Setting this option to yes causes Asterisk to not display notifications of remote console connections and disconnections at the Asterisk CLI. This is useful on systems where there are scripts that use remote consoles heavily.

The default setting is no. Lockconfdir no When this option is enabled, the Asterisk configuration directory will be protected with a lock. This helps protect against having more than one application attempting to write to the same file at the same time. The default value is no.

Option Value/Example Notes pbx_realtime 1.6 In versions earlier than Asterisk 1.6. X, the pbx_realtime module would automatically convert pipe characters into commas for arguments to Asterisk applications.

This is no longer done by default. To enable this previous behavior, set this option to 1.4. Res_agi 1.6 In versions earlier than Asterisk 1.6. X, the EXEC AGI command would automatically convert pipe characters into commas for arguments to Asterisk applications.

This is no longer done by default. To enable this previous behavior, set this option to 1.4. App_set 1.6 Starting with the Asterisk 1.6.

X releases, the Set() application only allows setting the value of a single variable. Previously, Set() would allow setting more than one variable by separating them with a &. This was done to allow any characters in the value of a variable, including the & character, which was previously used as a separator. MSet() is a new application that behaves like Set() used to. However, setting this option to 1.4 makes Set() behave like MSet().

Modules.conf This file is not strictly required in an Asterisk installation; however, without any modules Asterisk won’t really be able to do anything, so for all practical purposes, you need a modules.conf file in your /etc/asterisk folder. If you simply define autoload=yes in your modules.conf file, Asterisk will search for all modules in the /usr/lib/asterisk/modules folder and load them at startup. Although most modules do not use much in the way of resources, and they all load very quickly, it just seems cleaner to our minds to load only those modules that you are planning on using in your system. Additionally, there are security benefits to not loading modules that accept connections over a network. In the past we felt that explicitly loading each desired module was the best way to handle this, but we have since found that this practice creates extra work. After every upgrade we found ourselves having to edit the modules.conf file to correct all the module differences between releases, and the whole process ended up being needlessly complicated.

What we prefer to do these days is to allow Asterisk to automatically load the modules that it finds, but to explicitly tell Asterisk not to load any modules we do not want loaded by use of the noload directive. A sample modules.conf file can be found in.

Using menuselect to Control Which Modules Are Compiled and Installed One other way that you can control which modules Asterisk loads is to simply not compile and install them in the first place. During the Asterisk installation process, the make menuselect command provides you with a menu interface that allows you to specify many different directives to the compiler, including which modules to compile and install. If you never compile and install a module, the effect of this at load time is that it won’t exist, and therefore won’t be loaded.

If you are new to Linux and Asterisk, this may create confusion for you if you later want to use a module and discover that it doesn’t exist on your system. More information about menuselect is available in.

Option Value/Example Notes autoload yes Instead of explicitly listing which modules to load, you can use this directive to tell Asterisk to load all modules that it finds in the modules directory, with the exception of modules listed as not to be loaded using the noload directive. The default, and our recommendation, is to set this option to yes. Preload res_odbc.so Indicates that a module should be loaded at the beginning of the module load order. This directive is much less relevant than it used to be; modules now have a load priority built into them that solves the problems that this directive was previously used to solve. Load chan_sip.so Defines a module that should be loaded. This directive is only relevant if autoload is set to no.

Noload chan_alsa.so Defines a module that should not be loaded. This directive is only relevant if autoload is set to yes. Require chan_sip.so Does the same thing as load; additionally, Asterisk will exit if this module fails to load for some reason. Preload-require res_odbc.so Does the same thing as preload; additionally, Asterisk will exit if this module fails to load for some reason. Indications.conf The sounds that people expect from the telephone network vary in different parts of the world. Different countries or regions present different sounds for events such as dialtone, busy signal, ringback, congestion, and so forth.

The indications.conf file defines the parameters for the various sounds that a telephone system might be expected to produce, and allows you to customize them. In the early days of Asterisk this file only contained sounds for a limited number of countries, but it is now quite comprehensive. To assign the tones common for your region to channels, you can simply assign the tonezone using the CHANNEL() function, and that tonezone will apply for the duration of the call (unless changed later): Set(CHANNEL(tonezone)=[yourcountry]); i.e., uk, de, etc. However, since signaling from a call could come from various places (from the carrier, from Asterisk, or even from the set itself), you should note that simply setting the tonezone in your dialplan does not guarantee that those tones will be presented in all situations.

Hacking indications.conf for Fun and Profit If you have too much time on your hands, you can do all sorts of pointless but entertaining things with your indications. For example, fans of Star Wars can make the following change to the end of their indications.conf files: [starwars](us) description = Star Wars Theme Song ring = 262/400,392/500,0/100,349/400,330/400,294/400,524/400,392/500,0/100,349/400, 330/400,294/400,524/400,392/500,0/100,349/400,330/400,349/400,294/500,0/2000 If you then use the country named ' starwars' in your configuration files or dialplan, any ringing you pass back will sound quite different from the standard ring you are used to. Try the following dialplan code to test out your new ringing sound: exten =>500,1,Answer() same =>n,Set(CHANNEL(tonezone)=starwars) same =>n,Dial(SIP/0000FFFF0002); or whatever your channel is named in sip.conf.

Note Depending on the type of device used to call into this example, you may wonder if it will actually work. SIP phones, for example, typically generate their own tones instead of having Asterisk generate them. This example was carefully crafted to ensure that Asterisk will generate a ringback tone to the caller. The key is the Answer() that is executed first. Later, when an outbound call is made to another device, the only method Asterisk has available to pass back a ringing indication to the caller is by generating inband audio, since as far as the caller’s phone is concerned, this call has already been answered. While Asterisk will run without an indications.conf file, it is strongly recommended that you include one: copy the sample over with sudo cp ~/src/asterisk-complete/1.8/configs/indications.conf.sample, modify the country parameter in the [general] section to match your region, and restart Asterisk.

Musiconhold.conf If you plan on selling Asterisk-based telephone systems and you do not change the default music on hold that ships with Asterisk, you are sending the message, loud and clear, that you don’t really know what you are doing. [] Part of the problem with music on hold is that while in the past it was common to just plug a radio or CD player into the phone system, the legal reality is that most music licenses do not actually allow you to do this. That’s right: if you want to play music on hold, somebody, somewhere, typically wants you to pay them for the privilege. So how to deal with this? There are two legal ways: 1) pay for a music on hold license from the copyright holder, or 2) find a source of music that is released under a license suitable for Asterisk. We’re not here to give you legal advice; you are responsible for understanding what is required of you in order to use a particular piece of music as your music on hold source. What we will do, however, is show you how to take the music you have and make it work with Asterisk.

Converting Music to a Format That Works Best with Asterisk It’s quite common to have music in MP3 format these days. While Asterisk can use MP3s as a music source, this method is not at all ideal. MP3s are heavily compressed, and in order to play them the CPU has to do some serious work to decompress them in real time. This is fine when you are only playing one song and want to save space on your iPod, but for music on hold, the proper thing to do is convert the MP3 to a format that is easier on the CPU. CentOS Prerequisite Since CentOS does not have MP3 capability installed with sox, you will have to install mpg123 before you can convert MP3 files for use with Asterisk.

First you will need to install the rpmforge repository. To find out which version you need, open your web browser and go to. Select the text for the version/architecture you want to install and paste it into your shell: $ rpm -Uhv You need to make sure this new repository is used correctly, so run the following: $ yum install yum-priorities (If you want to know more about yum priorities, see this site:.) Once the repository has been added, you can proceed to get mpg123: $ yum install mpg123 Once that’s done, your CentOS system is ready to convert MP3 files for use with Asterisk.

If you are familiar with the file formats and have some experience working with audio engineering software such as Audacity, you can convert the files on your PC and upload them to Asterisk. We find it is simpler to upload the source MP3 files to the Asterisk server (say, to the /tmp folder), and then convert them from the command line. To convert your MP3 files to a format that Asterisk understands, you need to run the commands outlined here (in this example we are using a file named SilentCity.mp3).

UpdateStar is compatible with Windows platforms. UpdateStar has been tested to meet all of the technical requirements to be compatible with Windows 10, 8.1, Windows 8, Windows 7, Windows Vista, Windows Server 2003, 2008, and Windows XP, 32 bit and 64 bit editions. Simply double-click the downloaded file to install it. UpdateStar Free and UpdateStar Premium come with the same installer. UpdateStar includes such as English, German, French, Italian, Hungarian, Russian and.

You can choose your language settings from within the program.