Как посмотреть ошибки asterisk

Configure Asterisk logging

1. Edit the logger.conf file to enable specific logger channels to output to your filesystem. The word «debug_log_123456» can be changed to anything you want, as that is the filename the logging will be written to.

Modify the file name «debug_log_123456» to reflect your issues.asterisk.org issue number.

logger add channel debug_log_123456 notice,warning,error,debug,verbose,dtmf

Configure verbosity levels and rotate logs

2. From the Asterisk CLI, set the verbose and debug levels for logging (this affects CLI and log output) and then restart the logger module:

Optionally, if you’ve used this file to record data previously, then rotate the logs:

Enable channel tech or feature specific debug

2.1. Depending on your issue and if a protocol level trace is requested, be sure to enable logging for the channel driver or other module.

pjsip set logger on

sip set debug on

sip set debug

iax2 set debug on

iax2 set debug

Issue reproduction and clean up

3. Now that logging is configured, enabled and verbosity is turned up you should reproduce your issue.

4. Once finished, be sure to disable the extra debugging:

4.1. Again, remember to disable any extra logging for channel drivers or features.

SIP (1.4 or higher)

IAX2 (1.4 or higher)

5. Disable logging to the filesystem. Edit the logger.conf file and comment out or delete the line you added in step 1. Using a semi-colon as the first character on the line will comment out the line.

Then reload the logger module (or restart Asterisk) as you did in step 2:

Provide debug to the developers

6. Upload the file located in /var/log/asterisk/debug_log_123456 to the issue tracker.

Log-файлы. Для чего они нужны, где их искать и как использовать?

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

В конфигурационном каталоге asterisk (по умолчанию /etc/asterisk) находится несколько файлов, отвечающих за логи:
1.Файл asterisk.conf содержит переменную astlogdir, которая указывает местоположение логов asterisk (по умолчанию — /var/log/asterisk)

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

Полный список и расположение лог файлов следующий:

•  /var/log/asterisk/fail2ban — Лог-файл событий модуля fail2ban
•  /var/log/asterisk/freepbx.log — Лог-файл событий событий модулей FreePBX
•  /var/log/asterisk/freepbx_security.log — Лог-файл событий событий безопасности
•  /var/log/asterisk/full — Лог-файл событий Asterisk всех уровней. Этот файл чаще всего используется для поиска старых звонков.
•  /var/log/dmesg — Лог-файл событий событий уровня ядра
•  /var/log/httpd/access_log — Лог-файл событий доступа к Apache
•  /var/log/httpd/error_log — Лог-файл где можно посмотреть ошибки web сервера Apache
•  /var/log/messages — Системный журнал событий Linux
•  /var/log/yum.log — Лог-файл где записаны действия выполненных через yum

Обратите внимание, что в зависимости от используемого дистрибутива Linux место расположение log-файлов может отличаться.Тем не менее, настраивать какие-то дополнительные условия для логирования мы не будем. Как было написано выше – стандартный путь логов следующий: /var/log/asterisk. Перейдем туда

Как можете видеть – здесь содержится огромное количество логов очередей, фаервола и много чего еще, но в данном случае нас интересует полный лог станции с одноименным названием full. Есть два способа прочесть содержимое:

1 С помощью текстового редактора (vi/vim/nano)
2 С помощью утилиты grep

И мы даже не будем рассматривать просмотр лога с помощью текстового редактора. Вне зависимости от того, какой текстовый редактор вы будите использовать открывать весь лог-файл не оптимальное решение и удобнее использовать для этого утилиту grep. Grep это утилита командной строки которая используется для фильтрации текста по заданному шаблону. Пример: предположим, что интересующий момент произошел сегодня ночью (20 августа) в 04:42:58.

Используем следующую команду # grep ’04:42:58′ full

Как можете видеть утилита вывела все события которые произошли в указанное время, однако нам нужен полный лог связанный с этим событием и есть возможность его вывести игнорируя все остальные события. Для этого обратите внимание на значение [C-00004aec]

Это UID звонка и для каждого он уникален и позволяет по нему просмотреть все события связанные с этим звонком.

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

Некоторые дополнительные ключи команды grep:

•   -v : Выводи реверсивные результаты. Вместо того чтобы вывести строки где искомое было найдено — выводи те строки где искомой подстроки нет.
•   -c : Отключает стандартный способ вывода результата и вместо этого отображает только число обозначающее количество найденых строк.
•   -i : Делает поиск регистронезависимым
•   -w : Ведет поиск по цельным словам. Например, при обычном поиске строки ‘200’ grep может найти слово ‘81002002020. А если используется данный ключ то будут найдены только строки где есть слово ‘200’.
•   -l : Выводит только имена файлов, где была найдена строка.
•   -r : Производит поиск рекурсивно по всем поддиректориям.

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

Просмотр логов через Web-интерфейс

По каким-то причинам у вас не может оказаться доступа на АТС по ssh и в таком случае вы можете просмотреть логи на web-интерфейсе FreePBX с помощью модуля Asterisk Log Files. Этот модуль расположен по следующему пути: Reports — Asterisk Log Files

После попадаем мы на следующую страничку

Как можете видеть, уже без каких либо манипуляций модуль подгрузил последние логи со станции без каких либо фильтров

Есть возможность просматривать все логи не только за сегодняшнее число, но и за прошлые, а так же конкретно какой-то log-файл просмотреть.

Давайте для примера посмотрим подробную статистику по одному из звонков.

Как можете видеть поле Filtre выполняет ту же роль что и утилита grep

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

Модуль Support FreePBX

Обратите внимание, что данный модуль был включен в дистрибутив начиная с 13 версиии FreePBX.

Это очень полезная секция, которая позволяет получить доступ к логам. Благодаря ей можно скачать zip-файл, который будет содержать отчет с необходимой информацией, а так же логами для дальнейшего их исследования. Чтоб попасть на страничку модуля нужно пройти по следующему пути: Admin — System Admin

И мы попадаем в System Admin.

Здесь множество полезных утилит для администратора, но в данной статье нас интересует модуль Support.  вниз и выбираем раздел

Выбираем раздел «Support»

На этой странице и можно скачать zip-архив с отчетом. Путем выбора ответа Yes/No можно сформировать свой отчет. Пункты выбора следующие:

• FreePBX Versions — Список всех установленных модулей и их версии
• System Information — Информация об операционной системе
• Asterisk Logs — Журналы событий Asterisk за последние 24 часа
• Firewall Setting — Вывод текущих настроек ip-tables
• ASTDB Dump — Полный дамп ASTBD (Не путать с MySQL)
• License Information — Информация о лицензировании и статусе сервера
• Dialplan — Полный дайл-план, созданный FreePBX (включая кастомные файлы _custom)
• SIP Settings — Настройки SIP (Может содержать секретную информацию)
• PJSIP Settings — Настройки PJSIP (Может содержать секретную информацию)
• IAX Settings — Настройки IAX (Может содержать секретную информацию)

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

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

Так же вам могут быть интересны следующие темы по логированию:

Сбор логов на одном сервере с нескольких других, посредством SysLog

Расширенное логгирование звонков: CEL — Channel Event Logging

Сбор статистики звонков по региональным направлениям 

Глава 21

Системный мониторинг и журналирование

Хаос
присущ всем сложным вещам.

Стремитесь
с усердием.

—
Будда

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

logger.conf

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

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

Файл /etc/asterisk/logger.conf
позволяет вам определить различные
уровни журналирования для многих файлов,
если нужно. Он обладает великолепной
гибкостью, но это может привести к
запутанности.

Формат записей в файле
logger.conf следующий:

filename =>
type[,type[,type[,…]]]

Это простой файл logger.conf,
который идет с исходниками Asterisk, но не
стоит просто копировать файл примера,
мы рекомендуем использовать следующее
в вашем начальном файле logger.conf:

[general]

[logfiles]

console => notice,warning,error,dtmf

messages => notice,warning,error

;verbose => notice,warning,error,verbose

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

$ asterisk -rx ‘logger reload’

или из Asterisk CLI:

*CLI> logger reload

Детализация журналирования: полезна, но опасна

Мы боролись с желанием
рекомендовать добавление следующей
строки в ваш logger.conf:

verbose => notice,warning,error,verbose

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

Используйте это. Это
фантастика. Но помните, что это нужно
отключить после завершения!

Вы можете указать любое имя
файла, но специальное имя
файла console
фактически будет
производить вывод в Asterisk CLI, а не в любой
файл на жестком диске. Все остальные
имена будут храниться в файловой системе
в каталоге /var/log/asterisk. Типы logger.conf
описаны в Таблице 24-1.

Таблица
24-1. Типы logger.conf

^a Это не теория. Это
произошло с нами и было невесело.

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

Существует
особенность у системы логирования
Asterisk, которая может вызвать у вас
некоторое замешательство, если вы не
знаете о ней. Уровень журналирования
для типов verbose
и debug
связан с детализацией, установленной
в консоли. Это означает, что если вы
пишете лог в файл с типом verbose
или debug,
а кто-то зашел в консоль CLI и дает команду
core set verbose 0, или core set debug 0
журналирование в ваш файл журнала будет
остановлено.

Просмотр журналов Asterisk

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

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

В Asterisk 11 введена функция
ведения журнала, которая помогает с
отладкой конкретного вызова.
Протоколирование записей связанных с
вызовом в настоящее время включает
идентификатор вызова (call ID) в записи
журнала. Этот call ID может использоваться
с grep, чтобы найти все записи, связанные
с этим вызов. В следующем примере журнал
с идентификатором вызова С-00000004.

[Dec 4 08:22:32]
WARNING[14199][C-00000004]: app_voicemail.c:6286

leave_voicemail: No entry in voicemail
config file for ‘234123452’

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

$ tail —1000
verbose

[Mar 11 …] VERBOSE[31362] logger.c: —
IAX2/shifteight-4 answered Zap/1-1

[Mar 11 …] VERBOSE[2973] logger.c: —
Starting simple switch on ‘Zap/1-1’

[Mar 11 …] VERBOSE[31362] logger.c: ==
Spawn extension (shifteight, s, 1)

exited non-zero on ‘Zap/1-1’

[Mar 11 …] VERBOSE[2973] logger.c: —
Hungup ‘Zap/1-1’

[Mar 11 …] VERBOSE[3680] logger.c: —
Starting simple switch on ‘Zap/1-1’

[Mar 11 …] VERBOSE[31362] logger.c: —
Hungup ‘Zap/1-1’

Для фильтрации одного вызова,
мы можем произвести grep в потоке ID.
Например:

$ grep 31362
verbose

который дал бы нам следующее:

[Mar 11 …] VERBOSE[31362] logger.c: —
IAX2/shifteight-4 answered Zap/1-1

[Mar 11 …] VERBOSE[31362] logger.c: ==
Spawn extension (shifteight, s, 1)

exited non-zero on ‘Zap/1-1’

[Mar 11 …] VERBOSE[31362] logger.c: —
Hungup ‘Zap/1-1’

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

Логирование демоном Linux
syslog

Linux содержит очень мощный
движок логирования, которым Asterisk способен
воспользоваться. Сейчас обсуждаются
различные варианты syslog и описание
всех возможных способов логирования
Asterisk выходит за рамки этой книги,
достаточно сказать, что если вы хотите
вести протокол Asterisk демоном syslog,
вам просто необходимо указать следующую
строку в файле /etc/asterisk/logger.conf:

syslog.local0 => notice,warning,error ;
или любые типы, которые хотите

; регистрировать

Вы должны иметь запись в вашем
конфигурационном файле¹
системного журнала (syslog) с именем
local0, которая должна
выглядеть примерно так:

local0.* /var/log/asterisk/syslog

Вы можете для
этого использовать local0
до local7, но проверьте
ваш syslog.conf чтобы убедиться что ничего
другого не использует один из этих
каналов syslog.

syslog²
это гораздо более мощный инструмент
регистрации, но он требует больше знаний,
чем логирование Asterisk напрямую в файлы.

Проверка логирования

Вы можете просмотреть статус
всех ваших настроек logger.conf через
консоль Asterisk CLI используя команду:

*CLI> logger show channels

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

Channel
Type Status Configuration

——- —- ——
————-

syslog.local0
Syslog Enabled — NOTICE WARNING ERROR VERBOSE

/var/log/asterisk/verbose
File Enabled — NOTICE WARNING ERROR VERBOSE

/var/log/asterisk/messages
File Enabled — NOTICE WARNING ERROR

Console Enabled — NOTICE
WARNING ERROR DTMF=

Ротация логов

Существует некоторая поддержка
ротации, встроенная в Asterisk, когда Asterisk
протоколирует в файлы. Ротация журналов
будет выполнена в следующих случаях:

• Если
  вы запустили ротацию журналов в Asterisk
  CLI командой.
• Во
  время перезагрузки конфигурации, если
  существующие файлы журнала больше 1
  Гб.
• Если
  Asterisk получает сигнал SIGXFSZ,
  указывающий что файл для записи слишком
  велик.

Call Detail Records (CDR) — детальная
запись вызовов

Система CDR в Asterisk используется
для логирования истории вызовов в
системе. В некоторых решениях эти записи
используются для биллинга. В других —
запись вызовов используется для анализа
количества вызовов во времени.
Её можно
также использовать как инструмент
отладки администратора Asterisk.

Содержание CDR

CDR имеет несколько полей,
которые включены по умолчанию. Таблица
24-2 приводит их список.

Таблица
24-2. Поля CDR по умолчанию

^a
userfield не так
актуально в настоящее время, как это
было раньше. Пользовательские переменные
CDR являются более гибким способом
получить пользовательские данные в
CDR.

Все поля записи CDR можно
получить в диалплане Asterisk с помощью
функции CDR(). Функция
CDR() также используется
для установки полей CDR, которые определяются
для пользователя.

exten => 115,1,Verbose(Call start time:
${CDR(start)})

same => n,Set(CDR(userfield)=zombie
pancakes)

В дополнение к полям, которые
всегда включены в CDR, можно добавлять
пользовательские поля. Это делается в
диалплане с помощью приложения Set()
функцией CDR():

exten => 115,1,NoOp()

same =>
n,Set(CDR(mycustomfield)=coffee)

same => n,Verbose(I need some more
${CDR(mycustomfield)})

Если вы решите
использовать пользовательские переменные
CDR убедитесь что реализация CDR способна
их регистрировать.

Для просмотра встроенной
документации по функции CDR(),
выполните следующую команду в консоли
Asterisk:

*CLI> core show function CDR

В дополнение к функции CDR(),
есть приложения в диалплане, которые
могут использоватся для обработки CDR
записей. Мы рассмотрим эти приложения
далее.

Приложения диалплана

Есть несколько приложений
диалплана, которые могут обрабатывать
CDR для текущего вызова. Для получения
списка приложений CDR, которые загружаются
в текущую версию Asterisk, мы можем использовать
следующую команду CLI:

*CLI> core show applications like CDR

-= Matching Asterisk Applications =-

ForkCDR: Forks the Call Data Record.

NoCDR: Tell Asterisk to not
maintain a CDR for the current call

ResetCDR: Resets the Call Data Record.

-= 3 Applications Matching =-

Каждое приложение имеет
встроенную в Asterisk документацию, которую
можно просмотреть с помощью следующей
команды:

*CLI> core show application
<application name>

cdr.conf

Файл cdr.conf имеет раздел
[general], который
содержит параметры, применяемые ко всей
системе CDR. Дополнительные необязательные
разделы могут существовать в этом файле,
они применяются к конкретному логированию
CDR модулей. Таблица 24-3 приводит список
доступных опций раздела [general].

Таблица
24-3. Раздел cdr.conf [general]

^a
Недостатком включения этой опции есть
то, что если Asterisk слетит или умреть по
какой-либо причине, записи CDR будут
потеряны, так как они хранятся только
в памяти, а процесса Asterisk уже не существует.
См. safeshutdown для получения дополнительной
информации.

Конечные решения (Backends)

Модули конечных решений
Asterisk CDR реализуют различные пути
логирования CDR. Большинство конечных
решений CDR требуют определенной
конфигурации для своего запуска.

cdr_adaptive_odbc

