IP Phones for Asterisk. See IP Phones. Asterisk is the 1 open source communications toolkit. Need a Phone System? Build your own custom system with Asterisk? Buy a powerful, low-cost turnkey system based on Asterisk? Discover which option is right for you. Get the Guide. Learn More. Software add-ons for Asterisk are available from Digium and through other vendors.
Asterisk Software. Download Asterisk. Certified Asterisk. Commercial Licensing. Add-On Software Products. Frames are marked with a numerically encoded type and subtype.
Asterisk is a highly modularized application. However, it is not very useful by itself. The core application acts primarily as a module registry.
It also has code that knows how to connect all of the abstract interfaces together to make phone calls work. The concrete implementations of these interfaces are registered by loadable modules at runtime. By default, all modules found in a predefined Asterisk modules directory on the filesystem will be loaded when the main application is started.
This approach was chosen for its simplicity. However, there is a configuration file that can be updated to specify exactly which modules to load and in what order to load them. This makes the configuration a bit more complex, but provides the ability to specify that modules that are not needed should not be loaded. The primary benefit is reducing the memory footprint of the application. However, there are some security benefits, as well.
It is best not to load a module that accepts connections over a network if it is not actually needed. When the module loads, it registers all of its implementations of component abstractions with the Asterisk core application. There are many types of interfaces that modules can implement and register with the Asterisk core. A module is allowed to register as many of these different interfaces as it would like.
Generally, related functionality is grouped into a single module. The Asterisk channel driver interface is the most complex and most important interface available. The Asterisk channel API provides the telephony protocol abstraction which allows all other Asterisk features to work independently of the telephony protocol in use. This component is responsible for translating between the Asterisk channel abstraction and the details of the telephony technology that it implements.
It defines a set of methods that must be implemented by a channel driver. There are many other operations that must be handled in a technology-specific way.
The dialplan is made up of a series of call rules called extensions. When a phone call comes in to the system, the dialed number is used to find the extension in the dialplan that should be used for processing the call.
The extension includes a list of dialplan applications which will be executed on the channel. The applications available for execution in the dialplan are maintained in an application registry. This registry is populated at runtime as modules are loaded. Asterisk has nearly two hundred included applications. The definition of an application is very loose.
Applications can use any of the Asterisk internal APIs to interact with the channel. Some applications do a single task, such as Playback , which plays back a sound file to the caller.
Other applications are much more involved and perform a large number of operations, such as the Voicemail application. Using the Asterisk dialplan, multiple applications can be used together to customize call handling. If more extensive customization is needed beyond what is possible in the provided dialplan language, there are scripting interfaces available that allow call handling to be customized using any programming language.
Even when using these scripting interfaces with another programming language, dialplan applications are still invoked to interact with the channel. Before we get into an example, let's have a look at the syntax of an Asterisk dialplan that handles calls to the number Note that the choice of here is arbitrary.
It invokes three dialplan applications. First, it answers the call. Next, it plays back a sound file. Finally, it hangs up the call. The exten keyword is used to define the extension. On the right side of the exten line, the means that we are defining the rules for when someone calls The next 1 means this is the first step that is taken when that number is dialed.
Finally, Answer instructs the system to answer the call. The next two lines that begin with the same keyword are rules for the last extension that was specified, which in this case is The n is short for saying that this is the next step to take. The last item on those lines specifies what action to take. Here is another example of using the Asterisk dialplan.
In this case, an incoming call is answered. Then, the digits are read back to the caller. Finally, the call is ended. As previously mentioned, the definition of an application is very loose—the function prototype registered is very simple:. Most dialplan applications take a string of arguments. While some values may be hard coded, variables are used in places where behavior needs to be more dynamic.
The following example shows a dialplan snippet that sets a variable and then prints out its value to the Asterisk command line interface using the Verbose application.
Dialplan functions are invoked by using the same syntax as the previous example. Asterisk modules are able to register dialplan functions that can retrieve some information and return it to the dialplan. Alternatively, these dialplan functions can receive data from the dialplan and act on it. As a general rule, while dialplan functions may set or retrieve channel meta data, they do not do any signalling or media processing.
That is left as the job of dialplan applications. The following example demonstrates usage of a dialplan function. First, it prints out the CallerID of the current channel to the Asterisk command line interface. Then, it changes the CallerID by using the Set application. The dialplan function code knows how to set and retrieve the values from these data structures. Another example of using a dialplan function is for adding custom information into the call logs, which are referred to as CDRs Call Detail Records.
The CDR function allows the retrieval of call detail record information, as well as adding custom information. In the world of VOIP, many different codecs are used for encoding media to be sent across networks.
The variety of choices offers tradeoffs in media quality, CPU consumption, and bandwidth requirements. Asterisk supports many different codecs and knows how to translate between them when necessary. When a call is set up, Asterisk will attempt to get two endpoints to use a common media codec so that transcoding is not required.
However, that is not always possible. Even if a common codec is being used, transcoding may still be required. For example, if Asterisk is configured to do some signal processing on the audio as it passes through the system such as to increase or decrease the volume level , Asterisk will need to transcode the audio back to an uncompressed form before it can perform the signal processing.
Asterisk can also be configured to do call recording. If the configured format for the recording is different than that of the call, transcoding will be required. The method used to negotiate which codec will be used for a media stream is specific to the technology used to connect the call to Asterisk.
In some cases, such as a call on the traditional telephone network the PSTN , there may not be any negotiation to do.
0コメント