Текст книги "Asterisk™: будущее телефонии Второе издание"

Автор книги: Джим Меггелен

Соавторы: Джаред Смит,Лейф Мадсен
сообщить о нарушении

Текущая страница: 23 (всего у книги 41 страниц)

Теперь, когда новая страница создана, необходимо отредактировать файл cfgbasic.html, чтобы добавить эту страницу как панель GUI. Откройте файл cfgbasic.html, найдите JavaScript-функцию returnpanels и вставьте этот код в список панелей в том месте, где вы хотите разместить свою панель:

newpanel( ["Test", "test.html", "Test"]); Теперь перезагрузите GUI в своем броузере. Слева должна появиться новая вкладка Test (Проверка), и после щелчка по ней будут отображаться значения конфигурации для файла extensions.conf. Это всего лишь малая часть того, что можно рассказать об интерфейсе AJAM и Asterisk GUI, но данный пример служит только для того, чтобы продемонстрировать вам, как просто вводить новую функциональность в GUI. В следующем примере будет показано, как легко выводить в GUI настройки из конфигурационных файлов.

Вывод настроек конфигурации в GUI

Как говорилось ранее, одно из уникальных преимуществ Asterisk GUI по сравнению с другими графическими интерфейсами для Asterisk в том, что он обновляет существующие конфигурационные файлы, предпринимая при этом специальные меры для предотвращения перезаписи или удаления каких-либо дополнительных настроек, которые могут присутствовать в конфигурационных файлах. Чтобы продемонстрировать ту простоту, с которой можно предоставлять новые настройки в GUI, добавим в GUI простой флажок, обеспечивающий возможность задавать настройку nat в файле users.conf.

Если открыть GUI и щелкнуть по вкладке Users (Пользователи), GUI загрузит файл users.html в iframe. Откроем afqk users.html (обычно располагающийся в gfgrt /var/lib/asterisk/static-http/config) и начнем изменять его, чтобы добавить наш флажок.

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

fieldnames.push('nat'); Таким образом мы сообщаем Asterisk GUI о том, что хотим иметь возможность видеть, а также задавать значение nat. Однако, чтобы увидеть или задать значение, необходимо добавить элемент в HTML-фор– му. Для этого найдите в файле users.html флажок IAX и добавьте следующие строки между ним и флажком CTI.

NAT

Просто перезагрузите страницу – вот и все. Всего несколько дополнительных строк кода – и мы можем выводить настройку nat в GUI. Проще быть не может!

Занимаясь формированием Asterisk GUI, вы, вероятно, обнаружите, что отладка кода Ajax и JavaScript порой может вызывать некоторые трудности. Мы настоятельно рекомендуем использовать расширение для Mozilla/Firefox под названием Firebug, которое существенно упрощает задачу по отладке Ajax, JavaScript и HTML. Его можно найти по адресуhttp://www.getfirebug.com. Существует также упрощенная версия для Internet Explorer, известная как Firebug Lite, которую можно скачать на том же веб-сайте.

Дополнительная информация

В данной главе были представлены Asterisk GUI и инфраструктура AJAM. Мы рассмотрели модель работы GUI и то, как его можно изменять. Дополнительную информацию по разработке графического интерфейса для Asterisk можно найти в руководстве для разработчиков GUI (GUI Developers Guide) по адресуhttp://asterisknow.org/developers/gui-guide.

По договору между издательством «Символ-Плюс» и Интернет-магазином «Books.Ru – Книги России» единственный легальный способ получения данного файла с книгой ISBN 978-5-93286-128-8, название «Asterisk™: будущее телефонии, 2-е издание» – покупка в Интернет-магазине «Books.Ru – Книги России». Если Вы получили данный файл каким-либо другим образом, Вы нарушили международное законодательство и законодательство Российской Федерации об охране авторского права. Вам необходимо удалить данный файл, а также сообщить издательству «Символ-Плюс» ([email protected]), где именно Вы получили данный файл.12

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

Ничто так не раздражает, как хороший пример.

– Марк Твен

Введение

