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

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

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

— Будда

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

Тип	Описание
notice	Вы увидите много сообщений во время перезагрузки, а также они будут приходить во время обычных вызовов. notice просто любое событие, о котором Asterisk хотел бы проинформировать вас.
warning	Warning (предупреждение) представляет собой проблему, которая может быть достаточно серьезной чтобы повлиять на вызов (в том числе отключение вызова, потому что поток вызова не может продолжаться). Предупреждения нужно устранять.
error	Errors (ошибки) представляют собой значительные проблемы в системе, которые должны быть решены немедленно.
debug	Отладка полезна только если вы пытаетесь устранить проблемы с кодом Asterisk. Вы не будете использовать отладку для устранения проблем в диалплане, но вы должны использовать её если разработчики Asterisk попросили вас предоставить журнал для отчетности о проблеме. Не используйте отладку в продакшене, поскольку количество сохраненных записей может заполнить жесткий диск в течение нескольких дней.a
verbose	Это один из самых полезных типов протоколирования, но он также является одним из наиболее рискованных; если его оставить без присмотра, то велика вероятность заполнения жесткого диска.b
dtmf	Журналирование DTMF может быть полезно если вы получаете жалобы, что вызовы неправильно маршрутизируются от автосекретаря.
fax	Этот тип протоколирования обрабатывает сообщения связанные с технологией факса (res_fax_spandsp или res_fax_digium) сохраняемые факс-регистратором.
*	Будет протоколировать ВСЁ (EVERYTHING) (и мы подразумеваем всё). Не используйте это, если вы не представляете последствия хранения такого объема данных. Ничем хорошим это не закончится.

^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 по умолчанию

Опция	Значение/Пример	Примечание
accountcode	12345	Идентификатор учетной записи. Это поле определяется пользователем и пустое по умолчанию.
src	12565551212	ID вызывающего абонента. Он устанавливается автоматически и доступен только для чтения.
dst	102	Добавочный номер назначения для вызова. Это поле устанавливается автоматически и доступно только для чтения.
dcontext	PublicExtensions	Контекст назначения для вызова. Это поле устанавливается автоматически и доступно только для чтения.
clid	«Big Bird» <12565551212>	Полный идентификатор вызывающего абонента, включая имя вызывающего абонента. Это поле устанавливается автоматически и доступно только для чтения.
channel	SIP/0004F2040808-a1bc23ef	Канал вызывающей стороны. Это поле устанавливается автоматически и доступно только для чтения.
dstchannel	SIP/0004F2046969-9786b0b0	Канал вызываемой стороны. Это поле устанавливается автоматически и доступно только для чтения.
lastapp	Dial	Последнее приложение диалплана, которое было выполнено. Это поле устанавливается автоматически и доступно только для чтения.
lastdata	SIP/0004F2046969,30,tT	Аргументы переданные в lastapp. Это поле устанавливается автоматически и доступно только для чтения.
start	2010-10-26 12:00:00	Время начала вызова. Это поле устанавливается автоматически и доступно только для чтения.
answer	2010-10-26 12:00:15	Время ответа на вызов. Это поле устанавливается автоматически и доступно только для чтения.
end	2010-10-26 12:03:15	Время окончания вызова. Это поле устанавливается автоматически и доступно только для чтения.
duration	195	Количество секунд между началом вызова и окончанием. Это поле устанавливается автоматически и доступно только для чтения.
billsec	180	Количество секунд между ответом на вызов и окончанием вызова. Это поле устанавливается автоматически и доступно только для чтения.
disposition	ANSWERED	Индикатор того, что случилось с вызовом. Это может быть NO ANSWER, FAILED, BUSY, ANSWERED или UNKNOWN.
amaflags	DOCUMENTATION	Automatic Message Accounting (AMA) флаг связанный с этим вызовом. Он может быть одним из следующего: OMIT, BILLING, DOCUMENTATION или Unknown.
userfield	PerMinuteCharge:0.02	Поле пользователя общего назначения. По умолчанию это поле пусто и может быть задано в виде пользовательской строки.a
uniqueid	1288112400.1	Уникальный ID канала src. Это поле устанавливается автоматически и доступно только для чтения.

^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]

