Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Building Telephony Systems With Asterisk (2005).pdf
Скачиваний:
45
Добавлен:
17.08.2013
Размер:
1.82 Mб
Скачать

Configuring Asterisk

amaflags: affects the recording of Call Detail Records (CDRs). This variable

can be set to "default", "omit", "billing", or "documentation".

accountcode: we can tie channels to account codes for billing purposes.

adsi: we can set this to "yes" if we have ADSI-compatible handsets.

busydetect: this can be set to "yes" to try to find if lines are hung up or busy.

busycount: this variable sets how many busy tones to hear before hanging

up a channel. The default value is 4, but increasing this may prevent some seemingly random hang-ups.

callprogress: this variable sets whether or not to use the experimental call

progress detection algorithms. One note of warning: this tends to cause random hang-ups. It is probably best to wait until this is more stable to use.

progzone: used in conjunction with callprogress. Set this to "us" for the

United States.

musiconhold: sets which class of music on hold to use.

PRI idle extension: this group of settings can be used to more effectively use

channels on a PRI line. It is often used to multilink through PPP.

idledial: sets the extension to dial from the idle line.

idleext: sets the extension to dump the idle line to.

minunused: sets minimum number of channels to leave unused.

minidle: sets minimum number of channels to leave in the idle extension.

jitterbuffers: default is 4. This is designed to smooth out jitter.

cadence: defining custom ring cadences. Defining any here will cause the

default cadences to be turned off.

channel: this can be a channel or range of channels. These channels must

match those defined in /etc/zaptel.conf.

While there are many options available, we will only need a few of them. And most of them, we can set once and not need to set them again. Usually, the defaults work fine, but at least we know that if we're unhappy with the way our phone systems acts, we can easily configure it to perform the way we wish it to.

For /etc/asterisk/zapata.conf, we have the two major divisions of devices, as we had in zaptel.conf, namely lines and terminals. The definitions are the same as before.

Lines

Once we have set the options above, all we have to do is define the channel number. It is best to set the signaling method within sight of the channel definition so that problems are easier to debug. Supposing we have an FXO device on channel 1, which we want to call group 1, we would have the following lines in our /etc/asterisk/zapata.conf file:

52

Chapter 4

signalling=fxs_ks context=default group=1

channel=1

Grouping these four lines close together in the file will make it easier to troubleshoot any problems in the future.

Suppose we have two PRIs, as we did in the example in the lines section of zaptel.conf file. Our channel definitions could look like:

; incoming PRI callerid=asreceived context=default switchtype=dms100 signalling=pri_cpe group=2 channel=>1-23 channel=>25-47

By putting both of the incoming PRIs together, we saved ourselves some typing. As long as we're happy with both trunks being in the same group, there is no reason why we should have to redefine the variables.

One note on security: we need to be careful what context we put our incoming calls into. If we place them in a context that can dial long distance, then people can relay telephone calls through our server.

Terminals

When defining the channels that our terminal devices connect to, we need to remember to take into consideration more specific details about the uses of the channel. For instance, analog handsets will be unable to send caller ID information, so setting callerid=asreceived does not make much sense.

Furthermore, here is where we have to remember if we are using ADSI devices. While it may be tempting for us to turn on adsi=yes for all lines, it tends to make users angry when they hear some of the high-pitched beeps that sometimes are emitted during conversations. Therefore, we should only enable ADSI on phones that are ADSI compatible.

An example configuration for an FXS device on channel 2 might be:

signalling=fxo_ks context=longdistance

callerid="My Name Here"<(850) 555-5555> adsi=no

callgroup=1

pickupgroup=1

channel=2

As you can see, this phone does not support ADSI, has the correct caller ID set, and has been placed in the call group 1, so that the user can pick up any calls for terminals in the same group. Also, we need to take notice that the line channel=2 appears last.

53