В данной главе мы собираемся исследовать вопросы интеграции некоторых функций Asterisk и системы управления базами данных (СУБД). Для работы с Linux доступно несколько СУБД, но мы решили ограничить наше обсуждение PostgreSQL. Мы прекрасно понимаем, что MySQL – тоже чрезвычайно популярная СУБД, но надо было остановиться на какой-то одной, и наш опыт работы с PostgreSQL перевесил чашу весов в ее пользу. Фактически будет обсуждаться ODBC-коннек– тор, поэтому, если ваша база данных поддерживает работу через ODBC, содержание данной главы будет вам полезным.

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

Установка СУБД PostgreSQL

Первое, что надо сделать, – это установить сервер базы данных Post– greSQL[110]110
  Для большой, сильно загруженной системы рекомендуется устанавливать его отдельно от системы Asterisk, на другом компьютере.


[Закрыть].

# yum install -y postgresql-server

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

# service postgresql start

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

# su – postgres $ 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 USER

По умолчанию PostgreSQL не слушает TCP/IP-соединение, которое будет использовать Asterisk. Необходимо внести изменения в файл /var/ lib/pgsql/data/postgresql.conf, чтобы Asterisk могла устанавливать IP– соединения с базой данных. Для этого просто удалим символ комментария перед параметрами tcpip_socket и port. Не забудьте изменить значение tcpip_socket с false на true. tcpip_socket = true max_connections = 100

# примечание: увеличение max_connections стоит

# выделения примерно 500 байтов совместно

# используемой памяти на каждое соединение,

# кроме памяти, выделяемой под shared_buffers

# и max_locks_per_transaction. #superuser_reserved_connections = 2 port = 5432

Теперь редактируем файл /var/lib/pgsql/data/pg_hba.conf, чтобы обеспечить возможность только что созданному пользователю asterisk устанавливать соединения с сервером PostgreSQL через TCP/IP. В конце файла замените все под комментарием # Разместите здесь свою фактическую конфигурацию следующим[111]111
  В данном примере серверу Asterisk разрешается устанавливать соединение с PostgreSQL и запрашивать пароль на доступ. - Примеч. науч.ред.


[Закрыть]:

host all asterisk 127.0.0.1 255.255.255.255 md5 local all asterisk trust

Теперь можно создать базу данных, которая будет использоваться в данной главе. Мы собираемся создать базу данных asterisk и задать в качестве владельца нашего пользователя asterisk. $ createdb –owner=asterisk asterisk CREATE DATABASE

Выйдя из учетной записи postgres и вернувшись в административную учетную запись, перезапустите сервер PostgreSQL: $ exit

# service postgresql restart

Наше соединение с сервером PostgreSQL через TCP/IP можно проверить следующим образом:

# psql -h 127.0.0.1 -U asterisk Password:

Welcome to psql 7.4.16, the PostgreSQL interactive terminal.

Type: copyright for distribution terms h for help with SQL commands ? for help on internal slash commands g or terminate with semicolon to execute query q to quit

asterisk=>

Повторно проверьте свою конфигурацию, как было показано ранее, если получена следующая ошибка, которая свидетельствует о том, что соединение через TCP/IP не разрешено:

psql: could not connect to server: Connection refused

Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432?

(psql: невозможно установить соединение с сервером: В соединении отказано

Сервер работает на хосте "127.0.0.1" и принимает TCP/IP-соедине– ния через порт 5432?)

Установка и конфигурация ODBC

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

Прежде чем устанавливать коннектор в Asterisk, необходимо установить ODBC в самой Linux. Чтобы установить драйверы ODBC, просто выполним следующую команду:

# yum install -y unixODBC unixODBC-devel libtool-ltdl libtool-ltdl-devel

В главе 3 можно найти таблицу с пакетами, которые должны быть установлены.

Необходимо установить пакет unixODBC-devel, потому что Asterisk использует его для создания модулей ODBC, которые будут применяться в данной главе.

Убедитесь в наличии сконфигурированного ODBC-драйвера PostgreSQL в файле /etc/odbcinst.ini. Он должен выглядеть примерно так:

[PostgreSQL]

Description = ODBC for PostgreSQL Driver = /usr/lib/libodbcpsql.so

Setup = /usr/lib/libodbcpsqlS.so

FileUsage = 1

Убедитесь, что система видит драйвер, выполнив приведенную ниже команду. Если все хорошо, она должна возвратить имя метки используемой СУБД PostgreSQL. # odbcinst -q -d

[PostgreSQL]

