Asterisk--part 1

Asterisk

Russell Bryant

Asterisk1 is an open source telephony applications platform distributed under the GPLV2. In short, it's a server application for making, receiving, and performing custom processing of phone calls.

The project was started by Mark Spencer in 1999. Mark had a company called Linux support Services and he needed a phone system to help operate his business. He did not has a lot of money to spend in buying one, so he just made his own. As the popularity of Asterisk grew, Linux support Services shifted focus to Asterisk and changed their name to Digium, Inc.

The name Asterisk comes from the Unix wildcard character * . The goal for the Asterisk project are to do everything telephony. Through pursuing this goal, Asterisk now supports a long list of technologies for making and receiving phone calls. This includes many VoIP (Voice over IP) protocols, as well as both analog and digital connectivity to the traditional tele Phone network, or the PSTN (Public switched telephone network). This ability-to-get many different types of phone calls into and out of the system is one of the Asterisk ' s main strengths.

Once phone calls is made to and from an Asterisk system, there is many additional features that can is used to customize The processing of the phone call. Some features is larger pre-built common applications, such as voicemail. There is other smaller features the can be combined together to create custom voice applications such as playing back a sound file, reading digits, or speech recognition.

1.1. Critical Architectural Concepts

This section discusses some architectural concepts that is critical to all parts of Asterisk. These ideas is at the foundation of the Asterisk architecture.

1.1.1. Channels

A channel in Asterisk represents a connection between the Asterisk system and some telephony endpoint (Figure 1.1). The most common example are when a phone makes a call to an Asterisk system. This connection was represented by a single channel. In the Asterisk code, a channel exists as an instance of the ast_channel data structure. This call scenario could is a caller interacting with voicemail, for example.

Figure 1.1:a Single call Leg, represented to A single Channel

1.1.2. Channel Bridging

Perhaps a more familiar call scenario would be a connection between both phones, where a person using phone a have called a person on phone B. In this call scenario, there is both telephony endpoints connected to the Asterisk system, so the channels exist for this Call (Figure 1.2).

Figure 1.2:two Call Legs represented by and Channels

When Asterisk channels was connected like this, it was referred to as a channel bridge. Channel bridging is the act of connecting channels together for the purpose of passing media between them. The media stream is more commonly an audio stream. However, there may also is a video or a text stream in the call. Even in the case where there are more than one media stream (such as both audio and video), it's still handled by a Channel for each end of the "call" in Asterisk. in figure 1.2, where there is and both channels for phones A and B, the bridge was responsible for passing the media Coming from phone A to phone B, and similarly, for passing the media coming from phone B to phone a. All media streams is negotiated through Asterisk. Anything that Asterisk does not understand and has full control over are not allowed. This means is Asterisk can do recording, audio manipulation, and translation between different.

When the channels is bridged together, there is, the methods that may is used to accomplish this:generic bridging and Native bridging. A Generic bridge is one so works regardless of the what channel technologies am in use. It passes all audio and signalling through the Asterisk abstract channel interfaces. While the flexible bridging method, it's also the least efficient due to the levels of abstraction necessary To accomplish the task. figure 1.2 illustrates a generic bridge.

A native bridge is a technology specific method of connecting channels together. If the channels is connected to Asterisk using the same media transport technology, there could be a-to connect them th At are more efficient than going through the abstraction layers in Asterisk so exist for connecting different technologie S together. For example, if specialized hardware was being used for connecting to the telephone network, it could be possible to bridge t He channels on the hardware so, the media does not has the to flow up through the application at all. In the case of some VoIP protocols, it's possible to has endpoints send their media streams to all other directly, such That's signalling information continues to flow through the server.

The decision between generic bridging and native bridging is doing by comparing the both channels when it's time to bridge them. If both channels indicate that they support the same native bridging method and then that'll be used. Otherwise, the generic bridging method would be used. To determine whether or not both channels support the same native bridging method, a simple C function pointer comparison I S used. It's certainly not the most elegant method, but we had not yet hits any cases where this is not sufficient for our needs. Providing a native bridge function for a channel was discussed in more detail in section 1.2. Figure 1.3 illustrates an example of a native bridge.

Figure 1.3:example of a Native Bridge

Summary: Asterisk uses two modes of transmission, one is client-side interaction through the server, and the other is similar to the original FBT architecture, if the client can be connected through peer-to-peer media transmission.

Asterisk--part 1