Добавляем в CDR две колонки:
- hangupcause (int4);
- hangupparty (varchar или сделать отдельный тип enum 'caller|callee').
Далее добавляем в app_dial.c переменную типа char buf_hangup_str[8], по очереди пишем в неё значения ast_channel_hangupcause(chan) и ast_check_hangup(chan), и сбрасываем в CDR через ast_cdr_setvar.
Соответствующий патч ниже.
0) Логирование
-xlog и acc в LOCAL4 и Postgres
-настройка syslog-ng на запись LOCAL4 в opensips.log
-do_accounting("db|log","cdr|missed|failed") на начальный INVITE
1) Чёрные листы
-partition надо задать параметром, default не работает
-данные берутся из кэша, считываются из БД на старте, обновление через address_reload в cli
2) Регистрация, аутентификация, привязка к IP
-для аутентификации используются модули auth_db для доступа к таблице subscriber и auth для самой аутентификации
-данные зарегистрированного клиента сохраняются в таблицу location функцией save модуля registrar
-используются модули usrloc, registrar, auth, auth_db, signaling, tm, sl
-после аутентификации INVITE не забывать вызывать функцию consume_credentials(), чтобы удалить реквизиты из заголовка Authentication при дальнейшей пересылке
CARRIERROUTE
Модуль, обеспечивающий возможности маршрутизации, балансировки и черных списков. Он считывает маршруты из базы данных или файла конфигурации на старте OpenSIPS. Может использовать одно дерево маршрутизации (для одного оператора) или, при необходимости, для каждого пользователя — отдельное дерево маршрутизации (уникальное для каждого оператора) для маршрутизации на основе префикса номера. Поддерживает несколько доменов дерева маршрутов, например, для резервирования маршрутов или разных правил маршрутизации в зависимости от пункта назначения.
Модуль скалируется до более чем нескольких миллионов пользователей и способен обработать более нескольких сотен маршрутов. В сценариях балансировки рекомендуется использовать файл конфигурации, чтобы не вносить дополнительную сложность с запросами БД.
В целом, этот модуль можно использовать в качестве замены для модулей lcr и dispatcher, если у есть определенные требования к производительности, гибкости и/или интеграции, с которыми эти модули не справляются. Но для небольших установок, вероятно, имеет смысл использовать lcr и диспетчерский модуль.
Если модуль используется в маршруте ошибки (failure route), то необходимо вызвать функцию append_branch() после перезаписи RURI, чтобы сообщение ушло новому получателю.
Зависимости: tm, database (если используем БД)
B2B_ENTITIES
Реализация модели B2B разделена на два уровня:
- нижний, который реализует этот модуль, для базовых функций UAS и UAC;
- верхний, который реализует модуль b2b_logic (см. ниже), для всей логики B2BUA.
Этот модуль хранит записи соответствующих диалогов, в которых используется модель B2BUA. Он представляет API для других модулей, которые используют свои функции для создания нового диалога, для отправки сообщений этого диалога и заодно оповещает модуль верхнего уровня о поступлении сообщения внутри диалога. Записи разделяются на два типа: b2b записи сервера и b2b записи клиента, в зависимости от того, в каком режиме они созданы. Записи созданные для полученного начального запроса будут серверными, в то время как записи, для которых будут оправлены начальные запросы (т.е. создан новый диалог), станут записями b2b клиента. Этот модуль не реализует модель B2BUA самостоятельно, к нему ещё нужен модуль B2B логики.
Модуль b2b_entities может отвечать на запросы аутентификации, если загружен модуль uac_auth. Список реквизитов для аутентификации так же предоставляется модулем uac_auth.
Зависимости: b2b_logic, tm, db, uac_auth (если нужна аутентификация)
Просто, чтобы не вспоминать каждый раз.
# ssh -p 4322 -N -L 10.1.1.6:2222:10.77.20.29:80 myname@localhost
Логика маршрутизации
Логика маршрутизации представляет из себя сумму маршрутов (routes), которые содержат правила обработки сообщений SIP.
Маршруты делятся на два вида:
- основные маршруты (top routes) - это маршруты, которые напрямую запускаются (вызываются) OpenSIPS при возникновении некоторых событий (таких как поступление запроса или ответа, ошибка транзакции и т.п.);
- подмарштуры (sub-routes)- маршруты, которые вызываются из других маршрутов скрипта. Подмаршруты имеют имена и должны вызываться по ним из других маршрутов или подмаршрутов. Подмаршруты могут принимать параметры или возвращать числовой код (избегайте возврата нулевого значения (0), так как это завершит работу всего скрипта). Подмаршруты похожи на процедуры или функции в любом языке программирования!
Для перехода в подмаршрут используется функция route.
route(name [, param1 [, param2 [, ...] ] ] )
Она может принимать до семи параметров, которые в дальнейшем могут быть получены обращением к псевдо переменной '$param(idx)'.
Например, route(HANDLE_SEQUENTIALS, 1, "param", $var(param));
В OpenSIPS несколько типов переменных. Их отличия в том, в какой части скрипта они видны, за чем закреплены, могут ли хранить несколько значений (как массив) и являются ли перезаписываемыми.
Переменные определяются по наличию знака "$" перед их именем.
Обращение к переменной имеет следующий синтаксис (зеленые поля опциональны): $(<context>name(subname)[index]{transformation})
- name - имя переменной. Например: pvar, avp, ru, DLG_status.
- subname - идентификатор конкретного значения переменной данного типа (тип задаётся именем). Например: hdr(From), avp(name).
- index - индекс в массиве, если переменная поддерживает хранение нескольких значений. Индекс может быть отрицательным числом, где "-1" означает последнее добавленное значение, а "-2" - предпоследнее.
- transformation - некоторые преобразования, которые можно применить к переменной. Например: обрезка, преобразование типа, вычисление длины и т.п. Преобразования могут быть каскадными, в этом случае каждое последующее преобразование осуществляется над результатом предыдущего. Список преобразований тут.
- context - контекст, где переменная будет востребована. Есть два контекста: reply и request. Контекст reply может быть указан в failure маршруте для получения переменной из ответа на запрос. Контекст request может быть указан в маршруте reply для получения переменной из соответствующего запроса.
При получении OPTIONS Астериск ищет номер "s" в контексте default.
Поэтому простого диалпана вида
[default]
exten => s,1,Hangup
Просто чтобы не забыть.
Заголовок Path - это такой аналог Record-Route для сообщений REGISTER и ответов на них, т.е. для сообщений вне диалога. Назначение аналогичное - запись цепочки адресов прокси, через которые проходят сообщения. Синтаксис аналогичен Record-Route.
Проверка привязки делается по двум группам в таблице address модуля permissions. Сначала в одной группе ищется совпадение username из реквизитов аутентификации по сети 0.0.0.0/0 (т.е. по всем адресам), затем в другой группе ищется совпадение IP/username. Если совпадает, то запрос обрабатывается обычным образом.
На примере запроса REGISTER. Аккаунту 4521 разрешено подключаться только с IP 10.49.2.78.