Далее сконфигурируем файл /etc/odbc.ini, используемый для создания коннектора, который Asterisk будет применять для ссылки на эту конфигурацию. Если когда-то в будущем понадобится изменить базу данных или что-то еще, просто надо будет внести изменения в этот файл, не меняя ссылок в Asterisk[112]112
  Да, слишком много всего. На самом деле нужны только записи Driver,
  Database и Servername. Даже Username и Password задаются в другом месте, как вы увидите позже.


[Закрыть].

[asterisk-connector][asterisk-connector]
Description =	PostgreSQL connection to 'asterisk' database
Driver =	PostgreSQL
Database =	asterisk
Servername =	localhost
UserName =	asterisk
Password =	welcome
Port =	5432
Protocol =	7.4
ReadOnly =	No
RowVersioning =	No
ShowSystemTables =	No
ShowOidColumn =	No
FakeOidIndex =	No
ConnSettings =

Убедимся, что мы можем соединяться с нашей базой данных, используя приложение 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

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

# 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]113
  Опции pooling (создание пула) и limit (предел) довольно полезны для работы с базами данных MS SQL Server и Sybase. Они позволяют устанавливать с базой данных множество соединений (вплоть до limit), гарантируя при этом, что одновременно для каждого соединения выполняется только одно выражение (это обусловлено ограничением в протоколе, используемом этими серверами баз данных).


[Закрыть].

Внесем изменения в файл res_odbc.conf:

[asterisk]

enabled => yes

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 по мере необходимости и не требует перезагрузки. Архитектура реального времени настраивается в файле extconfig.conf, располагающемся в папке /etc/asterisk. Этот файл указывает Asterisk, что брать из базы данных и откуда именно, что обеспечивает возможность загружать некоторые файлы из базы данных, а другие – из стандатных конфигурационных файлов.

Статическая архитектура реального времени

Статическая архитектура реального времени используется, если требуется загрузить конфигурацию, которая обычно размещается в конфигурационных файлах в папке /etc/asterisk, из базы данных. Те же правила, которые применяются к плоским[114]114
  Плоскими являются двоичные файлы вида ключ-значение. Данные файлы позволяют быстрее осуществлять операции редактирования, добавления и удаления записей благодаря встроенным функциям Asterisk. - Примеч. науч. ред.


[Закрыть] файлам в системе, действуют и при использовании статической архитектуры реального времени. Например, требование выполнить команду перезагрузки из интерфейса командной строки Asterisk или перезагрузить модуль, связанный с конфигурационным файлом (то есть выполнить команду module reload chan_sip. so).

При использовании статической архитектуры реального времени мы указываем 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) (см. врезку «Несколько слов о значениях»).

filename

Имя файла, которое модуль в обычных условиях читал бы с жесткого диска системы (то есть musiconhold.conf, sip.conf, iax.conf и т. д.).

category

Имя раздела файла, такое как [general], но не надо сохранять его в базу данных в квадратных скобках.

var_name

Опция, располагающаяся слева от знака равенства (то есть disallow – это var_name в выражении disallow=all). var_val

Значение опции, располагающееся справа от знака равенства (то есть all – это var_val в выражении disallow=all).

commented

Любое отличное от 0 значение будет рассматриваться так, как если бы перед ним в плоском файле стояла точка с запятой (то есть оно было бы закоммментировано).

Несколько слов о значениях

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

Возьмем простой файл, который можно загрузить из статической архитектуры реального времени, musiconhold.conf file. Начнем с его перемещения во временную папку:

# cd /etc/asterisk

# mv musiconhold.conf musiconhold.conf.old

Чтобы удалить классы из памяти, необходимо перезапустить Asterisk. После этого, выполнив команду moh show classes, можно убедиться в отсутствии классов: *CLI> restart now *CLI> moh show classes *CLI>

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

