Использование PostgreSQL для работы с механизмом RealTime


Оригинал: http://www.voip-info.org/wiki/view/Asterisk+RealTime+PostgreSQL

Итак, вместо того, чтобы искать этот материал по разным местам, подумалось, что будет проще найти все на одной, где будет расписано все об использовании PostgreSQL с механизмом RealTime.
Несмотря на то, что PostgreSQL может использоваться для хранения CDR записей, он не может дальше использоваться с системой голосовой почты (voicemail). Таким образом, если Вы используете старый механизм общения с pgsql для управления системой голосовой почты, с использованием базы данных, то, после модернизации системы, Вы сможете использовать систему unixODBC. Также, предполагается простой переход на использование подсистемы unixODBC для хранения данных CDR. На данный момент нет точных данных о различиях в производительности этих двух методов, но думается, что незначительная разница в overhead не такая уж большая, чтобы разница в производительности была бы слишком заметна. Во всяком случае, удобней пользоваться одним механизмом общения с базой данных, и тут описывается, как заставить механизм RealTime и сохранение данных CDR использовать для работы подсистему unixODBC.

Тут описываются таблицы, которые необходимо создать для работы механизма RealTime. Так же, в таблицу для хранения CDR записей включены некоторые модификации. Планировалось использование этой системы совместно с системой репликации данных в реальном времени: (http://www.commandprompt.com), это подразумевает, что все таблицы должны иметь основной индекс (primary key). Для этого былл добавлено описание primary key в описании для создания таблицы cdr table. Далее, были добавлены, подходящие для каждого поля (ну для кого как), значения по умолчанию. Так же были изменены размерности полей в таблице для отражения реалий, с которыми мы сталкиваемся на практике. Существует тенденция к использованию очень большой секции appdata для некоторых екстеншенов, с тех пор как началось использование app_sql для хранения параметров, для производимых действий из плана набора, в базе данных.

ЗАМЕЧАНИЕ: Использовался PostgreSQL 8.1


Описание таблицы для CDR:


CREATE TABLE cdr (
cdr_pkey serial PRIMARY KEY,
calldate timestamp with time zone NOT NULL default now(),
clid text NOT NULL default '',
src text NOT NULL default '',
dst text NOT NULL default '',
dcontext text NOT NULL default '',
channel text NOT NULL default '',
dstchannel text NOT NULL default '',
lastapp text NOT NULL default '',
lastdata text NOT NULL default '',
duration bigint NOT NULL default '0',
billsec bigint NOT NULL default '0',
disposition text NOT NULL default '',
amaflags bigint NOT NULL default '0',
accountcode text NOT NULL default '',
uniqueid text NOT NULL default '',
userfield text NOT NULL default ''
);


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


Файл конфигурации Asterisk: cdr_odbc.conf


; cdr_odbc.conf
;
[global]
dsn=AsteriskCdr
username=asterisk
password=xxxxx
loguniqueid=yes
dispositionstring=yes
table=cdr ;"cdr" - имя таблицы, по умолчанию.
usegmtime=no ; установите в "yes", для использования времени в GMT.


Voicemail для механизма ))RealTime ((.


CREATE TABLE voicemail (
uniqueid serial PRIMARY KEY,
customer_id varchar(11) NOT NULL default '0',
context varchar(50) NOT NULL default '',
mailbox varchar(11) NOT NULL default '0',
password varchar(5) NOT NULL default '0',
fullname varchar(150) NOT NULL default '',
email varchar(50) NOT NULL default '',
pager varchar(50) NOT NULL default '',
tz varchar(10) NOT NULL default 'EST',
attach varchar(4) NOT NULL default 'yes',
saycid varchar(4) NOT NULL default 'yes',
dialout varchar(10) NOT NULL default '',
callback varchar(10) NOT NULL default '',
review varchar(4) NOT NULL default 'no',
operator varchar(4) NOT NULL default 'no',
envelope varchar(4) NOT NULL default 'no',
sayduration varchar(4) NOT NULL default 'no',
saydurationm int2 NOT NULL default '1',
sendvoicemail varchar(4) NOT NULL default 'no',
delete varchar(4) NOT NULL default 'no',
nextaftercmd varchar(4) NOT NULL default 'yes',
forcename varchar(4) NOT NULL default 'no',
forcegreetings varchar(4) NOT NULL default 'no',
hidefromdir varchar(4) NOT NULL default 'yes',
stamp timestamp NOT NULL default now(),
UNIQUE (context,mailbox)
);


IAX peers/users для механизма RealTime.



CREATE TABLE iax_buddies (
name varchar(30) primary key NOT NULL,
username varchar(30),
type varchar(6) NOT NULL,
secret varchar(50),
md5secret varchar(32),
dbsecret varchar(100),
notransfer varchar(10) DEFAULT 'yes',
inkeys varchar(100),
outkeys varchar(100),
auth varchar(100) NOT NULL DEFAULT 'md5',
accountcode varchar(100),
amaflags varchar(100),
callerid varchar(100),
context varchar(100) NOT NULL,
defaultip varchar(15),
host varchar(31) NOT NULL DEFAULT 'dynamic',
language char(5),
mailbox varchar(50),
deny varchar(95),
permit varchar(95),
qualify varchar(4) DEFAULT 'yes',
disallow varchar(100) NOT NULL DEFAULT 'all',
allow varchar(100) NOT NULL DEFAULT 'ulaw',
ipaddr varchar(15),
port integer DEFAULT 0,
regseconds integer DEFAULT 0,
UNIQUE (username)
);

Замечание: Обратите внимание, что поля name и username одлжны иметь уникальные значения в таблице. В этом моменте, правда есть один спорный момент: the name is what your remote IAX clients need to use as a username. Смотри пример ниже на странице.


Екстеншены для механизма RealTime.


CREATE TABLE extensions (
id serial,
context varchar(40) NOT NULL default '',
exten varchar(40) NOT NULL default '',
priority int4 NOT NULL default 0,
app varchar(40) NOT NULL default '',
appdata varchar(256) NOT NULL default '',
PRIMARY KEY (context,exten,priority),
UNIQUE (id)
);


Итак, отредактируем файл extconfig.conf для использования всего вышенаписанного, например так:

[settings]
iaxusers => odbc,asterisk,iax_buddies
iaxpeers => odbc,asterisk,iax_buddies
;sipusers => odbc,asterisk
;sippeers => odbc,asterisk
voicemail => odbc,asterisk,voicemail
ext_switch => odbc,asterisk,extensions

Тут используется одно имя таблицы для описаний iaxusers и iaxpeers. Если вы хотите настроить более "удобную" систему и разделить описания клиентов по типам peers, users и friends, тогда Вам нужно создать две таблицы, а не одну.


И наконец, для того, чтобы все это заработало как надо, можно добавить switch директиву в описание плана набора, например так:

[iaxswitch]
switch => Realtime/mycontext@ext_switch


Для вставки строк используем, например:

INSERT INTO extensions VALUES (1, 'mycontext', '2815551212', 1, 'Playback', 'pbx-invalid');
INSERT INTO extensions VALUES (1, 'mycontext', '_617555XXXX', 1, 'Voicemail', 'u1013@default');

INSERT INTO iax_buddies (name,username,type,secret,auth,callerid,mailbox,context) values ('test-1013','test1013','friend','xxxx','md5','"Test User" <1013>','1013','iaxswitch');

INSERT INTO voicemail (context,mailbox) values ('default','1013');


Ть проверим работу с помощью IAXy, ниже приведен пример, при условии использования iaxyprov из cvs:

; IAXY Provisioning Realtime testing

dhcp
server: 192.168.123.121
user: test-1013
pass: xxxx
register
codec: ulaw
;codec: adpcm


Ссылки по теме: