I. Революция в телефонии II. Конфигурация пользовательских устройств III. Основы диалплана IV. Внешние подключения V. Голосовая почта VI. Интернационализация VII. Погружение в диалплан VIII. Парковка, пейджинг и конференц-связь IX. Маршрутизация интернет-вызовов X. Очереди автоматического распределения вызовов (ACD) XI. Состояния устройств XII. Автосекретарь XIII. Интеграция реляционной базы данных XIV. Интерактивное голосовое меню XV. Внешние службы XVI. Fax XVII. Интерфейс управления Asterisk (AMI) XVIII. Интерфейс шлюза Asterisk (AGI) XIX. Кластеризация XX. Распределённое универсальное распознавание номеров (DUNDi) XXI. Системный мониторинг и журналирование XXII. Web-интерфейсы XXIII. Безопасность

Глава 13

Интеграция реляционной базы данных

Нет ничего более раздражающего, чем хороший пример.

— Марк Твен

В этой главе мы рассмотрим интеграцию некоторых возможностей и функций Asterisk в базу данных. Для Linux доступно несколько баз данных, но мы решили ограничить наше обсуждение двумя самыми популярными: PostgreSQL и MySQL.

Мы также объясним, как настроить Linux для подключения к базе данных Microsoft SQL через ODBC; однако конфигурация части Windows/Microsoft выходит за рамки этой книги.

Независимо от того, какую базу данных вы используете, эта глава фокусируется в первую очередь на ODBC-коннекторе, поэтому, если у вас есть некоторое знакомство с подготовкой вашей любимой базы данных ODBC, у вас не должно быть никаких проблем с этой главой.

Интеграция Asterisk с базами данных является одним из фундаментальных аспектов построения крупной кластерной или распределенной системы. Мощь базы данных позволит вам использовать динамически изменяющиеся данные в ваших диалпланах для таких задач, как обмен информацией по массиву систем Asterisk или интеграция с веб-сервисами. Наша любимая функция диалплана, которую мы рассмотрим далее в этой главе — func_odbc.

Хотя не для всех развертываний Asterisk потребуются реляционные базы данных, понимание того, как их использовать, открывает сундук с сокровищами, полный новых способов разработки вашего телекоммуникационного решения.

Установка и настройка PostgreSQL и MySQL

В следующих разделах мы покажем, как устанавливать и настраивать PostgreSQL и MySQL как для RHEL, так и для Ubuntu.¹ Рекомендуется устанавливать только одну базу данных одновременно, работая через этот раздел. Выберите базу данных, которая вам наиболее удобна, так как нет неправильного выбора.

Установка PostgreSQL для RHEL

Следующая команда может быть использована для установки сервера PostgreSQL и его зависимостей с консоли:

$ sudo yum install postgresql-server

…

Install 3 Package(s)

Upgrade 0 Package(s)

Total download size: 6.3 M

Installed size: 29 M

Is this ok [y/N]: y

После установки базы данных вы должны ее инициализировать:

$ sudo service postgresql initdb

Затем запустите базу данных:

$ sudo service postgresql start

Теперь перейдите в раздел «Настройка PostgreSQL» для получения инструкций о том, как выполнить первоначальную настройку.

Установка PostgreSQL для Ubuntu

Чтобы установить PostgreSQL на Ubuntu выполните следующую команду. Вам также будет предложено установить любые дополнительные пакеты зависимостей. Нажмите Enter чтобы принять список зависимостей, после чего пакеты будут установлены, и PostgreSQL будет автоматически запущен и инициализирован:

$ sudo apt-get install postgresql

…

After this operation, 19.1MB of additional disk space will be used.

Do you want to continue [Y/n]? y

Установка MySQL для RHEL

Чтобы установить MySQL на RHEL, выполните следующую команду. Вам будет предложено установить несколько зависимостей. Нажмите Enter чтобы принять, и будет установлен MySQL сервер и зависимости пакетов:

$ sudo yum install mysql-server

…

Install 3 Package(s)

Upgrade 0 Package(s)

Total download size: 9.6 M

Installed size: 27 M

Is this ok [y/N]: y

Затем запустите базу данных MySQL, запустив:

$ sudo service mysqld start

Теперь перейдите в «Настройка MySQL» для выполнения начальной конфигурации.

Установка MySQL для Ubuntu

Для установки MySQL на Ubuntu выполните следующую команду. Вам будет предложено установить несколько зависимостей. Нажмите Enter чтобы согласиться, и MySQL сервер и его пакеты зависимостей будут установлены:

$ sudo apt-get install mysql-server

Need to get 24.0MB of archives.

After this operation, 60.6MB of additional disk space will be used.

Do you want to continue [Y/n]? y

Во время установки вы будете помещены в мастер настройки, чтобы помочь вам с начальной конфигурацией базы данных. Вам будет предложено ввести новый пароль для пользователя root. Введите сложный пароль и нажмите Enter. Затем вас попросят подтвердить пароль. Введите свой сложный пароль еще раз, а затем Enter. Затем вы вернетесь в консоль где будет завершена установка. Теперь будет запущен сервис MySQL.

Теперь перейдите в «Настройка MySQL» для выполнения начальной конфигурации.

Настройка PostgreSQL

Далее создайте пользователя с именем asterisk, которого вы будете использовать для подключения к базе данных и управления ею. Вы можете переключиться на пользователя postgres, используя следующую команду:

$ sudo su — postgres

На момент написания этой статьи в RHEL и Ubuntu используется PostgreSQL версии 8.4.x.

Затем запустите следующие команды для создания пользователя asterisk в базе данных и установите разрешения:

$ createuser -P

Enter name of user to add: asterisk

Enter password for new user:

Enter it again:

Shall the new role be a superuser? (y/n) n

Shall the new user be allowed to create databases? (y/n) y

Shall the new user be allowed to create more new users? (y/n) n

CREATE ROLE

Теперь отредактируйте файл pg_hba.conf, чтобы разрешить пользователю asterisk, которого вы только что создали, подключение к серверу PostgreSQL через сокет TCP/IP.

В RHEL этот файл будет расположен по адресу /var/lib/pgsql/data/pg_hba.conf. На Ubuntu вы найдете его на /etc/postgresql/8.4/main/pg_hba.conf.

В конце файла замените все строки ниже этой:

# TYPE DATABASE USER CIDR-ADDRESS METHOD

на следующее:

# TYPE DATABASE USER CIDR-ADDRESS METHOD

host all asterisk 127.0.0.1/32 md5

local all asterisk trust

Настройка доступа к базе данных PostgreSQL через IPv6 localhost

Кроме того, на Ubuntu вам, скорее всего, придется добавить следующую строку:

host all asterisk ::1/128 md5

Без него при “Проверке ODBC-коннектора» может возникнуть следующая ошибка при подключении:

[28000][unixODBC]FATAL:no pg_hba.conf entry for host «::1», user «asterisk»,

database «asterisk», SSL off

[ISQL]ERROR: Could not SQLConnect

Теперь вы можете создать базу данных, которую мы будем использовать в этой главе. Вызовите базу данных asterisk и установите владельцем вашего пользователя asterisk:

$ createdb —owner = asterisk asterisk

CREATE DATABASE

Вы можете установить пароль для пользователя asterisk следующим образом:

$ psql -d template1

template1=# «ALTER USER asterisk WITH PASSWORD‘password'»

template1=# \q

Выход из пользователя postgres:

$ exit

Затем перезапустите сервер PostgreSQL. В RHEL:

$ sudo service postgresql restart

Вам необходимо перезапустить службу PostgreSQL, потому что вы внесли изменения в pg_hba.conf, а не потому что вы добавили нового пользователя или сменили пароль.

В Ubuntu:

$ sudo /etc/init.d/postgresql restart

Вы можете проверить свое соединение с сервером PostgreSQL через TCP/IP, например:

$ psql -h 127.0.0.1 -U asterisk

Пароль для пользователя asterisk:

Добро пожаловать в psql 9.1 , интерактивный терминал PostgreSQL.

Тип: \copyright для условий распространения

\h для справки по командам SQL

\? для получения помощи по командам psql

\g или terminate с точкой с запятой для выполнения запроса

\q для выхода

asterisk =>

Теперь вы готовы перейти к разделу «Установка и настройка ODBC«.

Настройка MySQL

Теперь, когда база данных MySQL работает, вы должны защитить свою инсталляцию. Удобно, для этого есть скрипт, который вы можете выполнить, что позволит ввести новый пароль² пользователя root наряду с некоторыми дополнительными опциями. Скрипт довольно прост, и после ввода и подтверждения пароля root вы можете продолжать выбирать значения по умолчанию, если у вас нет конкретной причины.

Выполните следующий скрипт:

$ sudo /usr/bin/mysql_secure_installation

Затем подключитесь к консоли базы данных, чтобы вы могли создать своего пользователя asterisk и установить разрешения:

$ mysql -u root -p

Enter password:

После ввода пароля вам будет представлена подсказка mysql в консоли. Теперь вы можете создать своего пользователя asterisk, выполнив команду CREATE USER. % — символ шаблона с указанием пользователя asterisk может подключаться с любого хоста и IDENTIFIED BY паролем some_secret_password (который вы явно должны изменить). Обратите внимание на конечную точку с запятой:

mysql> CREATE USER ‘asterisk’@’%’ IDENTIFIED BY ‘some_secret_password’;

Query OK, 0 rows affected (0.00 sec).

Давайте также создадим исходную базу данных, которую вы будете использовать в этой главе:

mysql> CREATE DATABASE asterisk;

Query OK, 1 rows affected (0.00 sec.)

Теперь, когда вы создали своего пользователя и базу данных, необходимо назначить разрешения для пользователя asterisk для доступа к базе данных asterisk:

mysql> GRANT ALL PRIVILEGES ON asterisk.* TO ‘asterisk’@’%’;

Query OK, 0 rows affected (0.00 sec)

Наконец, выйдите из консоли и убедитесь, что ваши права верны, выполнив вход в базу данных asterisk в качестве пользователя asterisk:

mysql> exit

Bye

# mysql -u asterisk -p asterisk

Enter password:

mysql>

Этот пароль вам понадобится при настройке и тестировании ODBC-коннектора, поэтому сохраните его. Теперь вы готовы перейти к следующему разделу.

Установка и настройка ODBC

ODBC-коннектор представляет собой уровень абстракции базы данных, который позволяет Asterisk обмениваться данными с широким спектром баз данных, не требуя от разработчиков создания отдельного коннектора для каждой поддерживаемой Asterisk базы данных. Это экономит много усилий по разработке и обслуживанию кода. Существует небольшая стоимость производительности, потому что мы добавляем еще один прикладной уровень между Asterisk и базой данных, но это можно смягчить с помощью правильной конструкции и стоимости этого, когда вам нужны мощные и гибкие возможности базы данных в вашей системе Asterisk.

Перед установкой коннектора в Asterisk вам необходимо установить ODBC в сам Linux.

Чтобы установить драйверы ODBC, используйте одну из следующих команд.

На RHEL:

$ sudo yum install unixODBC unixODBC-devel libtool-ltdl libtool-ltdl-devel

На Ubuntu:

$ sudo apt-get install unixODBC unixODBC-dev

См. Главу для просмотра матрицы пакетов, которые вы должны установить.

Вам также потребуется установить unixODBC пакет разработки, поскольку Asterisk использует его для создания модулей ODBC, которые мы будем использовать в этой главе.

Драйверы unixODBC, поставляемые с дистрибутивами, часто отличаются от официально выпущенных версий, доступных на веб-сайте unixODBC.

Если у вас есть проблемы со стабильностью при использовании unixODBC, вам может потребоваться установить из исходников. Просто сначала удалите драйверы unixODBC через диспетчер пакетов, а затем обновите пути в файле /etc/odbcinst.ini.

Чтобы установить ODBC-коннектор MySQL на RHEL:

$ sudo yum install mysql-connector-odbc

Для установки ODBC-коннектора PostgreSQL на RHEL:

$ sudo yum install postgresql-odbc

Для установки ODBC-коннектора PostgreSQLна Ubuntu:

$ sudo apt-get install odbc-postgresql

Или установить ODBC-коннектор MySQL на Ubuntu:

$ sudo apt-get install libmyodbc

Настройка ODBC для PostgreSQL

Конфигурация для драйвера ODBC PostgreSQL выполняется в файле /etc/odbcinst.ini.

В RHEL файл по умолчанию уже содержит некоторые данные, в том числе для PostgreSQL, поэтому просто убедитесь, что данные существуют. Файл будет выглядеть следующим образом:

[PostgreSQL]

Description = ODBC for PostgreSQL

Driver = /usr/lib/psqlodbc.so

Setup = /usr/lib/libodbcpsqlS.so

Driver64 = /usr/lib64/psqlodbc.so

Setup64 = /usr/lib64/libodbcpsqlS.so

FileUsage = 1

В Ubuntu файл /etc/odbcinst.ini будет пустым, поэтому вам нужно будет добавить данные в этот файл конфигурации. Добавьте в odbcinst.ini следующее:

[PostgreSQL]

Description = ODBC for PostgreSQL

Driver = /usr/lib/odbc/psqlodbca.so

Setup = /usr/lib/odbc/libodbcpsqlS.so

FileUsage = 1

В 64-битных системах , вам нужно будет изменить путь библиотек из /usr/lib на /usr/lib64 , чтобы получить доступ к файлам с правильной библиотекой.

В любом случае вы можете использовать cat> /etc/odbcinst.ini для записи чистого файла конфигурации, как это было сделано в других главах. Просто используйте Ctrl + D, чтобы сохранить файл, как только закончите.

Убедитесь, что система видит драйвер, выполнив следующую команду. Она должна вернуть имя метки PostgreSQL, если все хорошо:

$ odbcinst -q -d

[PostgreSQL]

Затем настройте файл /etc/odbc.ini, который используется для создания идентификатора, который Asterisk будет использовать для ссылки на эту конфигурацию. Если в любой момент в будущем вам нужно изменить базу данных на что-то еще, то нужно будет просто изменить этот файл, чтобы Asterisk продолжал указывать на то же место:³

[asterisk-connector]

Description = PostgreSQL connection to ‘asterisk’ database

Driver = PostgreSQL

Database = asterisk

Servername = localhost

Port = 5432

Protocol = 8.1

ReadOnly = No

RowVersioning = No

ShowSystemTables = No

ShowOidColumn = No

FakeOidIndex = No

ConnSettings =

Настройка ODBC для MySQL

Конфигурация для MySQL ODBC-драйвера находится в файле /etc/odbcinst.ini.

В RHEL файл по умолчанию уже содержит некоторые данные, в том числе для MySQL, но он должен быть раскоментирован и требует нескольких изменений. Замените существующий текст следующим:

[MySQL]

Description = ODBC for MySQL

Driver = /usr/lib/libmyodbc5.so

Setup = /usr/lib/libodbcmyS.so

Driver64 = /usr/lib64/libmyodbc5.so

Setup64 = /usr/lib64/libodbcmyS.so

FileUsage = 1

В Ubuntu /etc/odbcinst.ini будет пустым, поэтому вам нужно будет добавить данные в этот файл конфигурации. Добавьте в odbcinst.ini следующее:

[MySQL]

Description = ODBC for MySQL

Driver = /usr/lib/odbc/libmyodbc.so

Setup = /usr/lib/odbc/libodbcmyS.so

FileUsage = 1

В 64-битных системах , вам нужно будет изменить путь библиотек из /usr/lib на /usr/lib64, чтобы получить доступ к файлам с правильной библиотекой.

Убедитесь, что система видит драйвер, выполнив следующую команду. Она должна вернуть имя метки MySQL, если все хорошо:

$ odbcinst -q -d

[MySQL]

Затем настройте файл /etc/odbc.ini, который используется для создания идентификатора, который Asterisk будет использовать для ссылки на эту конфигурацию. Если в любой момент в будущем вам нужно изменить базу данных на что-то еще, то нужно будет просто перенастроить этот файл, чтобы Asterisk продолжал указывать на то же место:

[asterisk-connector]

Description = MySQL connection to ‘asterisk’ database

Driver = MySQL

Database = asterisk

Server = localhost

Port = 3306

Socket = /var/lib/mysql/mysql.sock

Местоположение этого файла может быть другим, поэтому вам может потребоваться найти его в вашей системе.

На Ubuntu местоположение сокета — /var/run/mysqld/mysqld.sock.

Настройка ODBC для Microsoft SQL

Подключение к Microsoft SQL (MS SQL) аналогично подключению к MySQL или PostgreSQL, как мы обсуждали ранее. Конфигурация MS SQL выходит за рамки этой книги, но следующая информация позволит настроить ваш Asterisk для подключения к базе данных MS SQL после включения соответствующих разрешений для этой базы данных.