Как следует из названия модуль
cdr_adaptive_odbc позволяет
сохранять CDR в
базе данных через ODBC. Часть имени
«adaptive» указывает на то, что он
приспосабливается к структуре таблицы:
нет статической структуры таблицы,
которая должна быть использована с этим
модулем. При загрузке модуля (или
перезагрузке) он читает структуру
таблицы. При логировании CDR, он ищет
переменную CDR, которая соответствует
каждому имени столбца. Это относится
как к встроенным CDR переменным, так и
пользовательским. Если вы хотите
логировать CDR переменные канала, просто
создайте столбец с названием channel.

Добавление содержания
пользовательских CDR это так просто, как
установить их в диалплане. Например,
если мы хотим логировать User-Agent
предоставляемый устройством SIP, мы можем
добавит пользовательскую переменную
CDR:

exten =>
105,n,Set(CDR(useragent)=${CHANNEL(useragent)})

Для того, чтобы эта переменная
CDR записывалась в базу данных
cdr_adaptive_odbc, все,
что нужно сделать — это создать столбец
с именем useragent.

Несколько таблиц могут быть
настроены в файле конфигурации
cdr_adaptive_ odbc. Каждая
имеет в свой собственный раздел
конфигурации. Название раздела может
быть каким угодно, модуль не использует
его. Вот пример простой таблицы
конфигурации:

[mytable]

connection = asterisk

table = asterisk_cdr

Более подробный
пример установок базы данных для
логирования CDR может быть найден в
«Хранение
записей деталей вызовов (CDR)».

Таблица 24-4, содержит список
опций, которые можно определить для
таблицы в разделе конфигурационного
файла cdr_adaptive_odbc.conf.

Таблица
24-4. Таблица конфигурационных опций
cdr_adaptive_odbc.conf

В дополнение к паре полей
ключ/значение (key/value), которые показаны
в предыдущей таблице, cdr_adaptive_odbc.conf
позволяет использовать несколько других
элементов конфигурации. Во-первых, это
псевдоним столбца. Обычно, переменные
CDR записываются в столбцах с одноименным
названием. Псевдоним позволяет изменять
имя, которое будет отображаться в колонке
с другим именем. Синтаксис такой:

alias <CDR variable> =>
<column name>

Вот пример отображение
колонки, используя параметр alias:

alias src => source

Кроме того, можно задать
фильтр контента. Это позволяет определить
критерии, которым должны соответствовать
записи, вставленные в таблицу. Синтаксис:

filter <CDR variable> =>
<content>

Вот пример фильтра содержания:

filter accountcode => 123

Наконец, cdr_adaptive_odbc.conf
позволяет определять статическое
содержание для столбцов. Это может быть
полезно когда используется вместе с
набором filters.
Статический контент может помочь
дифференцировать записи, которые были
вставлены в одну таблицу по различным
разделам конфигурации. Синтаксис для
статического содержимого:

static <«Static Content Goes
Here»> => <column name>

Это пример определения
статического содержания для вставки с
CDR:

static «My Content» =>
my_identifier

cdr_csv

cdr_csv —
это очень простой модуль CDR, который
протоколирует CDR в CSV файл (значения
разделены запятыми). Файл
/var/log/asterisk/cdr-csv/Master.csv. Пока логирование
CDR включено в cdr.conf и этот модуль
загружен, CDR будет логироваться в файл
Master.csv.

Таблица
24-5. Параметры раздела cdr.conf [csv]

Порядок переменных CDR в
CSV-файлах создаваемых модулем cdr_csv:

<accountcode>,<src>,<dst>,<dcontext>,<clid>,<channel>,<dstchannel>,<lastapp>,

<lastadata>,<start>,<answer>,<end>,<duration>,<billsec>,<disposition>,

<amaflags>[,<uniqueid>][,<userfield>]

cdr_custom

Этот модуль CDR позволяет
задавать пользовательский формат CDR
записей в файле протоколирования. Этот
модуль наиболее часто используется для
индивидуальных выводов CSV. Файл
конфигурации для этого модуля
/etc/asterisk/cdr_custom.conf. В этом файле должен
быть один раздел под названием [mappings].
Этот раздел содержит соответствия между
именем файла и шаблоном для CDR. Шаблон
задается с помощью функций диалплана
Asterisk.

В следующем примере показана
конфигурация для cdr_custom,
она включает логирование в файл CDR —
Master.csv. Этот файл будет создан в
/var/log/asterisk/cdr-custom/Master.csv. Шаблон, который
был определен, использует две функции
диалплана CDR() и
CSV_QUOTE(). CDR()
извлекает значения из сохраненого CDR.
Функция CSV_QUOTE()
гарантирует, что значения экранируются
для формата файла CSV:

[mappings]

Master.csv =>
${CSV_QUOTE(${CDR(clid)})},${CSV_QUOTE(${CDR(src)})},

${CSV_QUOTE(${CDR(dst)})},${CSV_QUOTE(${CDR(dcontext)})},

${CSV_QUOTE(${CDR(channel)})},${CSV_QUOTE(${CDR(dstchannel)})},

${CSV_QUOTE(${CDR(lastapp)})},${CSV_QUOTE(${CDR(lastdata)})},

${CSV_QUOTE(${CDR(start)})},${CSV_QUOTE(${CDR(answer)})},

${CSV_QUOTE(${CDR(end)})},${CSV_QUOTE(${CDR(duration)})},

${CSV_QUOTE(${CDR(billsec)})},${CSV_QUOTE(${CDR(disposition)})},

${CSV_QUOTE(${CDR(amaflags)})},${CSV_QUOTE(${CDR(accountcode)})},

${CSV_QUOTE(${CDR(uniqueid)})},${CSV_QUOTE(${CDR(userfield)})}

В реальном файле
конфигурации значение в Master.csv должно
быть в одной строке.

cdr_manager

Модуль cdr_manager записывает в
CDR события Asterisk Manager Interface (AMI), которые
мы детально обсуждали в Главе 20. Этот
модуль настраивается в файле
/etc/asterisk/cdr_manager.conf. Первый раздел в
этом файле [general],
который содержит простой параметр для
включения этого модуля (по умолчанию
значение — no):

[general]

enabled = yes

Другой раздел в cdr_manager.conf
— это раздел [mappings].
Он позволяет добавлять пользовательские
переменные CDR для событий менеджера.
Синтаксис такой:

<CDR variable> => <Header
name>

Это пример добавления двух
пользовательских переменных CDR:

[mappings]

rate => Rate

carrier => Carrier

При такой конфигурации, записи
CDR будут отображаться как события в
интерфейсе менеджера. Чтобы создать
пример события менеджера, мы используем
следующий пример диалплана:

exten => 110,1,Answer()

same => n,Set(CDR(rate)=0.02)

same => n,Set(CDR(carrier)=BS&S)

same => n,Hangup()

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

*CLI> console dial [email protected]

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

Event: Cdr

Privilege: cdr,all

AccountCode:

Source:

Destination: 110

DestinationContext: testing

CallerID:

Channel: Console/dsp

DestinationChannel:

LastApplication: Hangup

LastData:

StartTime: 2010-08-23 08:27:21

AnswerTime: 2010-08-23 08:27:21

EndTime: 2010-08-23 08:27:21

Duration: 0

BillableSeconds: 0

Disposition: ANSWERED

AMAFlags: DOCUMENTATION

UniqueID: 1282570041.3

UserField:

Rate: 0.02

Carrier: BS&S

cdr_mysql

Этот модуль позволяет размещать
CDR в базе данных MySQL. Мы рекомендуем
использовать в новой инсталляции
cdr_adaptive_odbc вместо
него.

cdr_odbc

Этот модуль обеспечивает
старый интерфейс ODBC для логирования
CDR. Новые установки должны использовать
вместо него cdr_adaptive_odbc.

cdr_pgsql

Этот модуль позволяет размещать
CDR в базе данных PostgreSQL. Мы рекомендуем
использовать в новой инсталляции
cdr_adaptive_odbc вместо
него.

cdr_radius

Модуль cdr_radius
позволяет размещать CDR на сервере RADIUS.
Когда используется это модуль, каждая
CDR сообщается RADIUS серверу как одно
событие останова. Этот модуль настраивается
в файле /etc/asterisk/cdr.conf. Опции для этого
модуля размещены в разделе с именем
[radius]. Доступные
параметры перечислены в Таблице 24-6.

Таблица
24-6. Параметры раздела cdr.conf [radius]

