Pull to refresh

Comments 20

отличная статья! давно хотел реализовать у себя на астериске.
Спасибо! пойду ковырять.
Спасибо) если обнаружите какие нибудь улучшения или замечания по коду прошу писать в комментарии) исправим в статье)
Все бы компании внедрили данный функционал. Ибо хорошо когда ты общаешься в компании партнере (назовем ее так) с одним человек и увидев пропущенный с номера этой компании знаешь кому звонить, а когда с несколькими людьми — вот и гадаешь, а кто ж звонил то :) Или вообще компания не знакомая.

Даешь в массы!
Хорошо бы добавить в статью, как завести логи/cdr в MYSQL asteriskcdrdb, наверняка у многих стоит чистый астериск.
Возьмиие литературу по asterisk и почитайте. Там все прекрасно изложено. И да. Если автор сюда ввложит как прикреплять БД то она будет уже неактуальна для asterisk 1.8 и выше так как asterisk 1.6 который испоьзуется в trixbox работает с другими файлами для настройки cdr в mysql.

А статья да- хорошая. Правильный подход.
Например в чистом виде Asterisk цепляется примерно
так
1. Создаем пользователя MySQL для работы только с БД CDR;

2. Создаем базу для CDR
mysql> create database asteriskcdrdb;

3. Создаем таблицу:
mysql> CREATE TABLE IF NOT EXISTS `asteriskcdrdb` (
`id` int(9) unsigned NOT NULL AUTO_INCREMENT,
`calldate` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
`clid` varchar(80) NOT NULL DEFAULT '',
`src` varchar(80) NOT NULL DEFAULT '',
`dst` varchar(80) NOT NULL DEFAULT '',
`dcontext` varchar(80) NOT NULL DEFAULT '',
`channel` varchar(80) NOT NULL DEFAULT '',
`dstchannel` varchar(80) NOT NULL DEFAULT '',
`lastapp` varchar(80) NOT NULL DEFAULT '',
`lastdata` varchar(80) NOT NULL DEFAULT '',
`duration` int(11) NOT NULL DEFAULT '0',
`billsec` int(11) NOT NULL DEFAULT '0',
`disposition` varchar(45) NOT NULL DEFAULT '',
`amaflags` int(11) NOT NULL DEFAULT '0',
`accountcode` varchar(20) NOT NULL DEFAULT '',
`uniqueid` varchar(32) NOT NULL DEFAULT '',
`userfield` varchar(255) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `calldate` (`calldate`),
KEY `accountcode` (`accountcode`),
KEY `uniqueid` (`uniqueid`),
KEY `dst` (`dst`),
KEY `src` (`src`));

4. Меняем конфиг в cdr_mysql.conf на примерно следующий:
[global]
hostname=IP_Адрес_сервера_с_базой
dbname=Имя_базы_данных_(например_asteriskcdrdb)
table=Называние_таблицы_для_CDR_(например_cdr)
user=Пользователь_БД
password=Пароль_пользователя_БД
port=Порт_на_котором_слушает_БД

5. И разумеется не забыть проверить загрузку модуля:
modules.conf
добавляем следующие строки (если нет):
load => cdr_addon_mysql.so

Если ничего не забыл должно работать.
Поправка, создание таблицы уже от пользователя и проверить права на нее. А так же CREATE TABLE IF NOT EXISTS `asteriskcdrdb` читать как CREATE TABLE IF NOT EXISTS `cdr`.
Правильной дорогой идете товарищ!

Разрешите добавить рекомендацию к вашему решению.

По умолчанию, asterisk может писать еще в несколько полей, одно из них `disposition` — статус вызова, значения в это поле устанавливаются такие «ANSWERED», «NO ANSWER», «BUSY», «FAILED», а еще есть поля `duration` (общая продолжительность вызова) и `billsec` (общее время разговора).

Так вот, на мой взгляд, было бы верным, делать еще две проверки 1-ую по статусу, т.е. если статус был не «ANSWERED» — однозначно переводить на вызывавшего абонента, и вторую, если статус был «ANSWERED» и время разговора (billsec) меньше 3-х секунд — также переводить на вызывавшего абонента.

p.s. если идея не понятна — могу продолжить развивать свою мысль дальше =)
Идея понятна =) реализовать не сложно) по сути подправить только запрос mysql) как доберусь до trixbox'a, накидаю и добавлю в статью обновленный dialplan. Спасибо за идею)
идею реализовал) добавил в статью.
Кстати по поводу запросов в БД — MYSQL уже подключен ( иначе бы cdr не мог писаться в базу) к asterisk поэтому запросы к БД лучше делать через механизм func_odbc.conf
предложил бы запросы вынести в ODBC. В интернетах как то негативно относятся к mysql, особенно в диалпланах.
если база разрастется, то на медленном железе и при больших объёмах — будет огромная задержка входящего звонка, что не всегда на руку.
неправда. В январе делал тесты на Live-системе, при полностью забитых 24х каналах на sip никак на задержку не отразилось. Средняя длительность звонка у меня 55 секунд, объёмы посчитайте сами. Если честно не вижу связи в скорости запроса между запросом напрямую астером, и через ODBC. Есть пруф?

Год назад делал другие тесты. Если есть задержка и не было обрыва звонка изза позднего ответа — нужно чтобы mysql тупил менее ~2х секунд, не больше. Если более — будет обрыв звонка. Тестировал на телефонной книге.
Если более — будет обрыв звонка. Тестировал на телефонной книге.

Я об этом и говорю. просто сужу как долго отвечает база ipcad записанная в mysql (данных примерно за год)
может как то резать базу на периоды, кварталы? если оставить так как сейчас есть, то с обрывами можно столкнуться уже через пару месяцев.
у меня база не чистилась больше года. Проблем нет. Правда говоря, ODBC…
Проц i5, 4 оперативы. До этого было 2 ксеона модели 2008 года — ксеоны давали бульканье при постоянной нагрузке 100%, а i5 — всё норм, максимум нагрузки что видел это 50%.
в статью добавил update. Прирост в скорости явно заметен. В базе на текущий момент 1,131,661 запись. Asterisk крутится на старом HP dl140 c xeon 5140 и 2Gb ОЗУ.

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

Sign up to leave a comment.

Articles