INSERT INTO ast_config (filename,category,var_name,var_val) VALUES ('musiconhold.conf','general','mode','files'); INSERT INTO ast_config (filename,category,var_name,var_val) VALUES ('musiconhold.conf','general','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 | general | mode | files musiconhold.conf | general | directory| /var/lib/asterisk/moh (2 rows)

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

musiconhold.conf => odbc,asterisk,ast_config Подключимся к консоли Asterisk и выполним перезагрузку: *CLI> module reload

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

*CLI> moh show classes

Class: general

Mode: files

Directory: /var/lib/asterisk/moh

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

Динамическая архитектура реального времени

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

Все настройки архитектуры реального времени описываются в файле /etc/asterisk/extconfig.conf, но динамическая архитектура реального времени имеет строго определенные конфигурацонные имена, такие как sippeers. Описание равноправного участника SIP (SIP peer) выполняется в следующем формате: ; extconfig.conf

sippeers => драйвер,базаданных[,таблица] Имя таблицы является необязательным параметром. Если он не задан, Asterisk будет использовать предопределенное имя (то есть sippeers) как имя таблицы для поиска данных. В нашем примере для хранения информации равноправных участников SIP будет использоваться таблица ast_sip peers.

Помните, что у нас имеются и равноправные участники SIP (SIP peer), и пользователи SIP (SIP user); peer – это конечные точки, которым мы отправляем вызовы, а user направляют вызовы нам. friend – это сокращенная запись, определяющая оба типа конечных точек.

Таким образом, чтобы сконфигурировать Asterisk на загрузку всех равноправных SIP-участников из базы данных в режиме реального времени, необходимо записать примерно следующее:

; extconfig.conf

sippeers => odbc,asterisk,ast_sipfriends Чтобы также загружать наших SIP-пользователей из базы данных, задаем следующее:

sipusers => odbc,asterisk,ast_sipfriends

Вероятно, вы обратили внимание, что и для sippeers, и для sipusers используется одна и та же таблица. В ней есть поле типа (точно так же, как если бы тип был определен в файле sip.conf), поэтому для извлечения информации мы можем задавать тип user, peer или friend. При описании таблицы для пользователей и равноправных участников необходимо как минимум следующее:

В обязательных полях port, regseconds и ipaddr Asterisk сохраняет регистрационную информацию равноправного участника, чтобы знать, куда направлять вызов. Предполагается, что хост является dynamic; однако, если бы равноправный участник был static, нам пришлось бы заполнять поле ipaddr самостоятельно. Поле port является необязательным. Если для него используется стандартный порт, указанный в разделе [general], поле regseconds остается пустым. Для SIP-друга можно определить множество других опций, таких как ID вызывающего абонента. Чтобы добавить эту информацию, требуется просто вставить дополнительный столбец callerid в таблицу. Другие опции, которые могут быть определены для соединения SIP типа friend, можно найти в файле sip.conf.sample.

Хранение записей параметров вызовов

Записи параметров вызовов (Call Detail Records, CDR) содержат информацию о вызовах, прошедших через систему Asterisk. Более подробно они обсуждаются в главе 13. Хранение CDR – один из самых популярных примеров использования баз данных в Asterisk, потому что в этом случае с CDR проще работать (например, можно отслеживать несколько систем Asterisk в одной таблице).

Создадим в нашей базе данных таблицу для хранения CDR. Зарегистрируемся на сервере PostgreSQL с помощью приложения psql: # psql -U asterisk -h localhost asterisk

Password:

И создадим таблицу asterisk_cdr:

asterisk=> CREATE TABLE asterisk_cdr (

id bigserial NOT NULL, calldate timestamptz,

Задание параметра systemname для глобальных уникальных идентификаторов

CDR состоят из уникального идентификатора и нескольких полей информации о вызове (включая источник и канал назначения, продолжительность вызова, приложение, выполняемое последним, и т. д.). В кластере серверов Asterisk теоретически возможно дублирование уникальных идентификаторов, поскольку каждая система Asterisk учитывает только саму себя. Чтобы решить эту проблему, можно автоматически добавлять идентификатор системы в начало уникального ID. Для этого введем дополнительную опцию в файл /etc/asterisk/asterisk.conf и зададим идентификатор для каждого из серверов: [options]

systemname=toronto

clid varchar(80), src varchar(80), dst varchar(80), dcontext varchar(80), channel varchar(80), dstchannel varchar(80), lastapp varchar(80), lastdata varchar(80), duration int8, billsec int8, disposition varchar(45), amaflags int8, accountcode varchar(20), uniqueid varchar(40), userfield varchar(255),

CONSTRAINT asterisk_cdr_id_pk PRIMARY KEY (id)

)

WITHOUT OIDS;

Убедиться в том, что таблица создана, можно с помощью команды dt (describe tables):

asterisk=> dt asterisk_cdr

List of relations

Schema | Name | Type | Owner + + +

public | asterisk_cdr | table | asterisk (1 row)

Далее конфигурируем Asterisk на хранение ее CDR в базе данных. Это выполняется в файле /etc/ asterisk/cdr_odbc.conf с помощью следующих настроек:

[global]

dsn=asterisk-connector

username=asterisk password=welcome loguniqueid=yes table=asterisk_cdr

Если Asterisk уже запущена, из интерфейса командной строки Asterisk выполняем команду module reload cdr_odbc.so. Также можно просто ввести reload, чтобы выполнить полную перезагрузку. *CLI> reload

Проверим статус CDR. Для этого введем следующую команду и найдем в выводе строку CDR registered backend: ODBC:

*CLI> cdr status

CDR logging: enabled CDR mode: simple

CDR registered backend: cdr-custom

CDR registered backend: cdr_manager

CDR registered backend: ODBC

Теперь выполним вызов через сервер Asterisk, а потом проверим наличие данных о нем в таблице asterisk_cdr. Самый простой способ протестировать вызов – использовать CLI-команду Asterisk console dial (предполагается, что имеется звуковая карта и установлен модуль chan_oss). Однако для выполнения тестового звонка можно использовать любой имеющийся в распоряжении метод: *CLI> console dial 100@default

– Executing [100@default:1] Playback("OSS/dsp", "tt-weasels") in new stack – Playing 'tt-weasels' (language 'en')

Затем установим соединение с базой данных и выполним запрос SELECT для проверки наличия данных в таблице asterisk_cdr. Также можно выполнить команду SELECT * FROM asterisk_cdr;, но в этом случае будет возвращено намного больше данных: # psql -U asterisk -h localhost asterisk Password:

asterisk=> SELECT id,dst,channel,uniqueid,calldate FROM asterisk_cdr;

id | dst | channel | uniqueid | calldate

–+ + + +

1 | 100 | OSS/dsp | toronto-1171611019.0 | 2007-02-16 02:30:19-05 (1 rows)

Ощутим могущество func_odbc: система «горячих столов»

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

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

Хотя применение внешнего сценария для взаимодействия с базой данных (из которой создается плоский файл для Asterisk) имеет свои преимущества (если база данных дает сбой, система будет продолжать функционировать и сценарий просто не будет обновлять файлы до восстановления соединения с базой данных), основной недостаток в этом случае в том, что любые изменения, вносимые вами для пользователя, остаются недоступными, пока не будет выполнен сценарий обновления. Возможно, это не является большой проблемой для маленьких систем, но в больших системах ожидание вступления в силу внесенных изменений может привести к неприятностям, таким как прерывание активного вызова на время загрузки или синтаксического разбора большого файла. Ослабить негативные эффекты можно, применяя систему баз данных с дублированием. В версии Asterisk, следующей за 1.4 (в настоящее время эта версия готовится к выпуску[115]115
  Сейчас уже доступна версия 1.6. - Примеч. науч.ред.


[Закрыть]) синтаксис файла func_odbc.conf изменится не сильно, но обеспечит возможность в случае отказа перейти к другой СУБД. Таким образом, можно будет кластеризовать серверную часть базы данных, используя отношение ведущий-ведущий (pgcluster; Slony-II) или систему дублирования ведущий-ведомый (Slony-I).

Чтобы вы получили правильное представление о рассматриваемом далее материале, представьте себе дагвудовский сэндвич[116]116
  А если вы не знаете, что это такое, как раз для этого случая и существует Википедия. Я вовсе не шучу.


[Закрыть]. Можно ли описать всю гамму впечатлений от такого блюда, только представив изображение помидора или помахав перед носом кусочком сыра? Вряд ли. С этой же проблемой мы сталкиваемся, пытаясь придумать хороший пример, объясняющий, в чем мощь func_odbc. Поэтому мы решили «приготовить сэндвич полностью». Рецепт довольно сложен, но, попробовав этот сэндвич, вы не захотите ничего другого. Для нашего примера мы решили реализовать то, что, по нашему мнению, могло бы иметь практическое применение. Представим небольшую компанию, в отделе продаж которой насчитывается пять человек и им приходится делить между собой два рабочих стола. Это не так ужасно, как может показаться, потому что эти ребята большую часть времени находятся в разъездах и проводят в офисе максимум один день в неделю.