cdr_sqlite

Этот модуль позволяет размещать
CDR в базе данных SQLite используя SQLite версии
2. Если у вас нет особой необходимости
в SQLite версии 2 вместо 3, мы рекомендуем,
чтобы все новые установки использовали
cdr_sqlite3_custom.

Этот модуль не требует
настройки работы. Если модуль был
скомпилирован и загружен в Asterisk, он
будет вставлять CDR в таблицу называемую
cdr в базе данных размещенной в
/var/log/asterisk/cdr.db.

cdr_sqlite3_custom

Этот модуль CDR вставляет CDR в
базу данных SQLite используя SQLite версии
3. База данных, созданная этим модулем
находится в /var/log/asterisk/master.db. Этот
модуль требует наличия конфигурационного
файла /etc/asterisk/cdr_sqlite3_custom.conf.
Конфигурационный файл определяет имя
таблицы, а также настраивает какие
переменные CDR будут вставлены в базу
данных:

[master]

table = cdr

;

; Список имен столбцов,
используемых при вставке CDRs.

;

columns => calldate, clid, dcontext,
channel, dstchannel, lastapp, lastdata,

duration, billsec, disposition, amaflags, accountcode, uniqueid,
userfield,

test

;

; Сопоставьте содержимое
CDR с ранее указанными столбцами.

;

values =>
‘${CDR(start)}’,’${CDR(clid)}’,’${CDR(dcontext)}’,’${CDR(channel)}’,

‘${CDR(dstchannel)}’,
‘${CDR(lastapp)}’,’${CDR(lastdata)}’,’${CDR(duration)}’,

‘${CDR(billsec)}’,’${CDR(disposition)}’, ‘${CDR(amaflags)}’,

‘${CDR(accountcode)}’,’${CDR(uniqueid)}’,’${CDR(userfield)}’,’${CDR(test)}’

В файле cdr_
sqlite3_custom.conf содержимое столбцов
(columns)
и значения каждой опции (values)
должны быть в одной строке.

cdr_syslog

Этот модуль позволяет
логировать CDR используя syslog. Для его
включения сперва добавьте конфигурационный
файл системы syslog — /etc/syslog.conf.
Например:

local4.* /var/log/asterisk/asterisk-cdr.log

Asterisk модуль также имеет
конфигурационный файл. Добавьте следующий
раздел в /etc/asterisk/cdr_syslog.conf:

[cdr]

facility = local4

priority = info

template = «We received a call from
${CDR(src)}»

Вот пример вывода syslog с
помощью этой конфигурации:

$ cat
/var/log/asterisk/asterisk-cdr.log

Aug 12 19:17:36 pbx cdr: «We received
a call from 2565551212»

cdr_tds

Модуль cdr_tds
использует библиотеку FreeTDS чтобы получить
возможность отправлять CDR в Microsoft SQL
Server и Sybase базу данных. Можно использовать
FreeTDS с unixODBC поэтому
мы рекомендуем использовать
cdr_adaptive_odbc вместо
этого модуля.

Пример Call Detail Records

Мы будем использовать модуль
cdr_custom для иллюстрации
нескольких примеров CDR записей для
различных сценариев вызова. Конфигурация
для /etc/asterisk/cdr_custom.conf показана в
разделе «cdr_custom».

Односторонний вызов

В этом примере мы покажем как
CDR выглядит для простого одностороннего
вызова. В частности, мы будем использовать
пример пользовательского вызова и
проверим свою голосовую почту. Вот
расширение из /etc/asterisk/extensions.conf:

exten =>
*98,1,VoiceMailMain(@${GLOBAL(VOICEMAIL_CONTEXT)})

Эта запись CDR из
/var/log/asterisk/cdr-custom/Master.csv была создана
как результат вызова этого номера:

«»»Console»»
<2565551212>»,»2565551212″,»*98″,»UserServices»,

«Console/dsp»,»»,
«VoiceMailMain»,»@shifteight.org»,»2010-08-16
01:08:44″,

«2010-08-16 01:08:44″,»2010-08-16
01:08:53″,»9″,»9″,»ANSWERED»,

«DOCUMENTATION»,»»,»1281935324.0″,»»,0

Двухсторонний вызов

В следующем примере мы покажем
как выглядит CDR для простого двухстороннего
вызова. Мы имеем один SIP телефон, вызывающий
другой SIP телефон. Ответ на вызов, а затем
повешенную трубку после короткого
периода времени. Вот расширение, которое
было вызвано:

exten => 101,1,Dial(SIP/0000FFFF0002)

Вот CDR, который был запротоколирован
в Master.csv в результате этого вызова:

«»»Console»»
<2565551212>»,»2565551212″,»101″,»LocalSets»,»Console/dsp»,

«SIP/0000FFFF0002-00000000″,»Dial»,»SIP/0000FFFF0002″,»2010-08-16
01:16:10″,

«2010-08-16 01:16:16″,»2010-08-16
01:16:29″,»19″,»13″,»ANSWERED»,

«DOCUMENTATION»,»»,»1281935770.2″,»»,2

Предостережения

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

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

CEL (Channel Event Logging)

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

Типы событий канала

Каждая запись CEL представляет
событие, которое произошло для канала
в системе Asterisk. Таблица 24-7 содержит
список событий, которые генерирует
Asterisk когда происходит вызов.

Таблица
24-7. Типы событий CEL

Есть еще несколько событий,
которые были определены, но еще не
используются в любом месте кода Asterisk.
Предположительно, некоторые будущие
версии будут генерировать эти события
в нужном месте. Они перечислены в Таблице
24-8.³

Таблица
24-8. Определённые, но не используемые
типы событий CEL

Содержание событий канала

Каждое событие CEL содержит
поля перечисленные в таблице Таблица
24-9:

Таблица
24-9. Поля событий CEL:

Некоторые содержания событий
CEL определяются пользователем. Например,
userfield определяется
пользователем и будет пустым по умолчанию.
Чтобы установить в него какое-то значение,
используйте функцию диалплана CHANNEL().
Вот пример определения userfield
для канала:

exten => 101,1,Set(CHANNEL(userfield)=I
like waffles!)

Приложения диалплана

Система CEL включает простые
приложения диалплана, которые находятся
в модуле app_celgenuserevent.so. Эти приложения
используют созданные пользовательские
события типа EV_USER_EVENT.
Практический пример использования
этого может быть логирование выбора
звонящих в меню:

exten =>
7,1,CELGenUserEvent(MENU_CHOICE,Caller chose option 7)

Для полной текущей информации
о синтаксисе приложения CELGenUserEvent()
используйте встроенную документацию
в Asterisk CLI:

*CLI> core show application
CELGenUserEvent

cel.conf

Система CEL имеет простой
конфигурационный файл /etc/asterisk/cel.conf.
Все параметры, заданные здесь влияют
на обработку CEL независимо от модуля
логирования, находящегося в работе.
Таблица 24-10 показывает параметры, которые
существуют в этом файле. Все они должны
быть установлены в разделе [general]
конфигурационного файла.

Таблица
24-10. cel.conf раздел параметров [general]

Как минимум для
начала использования CEL, вы должны
установить параметры enable
и events в
/etc/asterisk/cel.conf.

Конечные решения (Backends)

Как и в системе CDR есть ряд
модулей, доступных для регистрации CEL
событий. На самом деле, все CEL модули
были получены из модулей CDR, поэтому их
конфигурация очень похожа. В дополнение
к параметрам конфигурации для cel.conf,
которые были описаны в предыдущем
разделе, эти модули требуют настройки,
чтобы заставить их работать.

cel_odbc

Модуль cel_odbc.so предоставляет
возможность протоколировать события
CEL в базу данных с помощью ODBC. Этот модуль
является не совсем таким как CDR для ODBC.
Для событий CEL нет пользовательских
переменных. Тем не менее, этот модуль
будет по-прежнему приспосабливаться к
структуре базы данных в том, что он будет
логировать поля событий CEL, для которых
имеются соответствующие столбцы и не
будет выдавать ошибки если нет столбца
для каждого поля. Конфигурация для этого
модуля находится в /etc/asterisk/cel_odbc.conf.

Несколько таблиц могут быть
настроены в файле конфигурации cel_odbc.
Каждая имеет свой раздел конфигурации.
Название раздела может быть каким
угодно, модуль не использует его. Вот
пример простой таблицы конфигурации:

[mytable]

connection = asterisk

table = asterisk_cel

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

• eventtype
• eventtime
• userdeftype
• cid_name
• cid_num
• cid_ani
• cid_rdnis
• cid_dnid
• exten
• context
• channame
• appname
• appdata
• accountcode
• peeraccount
• uniqueid
• linkedid
• amaflags
• userfield
• peer

Таблица 24-11 показывает
сопоставление типов событий и их целых
значения, которые будут вставлены в
столбец eventtype базы
данных.

Таблица
24-11. Тип события отображаемое в целом
значении для столбца eventtype

Таблица 24-12 показывает
параметры, которые могут быть определены
в разделе конфигурации таблицы в файле
cel_odbc.conf.

Таблица
24-12. Таблица конфигурации cel_odbc.conf

В дополнение к паре полей
ключ/значение, которые показаны в
предыдущей таблице, cel_odbc.conf позволяет
несколько других элементов конфигурации.
Во-первых, это псевдоним столбца. Как
правило, поля CEL записываются в столбцах
с одноименным названием. alias
позволяет отображать переменную с
другим именем. Синтаксис:

alias <CEL field> =>
<column name>

Вот пример отображение
колонки, используя параметр alias:

alias exten => extension

Кроме того, можно задать
фильтр контента. Это позволяет определить
критерии, которым должны соответствовать
записи, вставляемые в таблицу. Синтаксис
такой:

filter <CEL field> =>
<content>

Вот
пример фильтра содержания:

filter appname => Dial

Наконец, cel_odbc.conf позволяет
указать статический контент для столбца.
Это может быть полезно когда используется
совместно с фильтром. Статический
контент может помочь различить записи,
которые были вставлены в одну таблицу
по различным разделам конфигурации.
Синтаксис для статического контента
такой:

static <«Static Content Goes Here»>
=> <column name>

Вот пример определяющий
статический контент для записи с CEL
событием:

static «My Content» =>
my_identifier

cel_custom

Этот модуль CEL позволяет
логировать события CEL в
пользовательском формате. Чаще всего
он используется для настройки данных
CSV. Файл конфигурации для этого модуля
/etc/asterisk/cel_custom.conf. В файле должен быть
один раздел с названием [mappings].
Этот раздел содержит сопоставления
между именами файлов и пользовательскими
шаблонами для событий CEL. Шаблоны задаются
с помощью функций диалплана Asterisk и
нескольких специальных переменных CEL.

Следующий пример — это простая
конфигурация для cel_custom,
которая включает один файл протокола
CEL — Master.csv. Этот файл будет создан в
/var/log/asterisk/cel-custom/Master.csv. Шаблон, который
будет определен, использует функции
диалплана CHANNEL(),
CALLERID() и CSV_QUOTE().
Функция CSV_QUOTE()
проверяет что значения правильно
подготовлены для формата CSV-файла. Этот
пример также рассматривает некоторые
специальные переменные CEL, которые
перечислены в Таблице 24-13.

Таблица
24-13. Переменные CEL, доступные для
использования в [mappings]

Это пример файла
/etc/asterisk/cel_custom.conf:

[mappings]

Master.csv =>
${CSV_QUOTE(${eventtype})},${CSV_QUOTE(${eventtime})},

${CSV_QUOTE(${CALLERID(name)})},${CSV_QUOTE(${CALLERID(num)})},

${CSV_QUOTE(${CALLERID(ANI)})},${CSV_QUOTE(${CALLERID(RDNIS)})},

${CSV_QUOTE(${CALLERID(DNID)})},${CSV_QUOTE(${CHANNEL(exten)})},

${CSV_QUOTE(${CHANNEL(context)})},${CSV_QUOTE(${CHANNEL(channame)})},

${CSV_QUOTE(${CHANNEL(appname)})},${CSV_QUOTE(${CHANNEL(appdata)})},

${CSV_QUOTE(${CHANNEL(amaflags)})},${CSV_QUOTE(${CHANNEL(accountcode)})},

${CSV_QUOTE(${CHANNEL(uniqueid)})},${CSV_QUOTE(${CHANNEL(linkedid)})},

${CSV_QUOTE(${CHANNEL(peer)})},${CSV_QUOTE(${CHANNEL(userfield)})},

${CSV_QUOTE(${eventextra})}

В реальном файле
конфигурации значения в Master.csv должны
быть в одной строке.

cel_manager

Модуль cel_manager
создает события CEL на Asterisk Manager Interface (мы
подробно обсуждали AMI в Главе 20). Этот
модуль настраивается в файле
/etc/asterisk/cel.conf. Он должен содержать
одну секцию, называемую [manager],
которая содержит один параметр включения
этого модуля. Значение по умолчанию —
no, но вы вожете
включить его вот так:

[manager]

enabled = yes

При такой конфигурации события
CEL будут выглядеть как события AMI.
Для примера генерации событий менеджера,
мы будем использовать следующий диалплан:

exten => 111,1,Answer()

same => n,CELGenUserEvent(Custom
Event,Whiskey Tango Foxtrot)

same => n,Hangup()

Эта команда используется для
выполнения этого расширения и генерации
некоторых событий CEL:

*CLI> console dial [email protected]

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

Event: CEL

Privilege: call,all

EventName: CHAN_START

AccountCode:

CallerIDnum:

CallerIDname:

CallerIDani:

CallerIDrdnis:

CallerIDdnid:

Exten: 111

Context: testing

Channel: Console/dsp

Application:

AppData:

EventTime: 2010-08-23 08:14:51

AMAFlags: NONE

UniqueID: 1282569291.1

LinkedID: 1282569291.1

Userfield:

Peer:

cel_pgsql

Этот модуль позволяет сохранять
события CEL в базе данных PostgreSQL. Мы
рекомендуем использовать в новых
установках cel_odbc.

cel_radius

Модуль cel_radius
позволяет сохранять события CEL на сервере
RADIUS. Когда используется этот модуль,
каждое событие CEL заносится на
сервер RADIUS как отдельное событие. Этот
модуль настраивается в файле
/etc/asterisk/cel.conf. Параметры для этого
модуля перечислены в Таблице 24-14 и
размещаются в разделе [radius].

Таблица
24-14. Разрешенные параметры в разделе

[radius]

файла cel.conf

cel_sqlite3_custom

Этот модуль CEL записывает
события CEL в базу данных SQLite используя
SQLite вирсии 3. База данных, созданная этим
модулем, находится в /var/log/asterisk/master.db.
Файл конфигурации для этого модуля
/etc/asterisk/cel_sqlite3_custom.conf определяет имя
таблицы, а также настраивает какие
переменные CEL будут вставлены в базу
данных. Выглядит это примерно так:

[master]

table = cel

;

; Список имен столбцов,
используемых при вставке событий CEL.

;

columns => eventtype, eventtime,
cidname, cidnum, cidani, cidrdnis, ciddnid, context, exten, channame,
appname, appdata, amaflags, accountcode, uniqueid, userfield, peer

;

; Сопоставьте содержимое
события CEL с ранее указанными столбцами.

;

values =>
‘${eventtype}’,’${eventtime}’,’${CALLERID(name)}’,’${CALLERID(num)}’,

‘${CALLERID(ANI)}’,’${CALLERID(RDNIS)}’,’${CALLERID(DNID)}’,

‘${CHANNEL(context)}’,’${CHANNEL(exten)}’,’${CHANNEL(channame)}’,

‘${CHANNEL(appname)}’,’${CHANNEL(appdata)}’,
‘$CHANNEL(amaflags)}’,

‘${CHANNEL(accountcode)}’,’${CHANNEL(uniqueid)}’,
‘${CHANNEL(userfield)}’,

‘${CHANNEL(peer)}’

В файле cel_
sqlite3_custom.conf содержимое столбцов и
значения параметров должны находиться
в одной строке.

cel_tds

Модуль cel_tds
использует библиотеку FreeTDS для записи
событий CEL в базу данных Microsoft SQL Server или
Sybase. Это можно сделать используя FreeTDS с
unixODBC, поэтому мы рекомендуем
использовать cel_odbc
вместо этого модуля.

Примеры событий канала