Опция	Значение/Пример	Примечание
enable	yes	Включает логирование CDR. По умолчанию — yes.
unanswered	no	Протоколирует неотвеченные вызовы. Обычно только отвеченные вызовы попадают в CDR. Протоколирование всех попыток вызова может привести к большому числу дополнительных записей о вызовах, а в большинстве своем они не нужны. По умолчанию — no.
end before hexten	no	Закрывает вывод CDR до запуска расширения h в диалплане Asterisk. Обычно CDR не прекращается пока диалплан полностью не завершит работу. По умолчанию — no.
initiated seconds	no	При вычислении поля billsec всегда округляется вверх. Например, если разница между ответом и завершением составляет 1 секунду и 1 микросекунду, billsec будет установлен на 2 секунды. Это помогает гарантировать поведение CDR Asterisk аналогичному поведению телекоммуникационных компаний. По умолчанию — no.
batch	no	Очередь записей CDR будет протоколирована в пакетах, а не синхронизирована по завершению каждого вызова. Это предотвращает протоколирование CDR блокированных завершенных вызовов с разрушенным процессом Asterisk. Использование режима batch может быть невероятно полезно при работе с базой данных, которая может быть медленной для обработки запросов. Значение по умолчанию — no, но мы рекомендуем его включить.a
size	100	Устанавливает число записей CDR, находящихся в очереди прежде чем они запишутся в пакетном режиме. По умолчанию значение — 100.
time	300	Устанавливает максимальное количество секунд, которое CDR записи будут ждать в очереди, прежде чем пакет будет сохранен. Процесс регистрации пакета CDR будет выполнен по завершению этого периода времени, даже если размер не был достигнут. Значение по умолчанию составляет 300 секунд.
scheduler only	no	Устанавливает когда процесс пакетной обработки CDR должен порождать новый поток или запланировано новое содержимое пакета CDR. Значение по умолчанию — no и мы рекомендуем не менять его.
safe shutdown	yes	Блокирует выключение Asterisk, чтобы убедиться, что все в очереди записей CDR сохранены в журнал. По умолчанию — yes и мы рекомендуем оставить его таким, так как эта опция предотвращает потери важных данных.

^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

Опция	Значение/Пример	Примечание
connection	pgsql1	Соединение с базой данных, которая будет использоваться. Это ссылка на настроеное соединение в res_odbc.conf. Поле является обязательным.
table	asterisk_cdr	Имя таблицы. Это поле является обязательным.
usegmtime	no	Указывает, следует ли временные метки логирования использовать по GMT, а не местному времени. По умолчанию значение этой опции — no.

В дополнение к паре полей ключ/значение (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]

Опция	Значение/Пример	Примечание
usegmtime	no	Записывает временные метки по GMT, а не по локальному времени. По умолчанию — no.
loguniqueid	no	Записывает переменную CDR uniqueid. По умолчанию — no.
loguserfield	no	Записывает переменную CDR userfield. По умолчанию — no.
accountlogs	yes	Создает отдельный файл CSV для каждого значения переменной CDR accountcode. По умолчанию — yes.

Порядок переменных 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 110@testing

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

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]

Опция	Значение/Пример	Примечание
usegmtime	no	Включает логирование с временными метками по GMT, а не по локальному времени. По умолчанию — yes.
log unique id	no	Включает логирование переменной CDR uniqueid. По умолчанию — yes.
loguserfield	no	Включает логирование переменной CDR userfield. По умолчанию — yes.
radiuscfg	/etc/radiusclient-ng/radiusclient .conf	Задает расположение файла конфигурации radiusclient-ng. По умолчанию /etc/radiusclient-ng/radiusclient.conf

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

Типы событий CEL	Описание
CHAN_START	Канал был создан.
CHAN_END	Канал был разрушен.
LINKEDID_END	Последний канал с заданным linkedid был уничтожен.
ANSWER	Канал ответил. Канал создан для исходящего вызова. Это событие будет создано, когда ответит удаленный конец.
HANGUP	Канал повесил трубку. Как правило, это событие будет следовать очень быстро за событием CHAN_END. Разница в том, что это событие происходит, как только получен запрос hangup, в то время как CHAN_END происходит после завершения Asterisk процедуры очистки вызова и все ресурсы, связанные с этим каналом были освобождены.
APP_START	Отслеживаемое приложение начало выполняться на канале. Отслеживаемые приложения задаются в файле конфигурации основной ячейки, который описан в разделе «cel.conf”.
APP_END	Отслеживаемое приложения прекратило выполнение на канале.
PARK_START	Канал был припаркован.
PARK_END	Канал снял парковку.
BRIDGE_START	Запущен соединения каналов. Это событие наступает, когда два канала соединяются с помощью приложений Dial() или Queue().
BRIDGE_END	Соединение каналов был закрыто.
BRIDGE_UPDATE	Произошло обновление соединения. Это событие быдет происходить если имя канала или другая информация были изменены во время соединения.
BLINDTRANSFER	Канал выполнил слепой трансфер.
ATTENDEDTRANSFER	Канал выполнил трансфер с уведомлением.
USER_DEFINED	Произошло пользовательское событие канала. Это событие создано с использованием приложения CELGenUserEvent().

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

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

Тип события CEL	Описание
CONF_ENTER	Канал, который подключается к комнате конференции.
CONF_EXIT	Канал, который отключился от комнаты конференции.
CONF_START	Конференция была начата. Это событие происходит, когда первый канал входит в комнату конференции.
CONF_END	Конференция была закончена. Это событие происходит, когда последний канал покидает комнату конференции.
3WAY_START	Старт трехстороннего вызова.
3WAY_END	Завершение трехстороннего вызова.
TRANSFER	Основной трансфер был выполнен.
HOOKFLASH	Канал сообщил о событии сигнал отбоя (hookflash).

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

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

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