Чтобы подключиться к MS SQL, вам необходимо установить драйверы FreeTDS с помощью диспетчера пакетов (или путем компиляции исходных файлов, доступных по адресу http://www.freetds.org).

На RHEL:

$ sudo yum install freetds

On Ubuntu:

$ sudo apt-get install tdsodbc

После установки драйверов вам необходимо поправить файл /etc/odbcinst.ini, в котором сообщается системе, где находятся файлы драйверов.

Вставьте следующий текст в /etc/odbcinst.ini помощью вашего любимого текстового редактора или с помощью следующей команды:

$ sudo cat> /etc/odbcinst.ini

[FreeTDS]

Description = ODBC для Microsoft SQL

Driver = / usr / lib / i386-linux-gnu / odbc / libtdsodbc.so

UsageCount = 1

Threading = 2

Ctrl+D

Значение драйвера должно быть /usr/lib/x86_64-linux-gnu/ если вы используете 64-разрядную установку. Если вы скомпилировали из исходных кодов, файлы могут быть расположены в каталоге /usr/local/lib/ или (если вы скомпилировали в 64-разрядной системе) /usr/local/lib64/.

Убедитесь, что система может видеть драйвер, выполнив следующую команду. Она должна вернуть имя метки FreeTDS, если все в порядке:

$ odbcinst -q -d

[FreeTDS]

После настройки драйверов вам необходимо изменить /etc/odbc.ini для управления подключением к базе данных:

[asterisk-connector]

Description = MS SQL connection to ‘asterisk’ database

Driver = FreeTDS

Database = asterisk

Server = 192.168.100.1

Trace = No

TDS_Version = 7.0

Port = 1433

В следующем разделе вы сможете проверить свое соединение с MS SQL-сервером.

Проверка ODBC-коннектора

Теперь убедитесь, что вы можете подключиться к своей базе данных с помощью приложения isql. В приложении echo выведите select 1 и перенаправьте в isql, который затем будет подключаться с использованием секции asterisk-connector, добавленной в /etc/odbc.ini. Вы должны получить следующий результат (или по крайней мере что-то подобное; мы ищем результат 1 rows fetched):

$ echo «select 1» | isql -v asterisk-connector asterisk some_secret_password

+—————————————+

| Connected! |

| |

| sql-statement |

| help [tablename] |

| quit |

| |

+—————————————+

SQL>

+————+

| ?column? |

+————+

| 1 |

+————+

SQLRowCount returns 1

1 rows fetched

Пароль, который вы использовали при создании пользователя ‘asterisk’@ в разделе «Настройка MySQL«.

Теперь, когда unixODBC установлен, настроен и проверен на работоспособность, вам необходимо перекомпилировать Asterisk, чтобы модули ODBC были созданы и установлены. Вернитесь в исходный каталог Asterisk и запустите скрипт ./configure, чтобы он знал, что вы установили unixODBC:

$ cd ~ / src / asterisk-complete / asterisk / 11

$ ./configure

$ make menuselect

$ make install

Почти все в этой главе включено по умолчанию. Вы должны запустить make menuselect, чтобы убедиться, что модули, связанные с ODBC, включены. К ним относятся cdr_odbc, cdr_adaptive_odbc, func_odbc, func_realtime, pbx_realtime, res_config_odbc и res_odbc. Для голосовой почты, хранящейся в базе данных ODBC, обязательно выберите ODBC_STORAGE в меню Voicemail Build Options (Параметры сборки голосовой почты). Вы можете проверить, что модули существуют в каталоге /usr/lib/asterisk/modules.

Как только Linux сможет использовать ODBC, Asterisk также сможет использовать ODBC. Суть в том, что ваш ODBC должен работать под Linux без ошибок, прежде чем вы погрузитесь в часть процесса настройки Asterisk.

Компиляция модулей ODBC для Asterisk

Теперь, когда ODBC установлен и протестирован, вам необходимо скомпилировать соответствующие модули для Asterisk.

Самый простой способ сделать это — просто вернуться в каталог установки («Asterisk»), повторно запустить sudo ./configure, а затем sudo make install и система распознает что зависимости для ODBC теперь выполнены и автоматически скомпилирует и установит соответствующие модули для Asterisk. Если хотите, то можете запустить make menuselect и убедиться, что функция диалплана func_odbc теперь отображается как [*] func_odbc, а модуль ресурсов res_odbc также указан как [*] res_odbc.

Настройка res_odbc для подключения Asterisk к ODBC

Подключения Asterisk к ODBC настраиваются в файле res_odbc.conf, расположенном в /etc/asterisk. В res_odbc.conf устанавливаются параметры, которые различные модули Asterisk будут использовать для подключения к базе данных.

Опции pooling и limit являются весьма полезными для баз данных MS SQL и Sybase. Они позволяют устанавливать несколько соединений (вплоть до limit подключений) с базой данных, гарантируя при этом, что каждое соединение имеет только одну инструкцию, выполняемую одновременно (это связано с ограничением в протоколе, используемом этими серверами баз данных).

Измените res_odbc.conf следующим образом:

[asterisk]

enabled => yes

dsn => asterisk-connector

username => asterisk

password => welcome

pooling => no

limit => 1

pre-connect => yes

Параметр dsn указывает на подключение к базе данных, которое вы настроили в /etc/odbc.ini, а параметр pre-connect сообщает Asterisk открыть и поддерживать соединение с базой данных при загрузке модуля res_odbc.so. Это снижает некоторые издержки, связанные с многократной установкой и разрывом соединения с базой данных.

После того как вы настроили res_odbc.conf, запустите Asterisk и проверьте соединение с базой данных с командой CLI odbc show:

*CLI> odbc show

ODBC DSN Settings

——————

Name: asterisk

DSN: asterisk-connector

Last connection attempt: 1969-12-31 19:00:00

Pooled: No

Connected: Yes

Управление базами данных

Хотя в этой книге не описывается управление базами данных, по крайней мере стоит кратко отметить некоторые приложения, которые можно использовать для управления базами данных. Некоторые из них существуют, некоторые из них являются локальными клиентскими приложениями, запущенными с Вашего компьютера и подключенными к базе данных, а другие — веб-приложениями, которые могут обслуживаться с того же компьютера, на котором запущена сама база данных, что позволяет подключаться удаленно.

Некоторые из тех, которые мы использовали, включают в себя:

Устранение неполадок с базой данных

При работе с соединениями базы данных ODBC и Asterisk важно помнить, что соединение ODBC абстрагирует часть информации, переданной между Asterisk и базой данных. В случаях, когда все работает не так, как ожидалось, вам может потребоваться включить логирование на вашей платформе базы данных, чтобы узнать, что Asterisk отправляет в базу (например, какие инструкции SELECT, INSERT или UPDATE запускаются из Asterisk), что база данных видит и почему может отклонять инструкции.

Например, одной из наиболее распространенных проблем, возникающих при интеграции базы данных ODBC, является некорректно определенная таблица или отсутствующий столбец, существование которого ожидает Asterisk. Хотя большие успехи были сделаны в виде адаптивных модулей, не все части Asterisk являются адаптивными. В случае хранилища голосовой почты ODBC вы, возможно, пропустили столбец, такой как flag, который является новым столбцом, не найденным в версиях Asterisk до 11.⁴ Чтобы выяснить, почему ваши данные не записываются в базу данных, как ожидалось, вы должны включить логирование операторов на стороне базы данных, а затем определить, какая инструкция выполняется и почему база данных отклоняет ее.

Инъекция SQL

Безопасность всегда учитывается при создании сетевых приложений, и безопасность базы данных не является исключением.

В случае с Asterisk вы должны подумать о том, какие ввходные данные принимаете от пользователей (как правило то, что они могут отправить в диалплан), и работать над дезинфекцией этих данных, чтобы убедиться, что вы разрешаете только символы, которые допустимы для вашего приложения. Например, типичный телефонный вызов допускал бы только цифры в качестве ввода (и, возможно, символы * и #), поэтому не было бы причин принимать какие-либо другие символы. Имейте в виду, что протокол SIP допускает больше, чем просто числа как часть адреса, поэтому не предполагайте, что кто-то, пытающийся скомпрометировать вашу систему, ограничится одними цифрами.

Небольшое дополнительное время, затрачиваемое на дезинфекцию ваших разрешенных входных данных, улучшит безопасность вашего приложения.

Мощь вашего диалплана с func_odbc

Функция диалплана func_odbc, возможно крутейшая⁵ и самая мощная функция диалплана в Asterisk. Она позволяет вам определять и использовать относительно простые функции в вашем диалплане, которые будут извлекать информацию из баз данных по мере обработки вызовов. Существуют всевозможные способы их использования, такие как управление пользователями или возможность совместного использования динамической информации в кластере машин Asterisk. Мы не будем утверждать, что это упростит проектирование и создание кода диалплана, но мы пообещаем, что это позволит вам добавить совершенно новый уровень мощности в ваш диалплан, особенно если вы любите работать с базами данных. До сих пор мы не можем думать о тех, кто не любит func_odbc.

func_odbc позволяет определять SQL-запросы, которыми назначаются имена функций. По сути, вы создаете пользовательские функции, которые получают результаты, выполняя запросы к базе данных. В func_odbc.conf вы указываете отношения между именами функций, которые вы создаете, и операторами SQL, которые хотите выполнить. Обращаясь к названным функциям в диалплане, вы можете получать и обновлять значения в базе данных.

Чтобы вы были в хорошем настроении для дальнейшего, мы хотим, чтобы вы представили себе сэндвич Dagwood.⁶

Можете ли вы передать общий опыт такой вещи, показывая кому-то изображение помидора или размахивая кусочком сыра? Вряд ли. Это та головоломка, с которой мы столкнулись, когда пытались дать полезные примеры того, почему func_odbc настолько силен. Итак, мы решили создать целый сэндвич для вас. Это довольно полный рот, но после нескольких укусов это арахисовое масло и желе никогда не будут одинаковыми.

Отношения файлов конфигурации ODBC

Чтобы Asterisk мог использовать ODBC из диалплана, несколько файлов должны выстроиться в линию. Рисунок 16-1 пытается дать визуальное понимание этого. Вы, вероятно, найдете эту диаграмму более полезной, как только поработаете с примерами в следующих разделах.

*Рисунок 16-1. Взаимоотношения между func_odbc.conf, res_odbc.conf, /etc/odbc.ini (unixODBC) и соединением с базой данных*

Нежное введение в func_odbc.

Прежде чем мы углубимся в func_odbc, мы чувствуем, что история в порядке.

Самое первое использование func_odbc, которое случилось когда его автор еще писал его, также является хорошим введением в его использование. Клиент одного из авторов модуля отметил, что некоторые люди, вызывающие его коммутатор, нашли способ совершать бесплатные звонки с его системы. Хотя его конечной целью было изменить свой диалплан, чтобы избежать этих проблем, он нуждался в черном списке определенных номеров вызывающих абонентов, в то же время, он хотел использовать для этого базы данных сервера Microsoft SQL.

За некоторыми исключениями это фактический диалплан:

[span3pri]

exten => _50054XX,1,NoOp()

same => n,Set(CDR(accountcode)=pricall)

; Этот callerID присутствует в базе данных?

same => n,GotoIf($[${ODBC_ANIBLOCK(${CALLERID(number)})}]?busy)

same => n(dial),Dial(DAHDI/G1/${EXTEN})

same => n(busy),Busy(10) ; Да, вы находитесь в черном списке.

same => n,Hangup

Этот диалплан, в двух словах, передает все вызовы другой системе для целей маршрутизации, за исключением вызовов, чьи CallerID находятся в черном списке. Вызовы, входящие в эту систему, имеют блок из 100 семизначных идентификаторов DID. Вы заметите, что используется функция диалплана, которую вы не найдете ни в одной из функций, которые поставляются с Asterisk: ODBC_ANIBLOCK(). Эта функция была определена в другом файле конфигурации func_odbc.conf:

[ANIBLOCK]

dsn=telesys

readsql=SELECT IF(COUNT(1)>0, 1, 0) FROM Aniblock WHERE NUMBER=’${ARG1}’

Итак, ваша функция ODBC_ANIBLOCK()⁷ подключается к источнику данных в res_odbc.conf с именем telesys и выбирает количество записей, которые имеют NUMBER, указанный в аргументе, который (ссылаясь на наш диалплан выше) является CallerID. Номинально эта функция должна возвращать либо 1 (указывающий CallerID присутствует в таблице Aniblock), либо 0 (если это не так). Это значение также напрямую оценивается как true или false, что означает что нам не нужно использовать выражение в нашем диалплане для усложнения логики.

И это, в двух словах, о func_odbc: написание пользовательских функций диалплана, которые возвращают результат из базы данных. Далее, более подробный пример того, как можно использовать func_odbc.

Веселимся с func_odbc: горячий стол

Хорошо, вернемся к сэндвичу Dagwood, который мы обещали.

Мы полагаем, что значение func_odbc станет для вас очень ясным если вы выполните следующий пример, который приведет к созданию новой функции в вашей системе Asterisk, которая сильно зависит от func_ocbc.

Представьте себе небольшую компанию с отделом продаж из пяти человек, которым приходится делить два стола. Это не так жестоко, как кажется, потому что эти люди проводят большую часть своего времени в дороге и каждый из них находится в офисе не более одного дня в неделю.

Тем не менее, когда они попадают в офис, то хотели бы чтобы система знала, за каким столом они сидят, чтобы их звонки могли быть направлены туда. Кроме того, босс хочет иметь возможность отслеживать когда они находятся в офисе и контролировать привилегии вызова с этих телефонов, когда никого нет.

Эта потребность обычно решается тем, что называется горячий стол. Мы создали один для вас, чтобы показать вам силу func_odbc.

Давайте начнем с простых вещей и создадим два настольных телефона в файле sip.conf:

;sip.conf

;HOT DESK ТЕЛЕФОНЫ

[hot_desk_phone](!) ;шаблон

type = friend

host = dynamic

context = hotdesk

qualify = yes

[0000FFFF0003](hot_desk_phone) ; первый стол

secret = this_phone_needs_a_good_password

[0000FFFF0004] (hot_desk_phone) ; второй стол

secret = this_phone_also_needs_a_secret

; КОНЕЦ ТЕЛЕФОНОВ HOT DESK

Эти два настольных телефона входят в диалплан в контексте hotdesk в extensions.conf, который мы вскоре определим. Если вы хотите, чтобы эти устройства действительно работали, вам, конечно же, нужно будет установить соответствующие параметры в самих устройствах, но мы это рассмотрели в Главе 5. Если вы создаете эти телефоны в своей лаборатории, имена устройств, которые мы используем, нужно заменить на то, что вам лучше всего подходит для ваших нужд (мы рекомендуем использовать MAC-адрес).

Это все для sip.conf. У нас есть два куска хлеба, которые пока не сэндвич.

Теперь давайте создадим часть базы данных (мы предполагаем, что у вас есть база данных ODBC, созданная и работающая, как описано в предыдущих частях этой главы). Сначала подключитесь к консоли базы данных.

Для PostgreSQL:

$ sudo su — postgres

$ psql -U asterisk -h localhost asterisk

Password:

Затем создайте таблицу со следующим битом SQL:

CREATE TABLE ast_hotdesk

(

id serial NOT NULL,

extension int8,

first_name text,

last_name text,

cid_name text,

cid_number varchar(10),

pin int4,

context text,

status bool DEFAULT false,

«location» text,

CONSTRAINT ast_hotdesk_id_pk PRIMARY KEY (id)

)

WITHOUT OIDS;

Для MySQL:

$ mysql -u asterisk -p asterisk

Enter password:

Затем создайте таблицу со следующим битом SQL:

CREATE TABLE ast_hotdesk

(

id serial NOT NULL,

extension int8,

first_name text,

last_name text,

cid_name text,

cid_number varchar(10),

pin int4,

context text,

status bool DEFAULT false,

location text,

CONSTRAINT ast_hotdesk_id_pk PRIMARY KEY (id)

);

Информация о таблице приведена в Таблице 16-1.

Таблица 16-1. Резюме таблицы ast_hotdesk

Имя столбца	Тип столбца
id	серийный, автоувеличивающийся
extension	целочисленный
first_name	текст
last_name	текст
cid_name	текст
cid_number	10-символьная переменная
pin	целочисленная
context	текст
status	логическая, по-умолчанию false
location	текст

После этого заполните базу данных следующей информацией (некоторые из значений, которые вы увидите, на самом деле изменятся только после выполнения работы диалплана, но мы включим их здесь в качестве примера).

На консоли PostgreSQL запустите следующие команды:

asterisk => INSERT INTO ast_hotdesk (‘extension’, ‘first_name’, ‘last_name’, \

‘cid_name’, ‘cid_number’, ‘pin’, ‘context’, ‘location’) \

VALUES (1101, ‘Leif’, ‘Madsen’, ‘Leif Madsen’, ‘4165551101’, ‘555’,\

‘longdistance’ , ‘0000FFFF0003’);

На консоли MySQL запустите следующие команды:

mysql> INSERT INTO ast_hotdesk (extension, first_name, last_name, cid_name,

cid_number, pin, context, status, location)

VALUES (1101, ‘Leif’, ‘Madsen’, ‘Leif Madsen’,

‘4165551101’, ‘555’, ‘longdistance’, 1, ‘0000FFFF0003’);

mysql> INSERT INTO ast_hotdesk (extension, first_name,

last_name, cid_name, cid_number, pin, context)

VALUES (1104,’Mark’,’Spencer’,’Mark Spencer’,

‘4165551104’,’558′,’international’);

Повторите эти команды, изменив значения VALUES по мере необходимости, для всех записей, которые вы хотите иметь в базе данных.⁸ После ввода данных образца вы можете просмотреть данные в таблице ast_hotdesk, запустив простой оператор SELECT из консоли базы данных:

mysql> SELECT * FROM ast_hotdesk;

которая может дать вам что-то вроде следующего вывода:

+—-+————+————+—————+——————+

+—-+————+————+—————+——————+

| 4 | 1102 | Jim | Van Meggelen | Jim Van Meggelen |

+—-+————+————+—————+——————+
+————+——+—————+———+—————+

+————+——+—————+———+—————+

| 4165551101 | 555 | longdistance | 1 | 0000FFFF0003 |

| 4165551104 | 558 | international | 0 | NULL |

| 4165551105 | 559 | local | 0 | NULL |

| 4165551102 | 556 | longdistance | 0 | NULL |

| 4165551103 | 557 | local | 0 | NULL |

+————+——+—————+———+—————+

У нас есть приправы, так что давайте перейдем к нашему диалплану. Здесь и будет происходить волшебство.

Где-то в extensions.conf нам необходимо создать контекст hotdesk. Для начала давайте определим внутерний номер-шаблон, который позволит пользователям входить в систему:

; extensions.conf

; Возможность горячего стола

[hotdesk]

; Вход в систему горячего стола

exten => _99110[1-5],1,NoOp()

same => n,Set(E=${EXTEN:2}) ; отделить ведущие 99

same => n,Verbose(1,Hot Desk Extension ${E} is changing status)

same => n,Verbose(1,Checking current status of extension ${E})

same => n,Set(${E}_STATUS=${HOTDESK_INFO(status,${E})})

same => n,Set(${E}_PIN=${HOTDESK_INFO(pin,${E})})

Мы еще не закончили писать этот код, но нам нужно отойти на несколько страниц, чтобы обсудить, где мы находимся до сих пор.

Когда торговый агент садится за стол, он регистрируется, набрав 99 плюс его собственный добавочный номер. В этом случае мы разрешили номерам с 1101 по 1105 войти в систему совпадением шаблонов _99110[1-5]. Вы можете так же легко сделать это менее ограничительным, используя _9911XX (с 1100 по 1199). Это расширение использует func_odbc для выполнения поиска с помощью функции диалплана HOTDESK_INFO(). Эта настраиваемая функция (которую мы определим в файле func_odbc.conf) выполняет оператор SQL и возвращает все, что извлекается из базы данных.

Мы бы определили новую функцию HOTDESK_INFO() в func_odbc.conf следующим образом:

[INFO]

prefix=HOTDESK

dsn=asterisk

readsql=SELECT ${ARG1} FROM ast_hotdesk WHERE extension = ‘${ARG2}’

Это много всего за несколько строк. Давайте быстро прикроем их, прежде чем двигаться дальше.⁹

Прежде всего, prefix является необязательным (префикс по умолчанию — ‘ODBC’). Это означает, что если вы не определяете префикс, Asterisk добавляет ‘ODBC’ к имени функции (в данном случае INFO), что означает, что эта функция станет ODBC_INFO(). Это не очень хорошо описывает, что делает функция, поэтому может быть полезно назначить префикс, который помогает связать ваши функции ODBC с задачами, которые они выполняют. Мы выбрали ‘HOTDESK’, что означает, что эта настраиваемая функция будет называться HOTDESK_INFO() в диалплане.

Причина, по которой prefix отделен, заключается в том, что автор модуля хотел уменьшить возможные коллизии с существующими функциями диалплана. Цель префикса состояла в том, чтобы разрешить несколько копий одной и той же функции, подключенной к различным базам данных, для многозадачных систем Asterisk. Мы, авторы, были немного более либеральны в использовании префикса, чем первоначально предполагал разработчик.

Атрибут dsn указывает Asterisk какое соединение использовать от res_odbc.conf. Поскольку в базе данных можно настроить несколько подключений к базе данных res_odbc.conf, мы укажем какой из них следует использовать здесь. На Рисунке 16-1 мы показываем взаимосвязь между различными конфигурациями файлов и тем, как они ссылаются на цепочку для подключения к базе данных.

Файл func_odbc.conf.sample в исходниках Asterisk содержит дополнительную информацию о том, как работать с несколькими базами данных и контролировать чтение и запись информации для различных соединений DSN. В частности, аргументы readhandle, writehandle, readsql и writeql предоставят вам большую гибкость для интеграции и управления базами данных.

Наконец, мы определяем наш оператор SQL с атрибутом readsql. Функции диалплана можно вызывать в двух разных форматах: один для извлечения информации и один для настройки информации. Атрибут readsql используется при вызове функции HOTDESK_INFO() с форматом извлечения (мы могли бы выполнить отдельный оператор SQL с атрибутом writesql, мы обсудим формат для этого атрибута немного позже в этой главе).

Чтение значений из этой функции примет этот формат в диалплане:

exten => s,n,Set(RETURNED_VALUE=${HOTDESK_INFO(status,1101)})

Это вернет значение, находящееся в базе данных в столбце status, где столбец extension равен 1101. status и 1101, которые мы передаем функции HOTDESK_INFO() затем помещаются в оператор SQL, присвоенный атрибуту readsql, доступный как ${ARG1} и ${ARG2} соответственно. Если бы мы допустили третий вариант, он был бы доступен как ${ARG3}.

После выполнения инструкции SQL возвращаемое значение (если есть) назначается канальной переменной RETURNED_VALUE.

Использование функции ARRAY()

В нашем примере мы используем два отдельных вызова базы данных и присваиваем эти значения паре переменных канала, ${E}_STATUS и ${E}_PIN. Это было сделано чтобы упростить пример:

exten => _110 [1-5],1,NoOp()

same => n,Dial(${Е}_STATUS=${HOTDESK_INFO(status,${Е})})

same => n,Set(${E}_PIN=${HOTDESK_INFO(pin,${E})})

В качестве альтернативы мы могли бы вернуть несколько столбцов и сохранить их в отдельные переменные, используя функцию набора номера ARRAY(). Если бы мы определили наш оператор SQL в файле func_odbc.conf следующим образом:

readsql=SELECT pin,status FROM ast_hotdesk WHERE extension = ‘${E}’

мы могли бы использовать функцию ARRAY() для сохранения каждого столбца информации из строки в свою переменную с одним вызовом базы данных:

exten => _110[1-5],1,Set(ARRAY(${E}_PIN,${E}_STATUS)=${HOTDESK_INFO(${E})})

Использование ARRAY() удобно в любое время, когда вы можете получить значения, разделенные запятыми и хотите присвоить значения отдельным переменным, например CURL().

Итак, в первых двух строках следующего блока кода мы передаем значения status и значение, содержащееся в переменной ${E} (например, 1101), в функцию HOTDESK_INFO(). Эти два значения затем заменяются в операторе SQL с помощью ${ARG1} и ${ARG2} соответственно и выполняется инструкция SQL. Наконец, возвращаемое значение присваивается переменной канала ${E}_STATUS.

Итак, давайте закончим писать внутренний номер-шаблон:

same => n,Set(${E}_STATUS=${HOTDESK_INFO(status,${E})})

same => n,Set(${E}_PIN=${HOTDESK_INFO(pin,${E})})

same => n,GotoIf($[${ODBCROWS} < 0]?invalid_user,1)

same => n,GotoIf($[${${E}_STATUS} = 1]?logout,1:login,1)

После присвоения значения столбца status в переменную ${E}_STATUS (если пользователь идентифицирует сам себе как номер 1101, имя переменной будет 1101_STATUS), мы проверяем если получили значение из базы данных (проверка ошибок), используя переменную канала ${ODBCROWS}.

Последняя строка в блоке проверяет состояние телефона и, если агент в настоящий момент вошел в систему, отключает его. Если агент еще не вошел в систему, он перейдет на расширение login, с приоритетом 1 в том же контексте.

Помните, что в традиционной телефонной системе все расширения должны быть номерами, но в Asterisk расширения также могут иметь имена. Возможным преимуществом использования расширения, которое не является числом, является то, что пользователю будет намного сложнее набрать его со своего телефона и, следовательно, более безопасно. В этом примере мы будем использовать несколько именованных расширений. Если вы хотите быть абсолютно уверены, что злоумышленник не сможет получить доступ к этим именованным расширениям, просто используйте трюк, который использует загрузчик AEL: запустите с приоритетом, отличным от 1. Вы можете получить доступ к первой строке расширения присвоив ему метку приоритета и ссылаясь на нее с помощью комбинации имя расширения/метка приоритета.

Расширение login выполняет некоторые первоначальные проверки, чтобы проверить PIN-код, введенный агентом. (Кроме того, мы использовали функцию FILTER(), чтобы убедиться что были введены только цифры во избежание некоторых проблем с SQL-инъекциями.) Мы разрешаем ему три попытки на введение правильного PIN-кода, и если все попытки неудачны, то отправляем вызов на расширение login_fail (которое мы опишем позже):

exten => login,1,NoOp() ; установить начальные значения счетчика

same => n,Set(PIN_TRIES=1) ; счетчик попыток pin

same => n,Set(MAX_PIN_TRIES=3) ; установка макс числа попыток входа

same => n,Playback(silence/1) ; воспроизвести некоторое молчание, так

; что первая подсказка не отрезана

same => n(get_pin),NoOp()

same => n,Set(PIN_TRIES=$[${PIN_TRIES} + 1]) ; увеличение счетчика pin

same => n,Read(PIN_ENTERED,enter-password,${LEN(${${E}_PIN})})

same => n,Read(PIN_ENTERED=${FILTER(0-9,${PIN_ENTERED})})

same => n,GotoIf($[«${PIN_ENTERED}» = «${${E}_PIN}»]?valid_login,1)

same => n,Playback(pin-invalid)

same => n,GotoIf($[${PIN_TRIES} <= ${MAX_PIN_TRIES}]?get_pin:login_fail,1)

Если введен PIN-код, мы проверяем логин с расширением valid_login. Сначала используем переменную CHANNEL, чтобы выяснить, какое телефонное устройство вызывается агентом. Переменная CHANNEL обычно заполняется чем-то вроде SIP/0000FFFF0001-ab4034c, поэтому мы используем функцию CUT(), чтобы сначала убрать часть строки SIP/ и назначить ее LOCATION. Затем мы удаляем часть строки -ab4034c, отбрасываем ее и назначаем оставшуюся часть (0000FFFF0001) переменной LOCATION:

exten => valid_login,1,NoOp()

; отрезаем технологию канала и назначаем переменной LOCATION

same => n,Set(LOCATION=${CUT(CHANNEL,/,2)})

; отрезаем уникальный идентификатор и сохраняем остальное в переменной

; LOCATION

same => n,Set(LOCATION=${CUT(LOCATION,-,1)})

Мы используем еще одну пользовательскую функцию, созданную в файле func_odbc.conf — HOTDESK_CHECK_PHONE_LOGINS(), чтобы проверить, были ли ранее зарегистрированы другие пользователи под этим телефоном и просто забыли выйти из системы. Если количество неавторизованных пользователей больше 0 (оно никогда не должно быть больше 1, но мы всё равно проверяем на большие значения и сбрасываем их тоже), он запускает логику в расширении logout_login:

; func_odbc.conf

[CHECK_PHONE_LOGINS]

prefix=HOTDESK

dsn=asterisk

readsql=SELECT COUNT(status) FROM ast_hotdesk WHERE status = ‘1’

readsql+=AND location = ‘${ARG1}’

Из-за ограничений длины строк в книге мы разбили команду readsql на несколько строк, используя синтаксис +=, который сообщает Asterisk добавлять содержимое после readsql+= к последнему определенному значению readsql=. Использование += применимо не только к параметру readsql, но также может использоваться и в других местах в других .conf-файлах в Asterisk. Например, что-то вроде callerid+= можно использовать в sip.conf.

Если нет других агентов вошедших в устройство, мы обновляем состояние входа для данного пользователя функцией HOTDESK_STATUS():

; Продолжение расширения valid_login ниже

same => n,Set(USERS_LOGGED_IN=${HOTDESK_CHECK_PHONE_LOGINS(${LOCATION})})

same => n,GotoIf($[${USERS_LOGGED_IN} > 0]?logout_login,1)

same => n(set_login_status),NoOp()

; Устанавливаем состояние для телефона в ‘1’ и где агент вошел в систему

same => n,Set(HOTDESK_STATUS(${E})=1,${LOCATION})

same => n,GotoIf($[${ODBCROWS} < 1]?error,1)

same => n,Playback(agent-loginok)

same => n,Hangup()

Мы создаем функцию записи в func_odbc.conf следующим образом:

[STATUS]

prefix=HOTDESK

dsn=asterisk

writeql=UPDATE ast_hotdesk SET status = ‘${SQL_ESC(${VAL1})}’, writeql+= location=’${SQL_ESC(${VAL2})}’

writeql+=WHERE extension = ‘${SQL_ESC(${ARG1})}

Синтаксис очень похож на readsql, рассмотренный ранее в этой главе, но здесь есть несколько новых вещей, поэтому давайте обсудим их, прежде чем двигаться дальше.

Первое что вы, возможно, заметили, это то, что теперь мы имеем переменные ${VALx} и ${ARGx} в нашем операторе SQL.

Мы также обернули значения ${VALx} и ${ARGx} в функцию SQL_ESC(), которая будет экранировать символы, такие как обратные кавычки, которые могут быть использованы при атаке SQL-инъекции.

Они содержат значения, которые мы передаем функции из диалплана. В этом случае у нас есть две переменные VAL и одна ARG, которые были установлены из диалплана через этот оператор:

Set(HOTDESK_STATUS(${E})=1,${LOCATION})

Обратите внимание, что синтаксис немного отличается от синтаксиса функции в стиле чтения. Это сигнализирует Asterisk, что вы хотите выполнить запись (это тот же синтаксис, что и для других функций диалплана).

Мы передаем значение переменной ${E} функции HOTDESK_STATUS(), значение которой затем доступно в операторе SQL в func_odbc.conf с переменной ${ARG1}. Затем мы передаем два значения: 1 и ${LOCATION}. Они доступны оператору SQL в переменных ${VAL1} и ${VAL2} соответственно.

Использование SQL непосредственно в диалплане.

Некоторые люди предпочли бы напрямую писать свои SQL-запросы в диалплане, а не создавать пользовательскую функцию для каждого типа транзакций базы данных, которые они могут выполнять.

Теоретически вы можете создать только одну функцию в func_odbc.conf следующим образом:

[SQL]

prefix=GENERIC

dsn=asterisk

readsql=${SQL_ESC(${ARG1})}

writeql=${SQL_ESC(${VAL1})}

Тогда, в диалплане вы могли бы написать практически любой тип SQL, который захотели (при условии, что ODBC-коннектор мог бы обрабатывать его, что не имеет ничего общего с Asterisk). Затем эта функция должна передать любую строку, указанную вами, в базу данных через ODBC-коннектор.¹

Некоторые утверждают, что это приводит к большей детализации в вашем диалплане; другие будут настаивать на том, что полезно иметь гораздо более простой файл func_odbc.conf:

[odbc_hacking]

exten => 8811,1,Goto(odbcreadtest,1)

exten => 8822,1,Goto(odbcwritetest,1)

exten => odbcreadtest,1,Noop()

same => n,Set(result=${GENERIC_SQL(SELECT first_name

FROM ast_hotdesk WHERE id=4)})

same => n,Verbose(1,${result})

same => n,Hangup()

; обратите внимание на необходимость экранирования символов кавычек

exten => odbcwritetest,1,Noop()

same => n,Set(GENERIC_SSQL()

= UPDATE ast_hotdesk SET

first_name=\’${EXTEN}\’WHERE id=4)

same => n,Verbose (1,ODBC_RESULT — ${OBDBC_RESULT})

same => n,Hangup()

Мы склонны думать, что обычно лучше строить функции с помощью func_odbc.conf, для обработки запросов, которые вы будете выполнять из вашего диалплана; однако нельзя отрицать соблазна использовать одну функцию для обработки всех SQL-запросов и написать весь запрос непосредственно в диалплане. Попробуйте оба метода и посмотрите, что работает для вас (вы даже можете использовать комбинацию обоих типов).

Суть в том, что func_odbc — это очень гибкий модуль Asterisk, который является немалой частью того, почему мы его любим.

Как уже упоминалось ранее, если нам нужно было выйти из одного или нескольких агентов перед входом в этот, мы проверили бы это в расширении logout_login. Эта логика диалплана будет использовать функцию ODBC_FETCH(), чтобы вывести информацию из стека, возвращаемого функцией HOTDESK_LOGGED_IN_USER(). Скорее всего, она выполнит только один цикл, но это хороший пример того, как вы можете обновлять или анализировать несколько строк в базе данных.¹¹

Первая часть нашего диалплана возвращает идентификационный номер, который мы можем использовать с функцией ODBC_FETCH(), для перебора возвращаемых значений. Мы напишем раздел диалплана, чтобы присвоить этот идентификатор переменной канала LOGGED_IN_ID:

same => n,Set(LOGGED_IN_ID=${HOTDESK_LOGGED_IN_USER(${LOCATION})})

Вот расширение logout_login, которое потенциально может циклически проходить через несколько строк:

exten => logout_login,1,NoOp()

; установите для всех пользователей, вошедших в систему на этом устройстве,

; состояние выхода из системы

same => n,Set(LOGGED_IN_ID=${HOTDESK_LOGGED_IN_USER(${LOCATION})})

same => n(start_loop),NoOp()

same => n,Set(WHO=${ODBC_FETCH(${LOGGED_IN_ID})})

same => n,GotoIf($[«${ODBC_FETCH_STATUS}» = «FAILURE»]?cleanup)

same => n,Set(HOTDESK_STATUS(${WHO})=0) ; выйти из телефона

same => n,Goto(start_loop)

same => n(cleanup),ODBCFinish(${LOGGED_IN_ID})

same => n,Goto(valid_login,set_login_status) ; возврат ко входу в систему

И вот функция, которую мы добавили бы в func_odbc.conf (не забудьте перезагрузить модуль func_odbc.so):

[LOGGED_IN_USER]

prefix=HOTDESK

dsn=asterisk

mode=multirow

readsql=SELECT extension FROM ast_hotdesk

readsql+= WHERE status = ‘1’

readsql+= AND location = ‘${SQL_ESC(${ARG1})}’

Мы назначаем первое значение, возвращаемое из базы данных (например, номер 1101) в канал WHO. Прежде чем что-либо делать, мы проверяем, была ли функция ODBC_FETCH() успешной при возврате данных. Если переменная канала ODBC_FETCH_STATUS содержит FAILURE, у нас нет данных для работы, поэтому мы переходим к метке приоритета cleanup.

Если у нас есть данные, мы передаем значение ${WHO} в качестве аргумента функции HOTDESK_STATUS(), которая содержит значение 0. Это первое переданное значение в HOTDESK_STATUS() и отображается как ${VAL1} в func_odbc.conf, где объявлена функция.

Если вы посмотрите на функцию HOTDESK_STATUS() в func_odbc.conf, вы увидите, что мы также можем передать второе значение, но не делаем этого, поскольку хотим удалить любые значения из этого столбца, чтобы вывести пользователя из системы, который не создает никакой ценности.

После использования HOTDESK_STATUS() для выхода пользователя из системы, мы возвращаемся к метке приоритета start_loop чтобы выполнить цикл по всем значениям, который просто выполняет NoOp(). После попытки получить значение, мы снова проверяем ODBC_FETCH_STATUS на FAILURE. Если это значение найдено, мы переходим на метку приоритета cleanup, где выполняем приложение диалплана ODBCFinish() для выполнения очистки. Затем возвращаемся к расширению valid_login на метку приоритета set_login_status.

Мультистроковая функциональность с func_odbc

Существует режим, позволяющий Asterisk обрабатывать несколько строк данных, возвращаемых из базы данных. Например, если бы нам нужно было создать функцию диалплана в func_odbc.conf, которая вернула бы все доступные внутренние номера, нам нужно было бы включить мультивывод для этой функции. Это приведет к тому, что функция будет работать несколько иначе, возвращая идентификационный номер, который затем может быть передан функции ODBC_FETCH(), чтобы возвращать каждую строку по очереди.

Давным-давно нам нужно было использовать функции SQL LIMIT и OFFSET для управления данными, возвращаемыми в Asterisk для итерации. Это было ресурсоемким (по крайней мере, в отношении многострочного режима), поскольку для каждой строки требовалось несколько запросов к базе данных.

Далее следует простой пример. Предположим, что у нас есть следующий func_odbc.conf:

[ALL_AVAIL_EXTENS]

prefix=GET

dsn=asterisk-connector

mode=multirow

readsql=SELECT extension FROM ast_hotdesk WHERE status = ‘${ARG1}’

и диалплан в extensions.conf, который выглядит примерно так:

[multirow_example]

exten => start,1,Verbose(1,Looping example)

same => n,Set(ODBC_ID=${GET_ALL_AVAIL_EXTENS(1)})

same => n,GotoIf($[${ODBCROWS} < 1]?no_rows,1)

same => n,Set(COUNTER=1)

same => n,While($[${COUNTER} <= ${ODBCROWS}])

same => n,Set(AVAIL_EXTEN_${COUNTER}=${ODBC_FETCH(${ODBC_ID})})

same => n,Set(COUNTER=$[${COUNTER + 1])

same => n,EndWhile()

same => n,ODBCFinish()

exten => no_rows,1,Verbose(1,No rows returned)

same => n,Playback(silence/1&invalid)

same => n,Hangup()

Функция ODBC_FETCH() по существу будет обрабатывать информацию как стек и каждый вызов ее с переданным ODBC_ID будет выводить следующую строку информации из стека. У нас также есть возможность использовать канальную переменную ODBC_FETCH_STATUS, которая устанавливается после функции ODBC_FETCH() (которая возвращает SUCCESS, если доступны дополнительные строки или FAILURE, если нет дополнительных строк). Это позволяет вам написать диалплан как показано ниже, который не использует счетчик, но по-прежнему циклически проходится по данным. Это может быть полезно, если мы ищем что-то конкретное и нет надобности просматривать все данные. Как только мы закончим, необходимо вызвать приложение ODBCFinish() для очистки всех оставшихся данных.

Вот еще один пример extensions.conf:

[multirow_example_2]

exten => start,1,Verbose(1,Looping example with break)

same => n,Set(ODBC_ID=${GET_ALL_AVAIL_EXTENS(1)})

same => n(loop_start),NoOp()

same => n,Set(ROW_RESULT=${ODBC_FETCH(${ODBC_ID})})

same => n,GotoIf($[«${ODBC_FETCH_STATUS}» = «FAILURE»]?cleanup,1)

same => n,GotoIf($[«${ROW_RESULT}» = «1104»]?good_exten,1)

same => n,Goto(loop_start)

exten => cleanup,1,Verbose(1,Cleaning up after all iterations)

same => n,Verbose(1,We did not find the extension we wanted)

same => n,ODBCFinish(${ODBC_ID})

same => n,Hangup()

exten => good_exten,1,Verbose(1,Extension we want is available)

same => n,ODBCFinish(${ODBC_ID})

same => n,Verbose(1,Perform some action we wanted)

same => n,Hangup()

Остальная часть контекста должна быть довольно простой (если некоторые из них не имеют смысла, мы предлагаем вам вернуться и обновить память в Главах 6 и 10). Единственным трюком, с которым вы не знакомы, может быть использование переменной канала ${ODBCROWS}, которая задается функцией HOTDESK_STATUS(). Она говорит нам сколько строк было затронуто в SQL UPDATE, которуе мы считаем равной 1. Если значение ${ODBCROWS} меньше 1, мы принимаем ошибку и обрабатываем ее соответствующим образом:

exten => logout,1,NoOp()

same => n,Set(HOTDESK_STATUS(${E})=0)

same => n,GotoIf($[${ODBCROWS} < 1]?error,1)

same => n,Playback(silence/1&agent-loggedoff)

same => n,Hangup()

exten => login_fail,1,NoOp()

same => n,Playback(silence/1&login-fail)

same => n,Hangup()

exten => error,1,NoOp()

same => n,Playback(silence/1&connection-failed)

same => n,Hangup()

exten => invalid_user,1,NoOp()

same => n,Verbose(1,Hot Desk extension ${E} does not exist)

same => n,Playback(silence/2&invalid)

same => n,Hangup()

Мы также включаем контекст hotdesk_outbound, который будет обрабатывать наши исходящие вызовы после того, как мы зарегистрировали агента в системе:

include => hotdesk_outbound

В контексте hotdesk_outbound используются многие из тех же принципов, которые уже обсуждались. В этом контексте используется сопоставление шаблонов, чтобы уловить любые номера, набранные с телефонов с поддержкой «горячего стола». Сначала мы устанавливаем переменную LOCATION с использованием переменной CHANNEL, затем определяем, какой внутренний номер (агент) заносится в систему и присваиваем это значение переменной WHO. Если эта переменная равна NULL мы отклоняем исходящий вызов. Если это не NULL мы получаем информацию об агенте с помощью функции HOTDESK_INFO() и присваем ее нескольким переменным CHANNEL, включая контекст для обработки вызова, где мы выполняем Goto() в контекст, который назначили (который управляет нашим исходящим вызовом).

Мы будем использовать функцию диалплана HOTDESK_PHONE_STATUS(), которую вы можете определить в func_odbc.conf следующим образом:

[PHONE_STATUS]

prefix=HOTDESK

dsn=asterisk

readsql=SELECT extension FROM ast_hotdesk WHERE status = ‘1’

readsql+= AND location = ‘${SQL_ESC(${ARG1})}’

Если мы попытаемся набрать номер, который не обрабатывается нашим контекстом (или одним из транзитных контекстов, т.е. международный включает междугородний, который содержит локальный), будет выполнено встроенное расширение i, которое воспроизводит сообщение о том, что действие не может быть выполнено, и завершает вызов:

[hotdesk_outbound]

exten => _X.,1,NoOp()

same => n,Set(LOCATION=${CUT(CHANNEL,/,2)})

same => n,Set(LOCATION=${CUT(LOCATION,-,1)})

same => n,Set(WHO=${HOTDESK_PHONE_STATUS(${LOCATION})})

same => n,GotoIf($[${ISNULL(${WHO})}]?no_outgoing,1)

same => n,Set(${WHO}_CID_NAME=${HOTDESK_INFO(cid_name,${WHO})})

same => n,Set(${WHO}_CID_NUMBER=${HOTDESK_INFO(cid_number,${WHO})})

same => n,Set(${WHO}_CONTEXT=${HOTDESK_INFO(context,${WHO})})

same => n,Goto(${${WHO}_CONTEXT},${EXTEN},1)

[international] ; как набирается из NANP

exten => _011.,1,NoOp()

same => n,Set(E=${EXTEN})

same => n,Goto(outgoing,call,1)

exten => i,1,NoOp()

same => n,Playback(silence/2&sorry-cant-let-you-do-that2)

same => n,Hangup()

include => longdistance

[longdistance] ; содержит NANP

exten => _1NXXNXXXXXX,1,NoOp()

same => n,Set(E=${EXTEN})

same => n,Goto(outgoing,call,1)

exten => _NXXNXXXXXX,1,Goto(1${EXTEN},1)

exten => i,1,NoOp()

same => n,Playback(silence/2&sorry-cant-let-you-do-that2)

same => n,Hangup()

include => local

[local] ; в пределах NANP NPA 416

exten => _416NXXXXXX,1,NoOp()

same => n,Set(E=${EXTEN})

same => n,Goto(outgoing,call,1)

exten => i,1,NoOp()

same => n,Playback(silence/2&sorry-cant-let-you-do-that2)

same => n,Hangup()

Приведенный выше пример не является полным диалпланом, а скорее демонстрирует концепцию того, как направить пользователей через различные части диалплана на основе информации, хранящейся в базе данных. Мы использовали очень упрощенные совпадения шаблонов здесь, и в продакшене вам, скорее всего, понадобится более подробный диалплан. В качестве примера, фактический NPA 416 содержит наложение (647), а также есть обмены в пределах NPA 905/289, которые обычно набираемы как местные NPA 416. Междугородние ограничения маршрутизации могут быть сложными.

Если вызов разрешен для выполнения, он отправляется в контекст [outgoing] для обработки, а имя и номер идентификатора абонента задаются с помощью функции CALLERID(). Затем вызов отправляется через канал SIP с помощью service_provider, который мы создали в файле sip.conf:

[outgoing]

exten => call,1,NoOp()

same => n,Set(CALLERID(name)=${${WHO}_CID_NAME})

same => n,Set(CALLERID(number)=${${WHO}_CID_NUMBER})

same => n,Dial(SIP/service_provider/${E})

same => n,Playback(silence/2&pls-try-call-later)

same => n,Hangup()

Наш service_provider может выглядеть в sip.conf примерно так:

[service_provider]

type=friend

host=switch1.service_provider.net

defaultuser=my_username

fromuser=my_username

secret=welcome

context=incoming

canreinvite=no

disallow=all

allow=ulaw

Теперь, когда мы внедрили довольно сложную функцию в диалплан с помощью func_odbc для извлечения и хранения данных в удаленной реляционной базе данных, вы можете начать видеть, что с помощью нескольких самоопределяющихся функций диалплана в файле func_odbc.conf и нескольких таблиц в базе данных вы можете создать несколько мощных приложений!

Сколько вещей вы только что придумали, к которым можно применить func_odbc?

Использование Realtime

Архитектура Asterisk Realtime¹² (ARA) позволяет хранить все параметры, обычно хранящиеся в файлах конфигурации Asterisk (обычно в каталоге /etc/asterisk) в базе данных. Существует два типа Realtime: статический и динамический.

Статическая версия похожа на традиционный метод чтения файла конфигурации (информация загружается только при запуске из CLI), за исключением того, что данные считываются из базы данных.¹³

Динамический метод Realtime, который загружает и обновляет информацию, когда она используется живой системой, обычно используется для таких вещей, как пользователи и пиры SIP (или IAX2 и т.д.), а также ящики голосовой почты.

Для внесения изменений в статическую информацию требуется перезагрузка, как если бы вы изменили текстовый файл в системе, но динамическая информация была опробована Asterisk по мере необходимости, поэтому при внесении изменений в эти данные не требуется перезагрузка. Realtime настроен в extconfig.conf, расположенный в каталоге /etc/asterisk. Этот файл сообщает Asterisk, что загружать из базы данных и откуда, позволяя загружать определенные файлы из базы данных и другие файлы из стандартных файлов конфигурации.

Другой (возможно более старый) способ хранения конфигурации Asterisk состоял в использовании внешнего скрипта, который бы взаимодействовал с базой данных и генерировал соответствующие плоские файлы (или .conf файлы), а затем перезагружал соответствующий модуль после записи нового файла. У него есть преимущество (если база данных падает, ваша система будет продолжать функционировать, скрипт просто не будет обновлять файлы до восстановления связи с базой данных), но она также имеет недостатки. Одним из главных недостатков является то, что любые изменения, внесенные пользователем, не будут доступны до запуска скрипта обновления. Это, вероятно, не самая большая проблема для небольших систем, но в больших системах ожидания вступления изменений в силу могут вызвать проблемы, такие как приостановка вызова во время загрузки и анализа большого файла.

Некоторые из них можно устранить, используя реплицированную систему баз данных. Asterisk предоставляет возможность перехода на другую систему баз данных. Таким образом, вы можете объединять базы данных, используя связь master-master (для PostgreSQL, pgcluster, или Postgre-R;¹⁴ для MySQL он родной¹⁵) или master-slave (для PostgreSQL или Slony-I; для MySQL он родной) систему репликации.

Наш неофициальный обзор таких вещей показывает, что использование скриптов для записи плоских файлов из баз данных не так популярен, как запрос к базе данных в режиме реального времени (и обеспечение достаточной отказоустойчивости базы данных, чтобы справиться с тем фактом, что от нее зависит живая телекоммуникационная система ).

Статический Realtime

Статическая конфигурация Realtime полезна, когда вы хотите загрузить из базы данных конфигурацию, которую обычно размещаете в файлах конфигурации в /etc/asterisk. Те же правила, которые применяются к файлам конфигурации в вашей системе, по-прежнему применяются при использовании Static Realtime. Например, после внесения изменений в конфигурацию вы должны либо запустить глобальную команду reload из Asterisk CLI, либо перезагрузить определенный модуль, связанный с файлом конфигурации (например, module reload chan_sip.so).

При использовании Static Realtime, мы говорим Asterisk какие файлы мы хотим загрузить из базы данных используя следующий синтаксис в файле extconfig.conf:

; /etc/asterisk/extconfig.conf

[settings]

filename.conf => driver,database[,table]

Нет файла конфигурации с именем filename.conf. Вместо этого используйте фактическое имя файла конфигурации, хранящегося в базе данных. Если имя таблицы не указано, Asterisk будет использовать имя файла в качестве имени таблицы (за исключением части .conf). Кроме того, все настройки внутри файла extconfig.conf должны находиться под заголовком [settings]. Имейте в виду, что вы не можете загружать определенные файлы из RealTime, включая asterisk.conf, extconfig.conf и logger.conf.

Модуль Static Realtime использует специально определенную форматированную таблицу, позволяющую Asterisk читать различные статические файлы из базы данных. Таблица 16-2иллюстрирует столбцы, поскольку они должны быть определены в вашей базе данных:

Таблица 16-2. Раскладка таблицы и описание ast_config

Имя столбца	Тип столбца	Описание
id	серийный, автоувеличивающийся	Автоувеличивающееся уникальное значение для каждой строки в таблице.
cat_metric	целочисленный	Вес категории в файле. Более низкая метрика означает что она отображается выше в файле (см. врезку Слово о метриках).
ver_metric	целочисленный	Вес предмета в категории. Более низкий показатель означает, что он отображается выше в списке (см. врезку Слово о метриках). Это полезно для таких вещей, как порядок кодеков в sip.conf или iax.conf, где вы хотите, чтобы сначала отображалось disallow = all (метрика 0), затем allow = ulaw (метрика 1), затем allow = gsm (метрика 2).
filename	символьный (до 128)	Имя файла, которое модуль обычно считывает с жесткого диска вашей системы (например, musiconhold.conf, sip.conf, iax.conf).
category	символьный (до 128)	Имя раздела в файле, например, [general]. Не заключайте имя в квадратные скобки при сохранении в базу данных.
var_name	символьный (до 128)	Опция слева от знака равенства (например, disallow — это var_name в disallow=all).
var_val	символьный (до 128)	Значение опции справа от знака равенства (например, all — это var_val в disallow=all).
commented	целочисленный	Любое значение, отличное от 0, будет оцениваться так, как если бы оно было с префиксом точки с запятой в плоском файле (закомментировано).

Слово о метриках

Метрики в статическом Realtime используются для управления порядком считывания объектов в память. Считайте cat_metric и var_metric исходными номерами строк в файле конфигурации. Сначала обрабатывается более высокое значение cat_metric, поскольку Asterisk сопоставляет категории снизу вверх. Внутри категории сначала обрабатывается более низкая переменная var_metric, поскольку Asterisk обрабатывает параметры снизу вверх (например, disallow=all должно быть установлено значение, меньшее, чем значение allow в категории, чтобы убедиться, что оно обработано первым ).

Простым файлом, который мы можем загрузить из Static Realtime, является файл musiconhold.conf.¹⁶ Начнем с перемещения этого файла во временное место:

$ cd /etc/asterisk

$ mv musiconhold.conf musiconhold.conf.old

Для того, чтобы классы были удалены из памяти, нам необходимо перезапустить Asterisk. Затем мы можем проверить, что наши классы пустые, запустив moh showclasses:

* CLI> core restart now

* CLI> moh show classes

* CLI>

OK, теперь войдите в свою базу данных и создайте следующую таблицу:

mysql> create table ast_config (

-> id int (8) primary key auto_increment,

-> cat_metric int (8),

-> var_metric int (8),

-> filename varchar (128),

-> category varchar (128),

-> var_name varchar (128),

-> var_val varchar (128),

-> commented int default 0

-> );

Давайте вставим класс [default] в Asterisk, но теперь мы загрузим его из базы данных. Подключитесь к своей базе данных и выполните следующие инструкции INSERT:

> INSERT INTO ast_config

(cat_metric,var_metric,filename,category,var_name,var_val)

VALUES

(1,1,’musiconhold.conf’,’default’,’mode’,’files’);

> INSERT INTO ast_config

(cat_metric,var_metric,имя_файла,category,var_name,var_val)

VALUES

(1,2,’musiconhold.conf’,’default’,’directory’,’/var/lib/asterisk/moh’);

Можно проверить, что значения попали в базу данных, выполнив инструкцию SELECT:

asterisk=# SELECT filename,category,var_name,var_val FROM ast_config;

filename | category | var_name | var_val

——————+—————-+—————+————————

musiconhold.conf | default | mode | files

musiconhold.conf | default | directory | /var/lib/asterisk/moh

(2 rows)

Есть еще одна модификация — необходимо изменить файл extconfig.conf в каталоге /etc/asterisk чтобы сообщить Asterisk получать данные для musiconhold.conf из базы данных, используя ODBC-коннектор. В первом столбце указано что мы используем драйверы ODBC для подключения (res_odbc.conf) и имя соединения asterisk (как определено в [asterisk] в res_odbc.conf). Добавьте следующую строку в конец файла extconfig.conf и затем сохраните его:

[settings]

musiconhold.conf => odbc,asterisk,ast_config

Затем подключитесь к консоли Asterisk и выполните перезагрузку:

* CLI> module reload res_musiconhold.so

Теперь вы можете проверить, загружается ли ваша музыка на удержание с базы данных, запустив moh showclasses:

*CLI> moh show classes

Class: general

Mode: files

Directory: /var/lib/asterisk/moh

И вот вы видите: musiconhold.conf загружен из базы данных. Если у вас есть проблемы с перезагрузкой модуля, загружающего данные в память, попробуйте перезапустить Asterisk. Вы можете выполнить те же действия для загрузки других файлов конфигурации из базы данных, если это необходимо.

Когда использовать preload в modules.conf для Realtime модулей

В modules.conf иногда вам может потребоваться загрузка модулей подключения к базам данных на ранней стадии с использованием директивы preload. Причина в том, что определенные файлы, такие как manager.conf, cdr.conf и rtp.conf, не являются внешними модулями, а скорее загружаются изнутри когда запускается Asterisk. Кроме того, если эти файлы, такие как manager.conf, хотят использовать именованные списки ACL из базы данных, вам также потребуется предзагрузка в данной ситуации.

Если бы мы использовали ODBC в качестве интерфейса базы данных в реальном времени, то нам нужно было бы добавить следующие строки в modules.conf сразу после опции autoload:

; modules.conf

[modules]

autoload=yes

preload => res_odbc.so

preload => res_odbc_config.so

Динамический Realtime

Система динамического Realtime используется для загрузки объектов, которые могут часто меняться, таких как SIP/IAX2 пользователи и пиры, очереди и их участники, а также сообщения голосовой почты.

Точно так же, когда новые записи, вероятно, будут добавляться на регулярной основе, мы можем использовать возможности базы данных чтобы позволить нам загружать эту информацию по мере необходимости.

Все для Realtime настроено в файле /etc/asterisk/extconfig.conf; однако динамический Realtime имеет явно определенные имена конфигурации. Все предопределенные имена должны быть настроены под заголовком [settings]. Например, определение пиров SIP выполняется в следующем формате:

; extconfig.conf

[settings]

sippeers => driver,database[,table]

Имя таблицы является необязательным. Если оно опущено, Asterisk будет использовать предопределенное имя (например sippeers), чтобы идентифицировать таблицу для поиска данных.

В нашем примере мы будем использовать таблицу ast_sippeers для хранения информации о SIP-пирах. Таким образом, чтобы настроить Asterisk для загрузки всех SIP-пиров из нашей базы данных в реальном времени, мы бы определили что-то вроде этого:

; extconfig.conf

[settings]

sippeers => odbc,asterisk,ast_sippeers

Предопределенные динамические имена для Realtime в extconfig.conf

Следующие имена предопределены для динамического Realtime:

iaxusers — IAX пользователи
iaxpeers — IAX пиры
sippeers — SIP пиры и пользователи
sipregs — регистрации SIP
voicemail — ящики голосовой почты
extensions — диалплан
meetme — MeetMe конференции
queues — очереди
queues_members — участники очередей
acls — списки доступа управления
musiconhold — музыка на удержание
queue_log — логирование очередей

Пользователи и пиры SIP загружаются из одной таблицы, определяемой помощью спекции sippeers из extconfig.conf. Это связано с тем, что будет поле type (точно так же, как если бы мы определяли тип в файле sip.conf), который позволит нам определить тип user, peer или friend. Если вы выгрузите chan_sip.so и затем загрузите его обратно в память (т.е. используя moduleunload chan_sip.so, а затем module load chan_sip.so) после настройки extconfig.conf, вас будут приветствовать некоторые предупреждения, сообщающие вам, какие столбцы вам не нужны для таблицы в Realtime. Если бы вы загружались из Realtime, то получили бы следующий аналогичный вывод в консоли (который был обрезан из-за требований к пространству):