Сейчас мы покажем вам несколько
примеров создания событий вызова из
системы CEL. Модуль cel_custom
будет использован из-за своей простоты.
Используемая конфигурация
/etc/asterisk/cel_custom.conf приведена в разделе
«cel_custom». Кроме
того, следующая конфигурация была
использована для /etc/asterisk/cel.conf:

[general]

enable = yes

apps = Dial,Playback

events = ALL

Односторонний вызов

В этом примере показан
одиночный телефонный вызов в расширение,
которое проигрывает сообщение “Hello
World.” Вот этот диалплан:

exten => 200,1,Answer()

same => n,Playback(hello-world)

same => n,Hangup()

Вот события CEL, которые
регистрируются в результате принятия
этого вызова:

«CHAN_START»,»1282062437.436130″,»Julie
Bryant»,»12565553333″,»»,»»,»»,»200″,

«LocalSets»,
«SIP/0000FFFF0003-00000010″,»»,»»,»3″,»»,»1282062437.17″,

«1282062437.17»,»»,»»

«ANSWER»,»1282062437.436513″,»Julie
Bryant»,»12565553333″,»12565553333″,»»,

«200»,»200″,
«LocalSets»,»SIP/0000FFFF0003-00000010″,»Answer»,»»,»3″,»»,

«1282062437.17»,»1282062437.17″,»»,»»

«APP_START»,»1282062437.501868″,»Julie
Bryant»,»12565553333″,»12565553333″,

«»,»200″,»200″,
«LocalSets»,»SIP/0000FFFF0003-00000010″,»Playback»,

«hello-world»,»3″,»»,»1282062437.17″,
«1282062437.17»,»»,»»

«APP_END»,»1282062439.008997″,»Julie
Bryant»,»12565553333″,»12565553333″,»»,

«200»,»200″,
«LocalSets»,»SIP/0000FFFF0003-00000010″,»Playback»,

«hello-world»,»3″,»»,»1282062437.17″,
«1282062437.17»,»»,»»

«HANGUP»,»1282062439.009127″,»Julie
Bryant»,»12565553333″,»12565553333″,»»,

«200»,»200″,
«LocalSets»,»SIP/0000FFFF0003-00000010″,»»,»»,»3″,»»,

«1282062437.17»,»1282062437.17″,»»,»»

«CHAN_END»,»1282062439.009666″,»Julie
Bryant»,»12565553333″,»12565553333″,

«»,»200″,»200″,
«LocalSets»,»SIP/0000FFFF0003-00000010″,»»,»»,»3″,»»,

«1282062437.17»,»1282062437.17″,»»,»»

«LINKEDID_END»,»1282062439.009707″,»Julie
Bryant»,»12565553333″,

«12565553333»,»»,»200″,»200″,
«LocalSets»,»SIP/0000FFFF0003-00000010″,»»,

«»,»3″,»»,»1282062437.17″,»1282062437.17″,»»,»»

Двухсторонний вызов

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

exten => 101,1,Dial(SIP/0000FFFF0001)

А это события CEL, которые
генерируются в результате создания
этого вызова:

«CHAN_START»,»1282062455.574611″,»Julie
Bryant»,»12565553333″,»»,»»,»»,»101″,

«LocalSets»,
«SIP/0000FFFF0003-00000011″,»»,»»,»3″,»»,»1282062455.18″,

«1282062455.18»,»»,»»

«APP_START»,»1282062455.574872″,»Julie
Bryant»,»12565553333″,»12565553333″,»»,

«101»,»101″,
«LocalSets»,»SIP/0000FFFF0003-00000011″,»Dial»,

«SIP/0000FFFF0001″,»3″,»»,»1282062455.18″,»1282062455.18″,»»,»»

«CHAN_START»,»1282062455.575044″,»Candice
Yant»,»12565551111″,»»,»»,»»,»s»,

«LocalSets»,
«SIP/0000FFFF0001-00000012″,»»,»»,»3″,»»,»1282062455.19″,

«1282062455.18»,»»,»»

«ANSWER»,»1282062458.068134″,»»,»101″,»12565551111″,»»,»»,»101″,»LocalSets»,

«SIP/0000FFFF0001-00000012″,»AppDial»,»(Outgoing
Line)»,»3″,»»,

«1282062455.19»,»1282062455.18″,»»,»»

«ANSWER»,»1282062458.068361″,»Julie
Bryant»,»12565553333″,»12565553333″,»»,

«101»,»101″,
«LocalSets»,»SIP/0000FFFF0003-00000011″,»Dial»,

«SIP/0000FFFF0001″,»3″,»»,»1282062455.18″,
«1282062455.18»,»»,»»

«BRIDGE_START»,»1282062458.068388″,»Julie
Bryant»,»12565553333″,

«12565553333»,»»,»101″,»101″,
«LocalSets»,»SIP/0000FFFF0003-00000011″,

«Dial»,»SIP/0000FFFF0001″,»3″,»»,»1282062455.18″,
«1282062455.18»,»»,»»

«BRIDGE_END»,»1282062462.965704″,»Julie
Bryant»,»12565553333″,»12565553333″,

«»,»101″,»101″,
«LocalSets»,»SIP/0000FFFF0003-00000011″,»Dial»,

«SIP/0000FFFF0001″,»3″,»»,»1282062455.18″,
«1282062455.18»,»»,»»

«HANGUP»,»1282062462.966097″,»»,»101″,»12565551111″,»»,»»,»»,»LocalSets»,

«SIP/0000FFFF0001-00000012″,»AppDial»,»(Outgoing
Line)»,»3″,»»,

«1282062455.19»,»1282062455.18″,»»,»»

«CHAN_END»,»1282062462.966119″,»»,»101″,»12565551111″,»»,»»,»»,»LocalSets»,

«SIP/0000FFFF0001-00000012″,»AppDial»,»(Outgoing
Line)»,»3″,»»,

«1282062455.19»,»1282062455.18″,»»,»»

«APP_END»,»1282062462.966156″,»Julie
Bryant»,»12565553333″,»12565553333″,»»,

«101»,»101″,»LocalSets»,»SIP/0000FFFF0003-00000011″,»Dial»,

«SIP/0000FFFF0001″,»3″,»»,»1282062455.18″,»1282062455.18″,»»,»»

«HANGUP»,»1282062462.966215″,»Julie
Bryant»,»12565553333″,»12565553333″,

«»,»101″,»101″,»LocalSets»,»SIP/0000FFFF0003-00000011″,»»,»»,»3″,»»,

«1282062455.18»,»1282062455.18″,»»,»»

«CHAN_END»,»1282062462.966418″,»Julie
Bryant»,»12565553333″,»12565553333″,

«»,»101″,»101″,»LocalSets»,»SIP/0000FFFF0003-00000011″,»»,»»,»3″,»»,

«1282062455.18»,»1282062455.18″,»»,»»

«LINKEDID_END»,»1282062462.966441″,»Julie
Bryant»,»12565553333″,

«12565553333»,»»,»101″,»101″,»LocalSets»,»SIP/0000FFFF0003-00000011″,

«»,»»,»3″,»»,»1282062455.18″,»1282062455.18″,»»,»»

Слепой трансфер

В этом последнем примере
будет выполнен трансфер. Вызов начнется
вызовом телефона по добавочному номеру
102. Затем вызов
будет переведен на другой телефон с
номером 101. Вот
соответствующий диалплан:

exten => 101,1,Dial(SIP/0000FFFF0001)

exten => 102,1,Dial(SIP/0000FFFF0002)

Это запротоколированные
события CEL в результате этого сценария
вызова:

«CHAN_START»,»1282062488.028200″,»Julie
Bryant»,»12565553333″,»»,»»,»»,

«102»,»LocalSets»,
«SIP/0000FFFF0003-00000013″,»»,»»,»3″,»»,

«1282062488.20»,»1282062488.20″,»»,»»

«APP_START»,»1282062488.028464″,»Julie
Bryant»,»12565553333″,»12565553333″,

«»,»102″,»102″,
«LocalSets»,»SIP/0000FFFF0003-00000013″,»Dial»,

«SIP/0000FFFF0002″,»3″,»»,»1282062488.20″,
«1282062488.20»,»»,»»

«CHAN_START»,»1282062488.028762″,»Brooke
Brown»,»12565552222″,»»,»»,»»,

