Asterisk™: будущее телефонии Второе издание
Шрифт:
Убедимся, что мы можем соединяться с нашей базой данных, используя приложение isql. Приложение isql не будет осуществлять соединение как пользователь с правами администратора (root) и должно выполняться под учетной записью владельца базы данных. Поскольку владельцем базы данных asterisk в PostgreSQL является пользователь asterisk, необходимо создать учетную запись Linux с таким же именем. В главе 14 эта учетная запись будет использоваться для запуска Asterisk от лица пользователя, не имеющего прав администратора.
# su - asterisk
$ echo "select 1" | isql -v asterisk-connector
+ +
| Connected! |
| sql-statement
| help [tablename]
| quit |
+ +
SQL> + +
| 'column? + +
I 1
+ +
SQLRowCount returns 1 1 rows fetched $ exit
После
# cd /usr/src/asterisk-1.4
# make distclean
# ./configure
# make menuselect
# make install
Практически все, о чем говорится в данной главе, включено по умолчанию. Выполнив команду make menuselect, убедитесь, что модули, связанные с ODBC, активированы. Сюда относятся cdr_odbc, func_odbc, func_realtime, pbx_realtime, res_config_ odbc, res_odbc. Для хранения голосовой почты в базе данных, совместимой с ODBC, не забудьте выбрать пункт ODBC STORAGE (ХРАНИЛИЩЕ ODBC) в меню Voicemail Build Options (Опции сборки голосовой почты). Чтобы убедиться в существовании модулей, загляните в папку /usr/lib/asterisk/modules/.
Конфигурация res_odbc
для обеспечения доступа к базе данных
Конфигурация ODBC-коннекторов выполняется в файле res_odbc.conf, располагающемся в папке /etc/asterisk. Файл res_odbc.conf задает параметры, которые будут использоваться различными модулями Asterisk для соединения с базой данных [113] .
Внесем изменения в файл res_odbc.conf:
[asterisk]
enabled => yes
113
Опции pooling (создание пула) и limit (предел) довольно полезны для работы с базами данных MS SQL Server и Sybase. Они позволяют устанавливать с базой данных множество соединений (вплоть до limit), гарантируя при этом, что одновременно для каждого соединения выполняется только одно выражение (это обусловлено ограничением в протоколе, используемом этими серверами баз данных).
dsn => asterisk-connector
username => asterisk
password => welcome
pooling => no
limit => 0
pre-connect => yes
Опция dsn указывает на соединение с базой данных, которое мы конфигурировали в файле /etc/odbc.ini, а опция pre-connect говорит Asterisk открыть и обслуживать соединение с базой данных при загрузке модуля res_odbc.so. Это снижает некоторые издержки, которые возникли бы при многократном повторном установлении и разрыве соединения с базой данных.
Сконфигурировав res_odbc.conf, запустите Asterisk и проверьте соединение с базой данных с помощью CLI-команды odbc show:
*CLI> odbc show Name: asterisk DSN: asterisk-connector Pooled: no Connected: yes
Использование архитектуры реального времени
Архитектура реального времени Asterisk (Asterisk Realtime Architecture, ARA) - это метод хранения конфигурационных файлов (которые при обычных обстоятельствах располагались бы в папке /etc/asterisk) и их конфигурационных опций в таблице базы данных. Существует два типа архитектур реального времени: статическая и динамическая. Статический вариант аналогичен традиционному методу чтения конфигурационного файла, за исключением того что чтение данных осуществляется из базы данных. Метод динамической реализации архитектуры реального времени используется для таких элементов, как объекты user и peer (SIP, IAX2) и голосовая почта, которые загружают и обновляют информацию по мере необходимости. Изменение в статической информации требует перезагрузки текстового файла сразу после внесения в него изменений, но динамическая информация запрашивается Asterisk
Статическая архитектура реального времени
Статическая архитектура реального времени используется, если требуется загрузить конфигурацию, которая обычно размещается в конфигурационных файлах в папке /etc/asterisk, из базы данных. Те же правила, которые применяются к плоским [114] файлам в системе, действуют и при использовании статической архитектуры реального времени. Например, требование выполнить команду перезагрузки из интерфейса командной строки Asterisk или перезагрузить модуль, связанный с конфигурационным файлом (то есть выполнить команду module reload chan_sip. so).
114
Плоскими являются двоичные файлы вида ключ-значение. Данные файлы позволяют быстрее осуществлять операции редактирования, добавления и удаления записей благодаря встроенным функциям Asterisk.
– Примеч. науч. ред.
При использовании статической архитектуры реального времени мы указываем Asterisk, какие файлы хотим загрузить из базы данных, используя в файле extconfig.conf следующий синтаксис:
; /etc/asterisk/extconfig.conf filename.conf => драйвер,базаданных[,таблица]
Если имя таблицы не задано, Asterisk будет использовать имя файла.
Использование директивы preload
Большинство файлов можно загружать посредством статической архитектуры реального времени, но несколько файлов не могут быть загружены при использовании этого метода. Это файлы asterisk. conf, extconfig.conf и logger.conf. Кроме того, файлы manager.conf, cdr.conf и rtp.conf не могут загружаться из статической архитектуры реального времени, если драйверы подключения к базе данных не были загружены до запуска основного ядра Asterisk (потому что архитектура реального времени должна загрузить конфигурационные файлы до того, как модуль начнет читать свою конфигурацию). Поскольку в данной главе используется ODBC, в modules.conf пришлось бы добавить следующие строки: ; /etc/asterisk/modules.conf preload => res_odbc.so preload => res_config_odbc.so
Модуль статической архитектуры реального времени читает настройки статических файлов из базы данных, используя особым образом форматированную таблицу. В PostgreSQL таблица для статической архитектуры реального времени создается с помощью следующего запроса:
CREATE TABLE ast_config (
id serial NOT NULL,
cat_metric int4 NOT NULL DEFAULT 0,
var_metric int4 NOT NULL DEFAULT 0,
filename varchar(128) NOT NULL DEFAULT ''::character varying, category varchar(128) NOT NULL DEFAULT 'default'::character varying, var_name varchar(128) NOT NULL DEFAULT ''::character varying, var_val varchar(128) NOT NULL DEFAULT ''::character varying, commented int2 NOT NULL DEFAULT 0, CONSTRAINT ast_config_id_pk PRIMARY KEY (id)
)
WITHOUT OIDS;
Чтобы понимать, как Asterisk применяет строки базы данных для конфигурации различных загружаемых модулей, дадим краткое описание каждого из столбцов:
cat_metric
Значимость категории в рамках файла. Чем ниже значение, тем выше в файле располагается категория (см. врезку «Несколько слов о значениях»).
var_metric
Значимость элемента в рамках категории. Чем ниже значение, тем выше в списке располагается элемент. Применяется, например, для определения порядка расположения кодеков в файле sip.conf или iax.conf, когда требуется, чтобы disallow=all шел первым (значение 0), за ним - allow=ulaw (значение 1), а далее - allow=gsm (значение 2) (см. врезку «Несколько слов о значениях»).