Имя поля	Значение/Пример	Примечания
eventtype	CHAN_START	Имя события. Список событий, которые могут произойти можно найти в Таблице 24-7.
eventtime	2010-08-19 07:27:19	Время когда произошло событие.
cidname	Julie Bryant	Имя caller ID установленное на канале связанным с этим событием .
cidnum	18435551212	Номер caller ID установленный на канале связанным с этим событием.
cidani	18435551212	Номер Automatic Number Identification (ANI) установленный на канале связанным с этим событием.
cidrdnis	18435551234	Перенаправление номера установленного на канале связанным с этим событием.
ciddnid	18435550987	Вызываемый номер установленный на канале связанным с этим событием.
exten	101	Расширение в диалплане, которое сейчас начало выполняться.
context	LocalSets	Контекст для расширения в диалплане, которое сейчас начало выполняться.
channame	SIP/0004F2060EB4-00000010	Имя канала связанное с этим событием.
appname	Dial	Имя приложения диалплана начавшее сейчас выполняться.
appdata	SIP/0004F2060E55	Аргументы, передаваемые приложению диалплана, которое сейчас начало выполняться.
amaflags	DOCUMENTATION	Флаг Automatic Message Accounting (AMA) асоциируется с этим вызовом. Может принимать одно из следующих значений: OMIT, BILLING, DOCUMENTATION, или Unknown.
accountcode	1234	account ID. Это поле определяется пользователем и по умолчанию пустое.
uniqueid	1282218999.18	Уникальный ID для канала, который связан с этим событием.
userfield	I like waffles!	Содержание пользовательского события.
linkedid	1282218999.18	ID каждого вызова. Этот ID позволяет связать воедино несколько событий из нескольких каналов, которые являются частью одного и того же логического вызова. ID исходит от uniqueid первого канала в вызове.
peer	SIP/0004F2060E55-00000020	Название канала соединенного с каналом, определенным в channame.

Некоторые содержания событий 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]

Опция	Значение/Пример	Примечание
enable	yes	Включает/Отключает CEL. По умолчанию — no.
apps	Dial,queue	Устанавливает приложение диалплана для отслеживания. По умолчанию для отслеживания приложений нет. События EV_APP_START и EV_APP_END будут генерироваться когда каналы запустят и остановят выполнение любых отслеживаемых приложений.
events	CHAN_START,CHAN_END, ANSWER,HANGUP	Списки генерируемых событий. Это полезно, если вы заинтересованы только в подмножестве событий, генерируемых CEL. Если же хотите увидеть все события, установите эту опцию в ALL. Значение по умолчанию не генерирует события.
dateformat	%F %T	Указывает формат даты когда событие CEL содержит отметку времени. Сведения о синтаксисе см. в руководстве для strftime, запустив man strftime в командной строке. Формат по умолчанию для метки времени CEL second.microseconds с эпохи.

Как минимум для начала использования 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

Тип события	Целочисленное значение
CHANNEL_START	1
CHANNEL_END	2
HANGUP	3
ANSWER	4
APP_START	5
APP_END	6
BRIDGE_START	7
BRIDGE_END	8
CONF_START	9
CONF_END	10
PARK_START	11
PARK_END	12
BLINDTRANSFER	13
ATTENDEDTRANSFER	14
TRANSFER	15
HOOKFLASH	16
3WAY_START	17
3WAY_END	18
CONF_ENTER	19
CONF_EXIT	20
USER_DEFINED	21
LINKEDID_END	22
BRIDGE_UPDATE	23
PICKUP	24
FORWARD	25

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

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

Опция	Значение/Пример	Примечание
connection	pgsql1	Определяет, какая база данных будет использоваться. Это ссылка на настроенное соединение в res_odbc.conf. Это поле является обязательным.
table	asterisk_cdr	Определяет имя таблицы. Это поле обязательно.
usegmtime	no	Включает/выключает при логировании использование временных меток GMT, а не локального времени. По умолчанию значение этой опции — no.

В дополнение к паре полей ключ/значение, которые показаны в предыдущей таблице, 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]

Переменная CEL	Значение	Описание
${eventtype}	CHAN_START	Имя события CEL.
${eventtime}	1281980238.660403	Временной штамп для событий CEL. В этом примере штамп времени приводится в формате по умолчанию.
${eventextra}	Whiskey Tango Foxtrot	Пользовательские данные, включаемые с событием CEL. Дополнительные данные включаются когда используется CELGenUserEvent().

Это пример файла /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 111@testing

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

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

Опция	Значение/Пример	Примечание
usegmtime	no	Использует штамп времени GMT (гринвич меридиан тайм) вместо локального времени. По умолчанию — yes.
radiuscfg	/etc/radiusclient-ng/radiusclient.conf	Устанавливает размещение конфигурационного файла radiusclient-ng. По умолчанию /etc/radiusclient-ng/radiusclient.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.