«s»,»LocalSets»,
«SIP/0000FFFF0002-00000014″,»»,»»,»3″,»»,»1282062488.21″,

«1282062488.20»,»»,»»

«ANSWER»,»1282062492.565759″,»»,»102″,»12565552222″,»»,»»,»102″,»LocalSets»,

«SIP/0000FFFF0002-00000014″,»AppDial»,»(Outgoing
Line)»,»3″,»»,

«1282062488.21»,»1282062488.20″,»»,»»

«ANSWER»,»1282062492.565973″,»Julie
Bryant»,»12565553333″,»12565553333″,»»,

«102»,»102″,»LocalSets»,»SIP/0000FFFF0003-00000013″,»Dial»,

«SIP/0000FFFF0002″,»3″,»»,»1282062488.20″,»1282062488.20″,»»,»»

«BRIDGE_START»,»1282062492.566001″,»Julie
Bryant»,»12565553333″,

«12565553333»,»»,»102″,»102″,»LocalSets»,»SIP/0000FFFF0003-00000013″,

«Dial»,»SIP/0000FFFF0002″,»3″,»»,»1282062488.20″,»1282062488.20″,»»,»»

«CHAN_START»,»1282062497.940687″,»»,»»,»»,»»,»»,»s»,»LocalSets»,

«AsyncGoto/SIP/0000FFFF0002-00000014″,»»,»»,»3″,»»,»1282062497.22″,

«1282062488.20»,»»,»»

«BLINDTRANSFER»,»1282062497.940925″,»Julie
Bryant»,»12565553333″,»12565553333″,»»,

«102»,»102″,»LocalSets»,»SIP/0000FFFF0003-00000013″,»Dial»,»SIP/0000FFFF0002″,

«3»,»»,»1282062488.20″,»1282062488.20″,

«AsyncGoto/SIP/0000FFFF0002-00000014<ZOMBIE>»,»»

«BRIDGE_END»,»1282062497.940961″,»Julie
Bryant»,»12565553333″,»12565553333″,»»,

«102»,»102″,»LocalSets»,»SIP/0000FFFF0003-00000013″,»Dial»,

«SIP/0000FFFF0002″,»3″,»»,»1282062488.20″,»1282062488.20″,»»,»»

«APP_START»,»1282062497.941021″,»»,»102″,»12565552222″,»»,»»,»101″,»LocalSets»,

«SIP/0000FFFF0002-00000014″,»Dial»,»SIP/0000FFFF0001″,»3″,»»,

«1282062497.22»,»1282062488.20″,»»,»»

«CHAN_START»,»1282062497.941207″,»Candice
Yant»,»12565551111″,»»,»»,»»,»s»,

«LocalSets»,»SIP/0000FFFF0001-00000015″,»»,»»,»3″,»»,»1282062497.23″,

«1282062488.20»,»»,»»

«HANGUP»,»1282062497.941361″,»»,»»,»»,»»,»»,»»,»LocalSets»,

«AsyncGoto/SIP/0000FFFF0002-00000014<ZOMBIE>»,»AppDial»,

«(Outgoing
Line)»,»3″,»»,»1282062488.21″,»1282062488.20″,»»,»»

«CHAN_END»,»1282062497.941380″,»»,»»,»»,»»,»»,»»,»LocalSets»,

«AsyncGoto/SIP/0000FFFF0002-00000014<ZOMBIE>»,»AppDial»,»(Outgoing
Line)»,

«3»,»»,»1282062488.21″,»1282062488.20″,»»,»»

«APP_END»,»1282062497.941415″,»Julie
Bryant»,»12565553333″,»12565553333″,»»,

«102»,»102″,»LocalSets»,»SIP/0000FFFF0003-00000013″,»Dial»,

«SIP/0000FFFF0002″,»3″,»»,»1282062488.20″,»1282062488.20″,»»,»»

«HANGUP»,»1282062497.941453″,»Julie
Bryant»,»12565553333″,»12565553333″,

«»,»102″,»102″,»LocalSets»,»SIP/0000FFFF0003-00000013″,»»,»»,»3″,»»,

«1282062488.20»,»1282062488.20″,»»,»»

«CHAN_END»,»1282062497.941474″,»Julie
Bryant»,»12565553333″,»12565553333″,

«»,»102″,»102″,»LocalSets»,»SIP/0000FFFF0003-00000013″,»»,»»,»3″,»»,

«1282062488.20»,»1282062488.20″,»»,»»

«ANSWER»,»1282062500.559578″,»»,»101″,»12565551111″,»»,»»,»101″,»LocalSets»,

«SIP/0000FFFF0001-00000015″,»AppDial»,»(Outgoing
Line)»,»3″,»»,

«1282062497.23»,»1282062488.20″,»»,»»

«BRIDGE_START»,»1282062500.559720″,»»,»102″,»12565552222″,»»,»»,»101″,»LocalSets»,

«SIP/0000FFFF0002-00000014″,»Dial»,»SIP/0000FFFF0001″,»3″,»»,»1282062497.22″,

«1282062488.20»,»»,»»

«BRIDGE_END»,»1282062512.742600″,»»,»102″,»12565552222″,»»,»»,»101″,»LocalSets»,

«SIP/0000FFFF0002-00000014″,»Dial»,»SIP/0000FFFF0001″,»3″,»»,»1282062497.22″,

«1282062488.20»,»»,»»

«HANGUP»,»1282062512.743006″,»»,»101″,»12565551111″,»»,»»,»»,»LocalSets»,

«SIP/0000FFFF0001-00000015″,»AppDial»,»(Outgoing
Line)»,»3″,»»,»1282062497.23″,

«1282062488.20»,»»,»»

«CHAN_END»,»1282062512.743211″,»»,»101″,»12565551111″,»»,»»,»»,»LocalSets»,

«SIP/0000FFFF0001-00000015″,»AppDial»,»(Outgoing
Line)»,»3″,»»,»1282062497.23″,

«1282062488.20»,»»,»»

«APP_END»,»1282062512.743286″,»»,»102″,»12565552222″,»»,»»,»101″,»LocalSets»,

«SIP/0000FFFF0002-00000014″,»Dial»,»SIP/0000FFFF0001″,»3″,»»,»1282062497.22″,

«1282062488.20»,»»,»»

«HANGUP»,»1282062512.743346″,»»,»102″,»12565552222″,»»,»»,»101″,»LocalSets»,

«SIP/0000FFFF0002-00000014″,»»,»»,»3″,»»,»1282062497.22″,»1282062488.20″,

«»,»»

«CHAN_END»,»1282062512.743371″,»»,»102″,»12565552222″,»»,»»,»101″,»LocalSets»,

«SIP/0000FFFF0002-00000014″,»»,»»,»3″,»»,»1282062497.22″,»1282062488.20″,

«»,»»

«LINKEDID_END»,»1282062512.743391″,»»,»102″,»12565552222″,»»,»»,»101″,

«LocalSets»,»SIP/0000FFFF0002-00000014″,»»,»»,»3″,»»,»1282062497.22″,

«1282062488.20»,»»,»»

SNMP

Simple Network Management Protocol (SNMP) — это
стандартизированный протокол для
управления сетью. Он очень широко
используется и реализован во многих
приложениях и сетевых устройствах.
Такая платформа как OpenNMS⁴
— это платформа управления сетью с
открытым исходным кодом, использующая
SNMP (а также другие вещи). Asterisk поддерживает
SNMP через модуль res_snmp.
Этот раздел описывает установку и
настройку res_snmp и
как мы можем использовать платформу
подобную OpenNMS.

Установка модуля SNMP для
Asterisk

По умолчанию Asterisk не компилирует
модуль разработки SNMP, поскольку сначала
нужно установить все необходимые
(зависимые) пакеты.

Зависимости в RHEL

В RHEL вам просто нужно установить
пакет net-snmp-devel:

$ sudo yum install net-snmp-devel

Смотри далее раздел под
названием “Перекомпиляция
Asterisk с модулем res_snmp” для обзора, как
перекомпилировать Asterisk с поддержкой
SNMP.

Зависимости в Ubuntu

Под Ubuntu, нужно установить
следующий пакет:

$ sudo apt-get install snmp libsnmp-dev
snmpd

