Text File Configuration
Once channels are established and communicating between devices and Asterisk; where that data flows to depends on the channel type itself, its overall configuration, device specific configuration, signaling sent by the originating mechanism (a device, a command, an API call) and associated bridges. One or more channels could be talking to one or more channels over various bridges. What specifically Asterisk talks to on each channel is limited only by the technology implemented by the channel driver.
Inbound and Outbound Channels
Often in our documentation, troubleshooting and development discussions you'll see mention of inbound or outbound channels. It'll be helpful to define what that means here.
Inbound channels are channels created when things outside of Asterisk call into Asterisk. This is typically the channel executing Dialplan.
Outbound channels are channels created when Asterisk is calling out to something outside Asterisk.
The primary exception is with Local Channels. In the case of local channels, you'll typically have two local channel legs, one that is treated as outbound and the other as inbound. In this case both are really inside Asterisk, but one is executing dialplan and the other is not. The leg executing dialplan is the one treated as inbound.
Below we'll diagram a few examples for clarity.
The figures have been kept somewhat generic and should apply to most channel types. Each figure shows the final state of the call, rather than a sequence of events.
Below are explanations of the various figures.
One phone dials another phone; about as simple as it gets.
The inbound channel is created from Alice's phone calling Asterisk. Asterisk then calls the extension dialed by Alice by creating an outbound channel to talk to Bob. Once the call is established the two channels are put into a bridgeBridges.
A user runs the originate command from AMI, or maybe something like "channel originate SIP/Alice application playback demo-congrats" from the CLI. Asterisk creates an outbound channel to call the device specified (SIP/Alice). When answered, Asterisk begins treating the channel like an inbound channel and connects it to the specified dialplan application.
Perhaps a user runs originate again - but this time "channel originate SIP/Alice extension [email protected]" from the CLI. Where [email protected] contains dialplan telling Asterisk to dial outbound to SIP/Bob. At first, the created outbound channel would look like Fig 2 where it begins to be treated as inbound after the device answers the call. At that point, a number of things happen:
- Asterisk creates an outbound local channel into Asterisk and bridges it with the now inbound channel to Alice.
- Asterisk creates another leg of local channel as "inbound" into Asterisk to execute the dialplan at the extension specified with the originate. This local channel is essentially bridged with some magic to the other local channel.
- In our case the dialplan executes something like Dial(SIP/Bob), so the new SIP channel is created to communicate with SIP/Bob and is then bridged with the inbound local channel. Now communication flows across the whole path.
For this example demonstrating relationships between channels and other elements we used non-optimized local channels. If the local channels are optimized, then they will optimize themselves out of this mix and Alice and Bob's channels would be bridged together directly.
Channel Variable Inheritance
When working with channels you'll almost certainly be touching channel variables. It is useful to note that upon setting a channel variable the level of inheritance between channels can be defined. This is discussed in the Channel Variables sub-section Variable Inheritance.