На Ubuntu
необходимо устанавливать
оба пакета snmp и snmpd, поскольку
они не разрешают зависимостей библиотек
разработки SNMP наподобие RHEL. Пакет snmp
устанавливает инструменты SNMP подобно
snmpwalk, который нам нужен, а пакет
snmpd устанавливает демон SNMP.

Смотри следующий раздел для
описания, как пере компилировать Asterisk
с поддержкой SNMP.

Перекомпиляция Asterisk с модулем res_snmp

Как только вы установите все
нужные пакеты для SNMP, то можете
перекомпилировать Asterisk с поддержкой
SNMP:

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

$ ./configure

$ make
menuselect # verify that
res_snmp is selected under Resource Modules

$ make

$ sudo make
install

Затем вам нужно скопировать
пример конфигурационного файла в каталог
/etc/asterisk:

$ sudo cp
~/src/asterisk-complete/asterisk/11/configs/res_snmp.conf.sample

/etc/asterisk/res_snmp.conf

Мы раскажем о настройке этого
файла, для использования с OpenNMS, в
следующем разделе.

Настройка SNMP для использования
OpenNMS в Asterisk

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

Установка OpenNMS

Вики OpenNMS имеет детальную
иструкцию по установке OpenNMS.

OpenNMS можно не
устанавливать на ваш сервер Asterisk. Вы
можете выделить отдельную машину для
сервера OpenNMS.

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

Инструкции по установке
OpenNMS в вики используют SNMPv2c, который не
является безопасным методом абстрагирования
данных протокола SNMP. Так как мы хотим
построить безопасную систему, наши
инструкции покажут вам как включить
поддержку SNMPv3.⁵

Однако, поскольку SNMPv3 может
быть немного громоздким зверем или
потому что вы не желаете включить SNMPv3
по каким-то причинам (например, если
ваша версия SNMP не была собрана с поддержкой
OpenSSL), мы предоставим вам инструкции по
настройке демона SNMP для SNMPv2c и SNMPv3.

Как правило, проще настроить
систему для SNMPv2c, а затем обновить ее до
SNMPv3, правильная настройка SNMPv3 более
сложная.

Редактирование
/etc/asterisk/res_snmp.conf для работы с вашим
сервером OpenNMS

В файле /etc/asterisk/res_snmp.conf,
который вы скопировали из каталога с
исходными кодами, нужно раскоментировать
две строки:

[general]

;subagent=yes

;enabled=yes

Изменим файл res_snmp.conf для
обоих клиентов SNMP и включим subagent:

[general]

subagent=yes

enabled=yes

После изменения этого файла,
вам нужно перезагрузить модуль
res_snmp.so, чтобы изменения вступили в
силу:

*CLI> module unload res_snmp.so

Unloaded res_snmp.so

Unloading [Sub]Agent Module

== Terminating SubAgent

*CLI> module load res_snmp.so

Loaded res_snmp.so

== Parsing
‘/etc/asterisk/res_snmp.conf’: == Found

Loading [Sub]Agent Module

Loaded res_snmp.so => (SNMP [Sub]Agent
for Asterisk)

== Starting SubAgent

Редактирование /etc/snmp/snmpd.conf
для работы с вашим сервером OpenNMS

Теперь мы можем изменить файл
/etc/snmp/snmpd.conf для SNMP на хосте. Переименуем
текущий пример конфигурационного файла
и создадим новый файл snmpd.conf:

$ cd /etc/snmp

$ sudo mv
snmpd.conf snmpd.sample

Первое что нужно сделать —
это добавить права доступа этому файлу.
Мы предлагаем вам прочитать файл
/etc/snmpd/snmp.sample, который вы переименовали
для лучшего представления об установке
прав доступа. Затем добавим следующее
в ваш файл snmpd.conf:

$ sudo sh -c
cat > snmpd.conf

com2sec notConfigUser default public

group notConfigGroup v1 notConfigUser

group notConfigGroup v2c notConfigUser

view all included .1

view
system included .iso.org.dod.internet.mgmt.mib-2.system

access notConfigGroup «»
any noauth exact all none none

syslocation Caledon, ON

syscontact Leif Madsen
[email protected]

Ctrl+D

Строки syslocation
и syscontact необязательны,
но они могут облегчить идентификацию
сервера, если вы мониторите несколько
узлов.

Теперь нам нужно включить
поддержку субагента AgentX что бы мы могли
найти информацию о нашей системе
Asterisk:

$ sudo cat >> snmpd.conf

master agentx

agentXSocket /var/agentx/master

agentXPerms 0660 0775 nobody root

sysObjectID .1.3.6.1.4.1.22736.1

Ctrl+D

В дополнении к строке master
agentx и опции agentX,
мы включаем на Asterisk демон SNMP для
коммуникации. Опция agentXPerms
говорит, что Asterisk запущен от root. Если
ваш Asterisk запущен от другой группы
замените root на группу от которой
запущен Asterisk.

Чуть ниже конфигурации AgentX,
мы добавили параметр sysObjectID.
Цель добавления строки sysObjectID
указать OpenNMS на хост-систему Asterisk, что
позволяет динамически захватить
дополнительную информацию для графиков.

После того, как вы выполните
эти шаги по настройке, вам нужно
перезапустить демон SNMP:

$ sudo /etc/init.d/snmpd restart

Чтобы убедиться что информация
будет передаваться правильно, используйте
приложение snmpwalk:

$ snmpwalk -On -v2c -c public 127.0.0.1
.1.3.6.1.4.1.22736

Если вы правильно все настроили,
то должны получить несколько строк с
информацией на вашем экране, подобно
этим:

.1.3.6.1.4.1.22736.1.5.4.1.4.3 = INTEGER: 2

.1.3.6.1.4.1.22736.1.5.4.1.4.4 = INTEGER: 2

.1.3.6.1.4.1.22736.1.5.4.1.4.5 = INTEGER: 1

.1.3.6.1.4.1.22736.1.5.4.1.4.6 = INTEGER: 1

.1.3.6.1.4.1.22736.1.5.4.1.5.1 = INTEGER: 1

…etc

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

Наблюдение за Asterisk с OpenNMS

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

Рисунок 24-1 содержит график,
показывающий количество активных
каналов в Asterisk в различное время.

Рисунок 24-2 показывает график
активности каналов определенного типа.
В данном случае мы просматриваем
количество активных каналов DAHDI в
системе. Мониторинг каналов DAHDI интересен
с практической стороны, поскольку каналы
DAHDI взаимосвязаны с физическими ресурсами
и доступное количество каналов
предопределено. Это будет очень полезно
для управления использования каналами
DAHDI и получения уведомлений о занятости
всех каналов, это может послужить
сигналом для добавления дополнительных
каналов.

В завершение, Рисунок 24-3
показывает использование сетевого
интерфейса. Как вы можете видеть, были
всплески трафика, следующего «в» и «из»
системы, когда происходили SIP вызовы.

Заключение

Asterisk очень хорошо позволяет
отслеживать различные аспекты своей
деятельности, начиная от CDR до полной
отладки выполнения кода. Эти различные
механизмы помогут вам в управлении УАТС
Asterisk и представляют собой один из
моментов, в которых Asterisk значительно
превосходит большинство (если не все)
традиционные АТС.

1Который
обычно находится в /etc/syslog.conf.

2И
rsyslog, syslog-ng и все остальное.

3Если
вы представите патч для добавления
любого из этих событий в код и опишите
эту сноску, Рассел вышлет вам бесплатно
футболку Asterisk. Сноска за взятку!

4OpenNMS,
конечно не единственная платформа,
которая может быть использована с
модулем res_snmp. Тем
не менее, мы решили обсудить её здесь
по ряду причин. Во-первых, OpenNMS очень
хорошая платформа управления сетью,
которая имеет специальную интеграцию
с Asterisk. Во-вторых, это открытый исходный
код и 100% бесплатный. Наконец, Джефф
Гельбах из OpenNMS внесший свой вклад в
развитие Asterisk, прилагает значительные
усилия в поддержке SNMP. OpenNMS также был
достаточно хорош, чтобы помочь нам
получить описание как все это работает,
что мы могли задокументировать это.

5Дополнительно
вы можете найти пост
в блоге о включении SNMPv3 для OpenNMS.

Также доступны:  EN 

Обновлено: 19 марта 2019