Модификация приложения Record для отлавливания нужного кода DTMF

Продолжаем мучать app_record.c

Задача: отловить набор внутреннего номера. Номера начинаются с "4".

Т.е. нужно прервать запись только по нажатию "4", и сообщить об этом факте.

Добавим опцию "e" в приложение Record. Для этого:

Распаковка initramfs

# mkdir initramfs_tmp

# cd initramfs_tmp

# cp /boot/initramfs-6.12.34-gentoo-dist.img .

# mv initramfs-6.12.34-gentoo-dist.img initramfs-6.12.34-gentoo-dist.xz

# unzstd initramfs-6.12.34-gentoo-dist.xz

# cat initramfs-6.12.34-gentoo-dist | cpio -idmv

Добавляем в CDR причину и инициатора разрыва соединения

 Добавляем в 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.

Соответствующий патч ниже.

Заметки по поводу настройки OpenSIPS

 0) Логирование

-xlog и acc в LOCAL4 и Postgres

-настройка syslog-ng на запись LOCAL4 в opensips.log

-для записи CDR нужен модуль dialog

-do_accounting("db|log","cdr|missed|failed") на начальный INVITE

1) Чёрные листы (модуль permissions)

-partition надо задать параметром, default не работает

-данные берутся из кэша, считываются из БД на старте, обновление через address_reload в cli

-для наших целей можно для каждого клиента делать отдельную запись в таблице address, pattern указывать с помощью wildcards (например, [Pp]ety*), а в context_info хранить accountcode

2) Регистрация, аутентификация, привязка к IP

-для аутентификации используются модули auth_db для доступа к таблице subscriber и auth для самой аутентификации

-данные зарегистрированного клиента сохраняются в таблицу location функцией save модуля registrar

-используются модули usrloc, registrar, auth, auth_db, signaling, tm, sl

-после аутентификации INVITE не забывать вызывать функцию consume_credentials(), чтобы удалить реквизиты из заголовка Authentication при дальнейшей пересылке

-проверку IP-адреса клиента нужно делать после www_challenge, т.е. когда уже получен authentication user, можно в отдельном роуте (как процедура)

Модули маршрутизации в OpenSIPS

CARRIERROUTE

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

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

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

Если модуль используется в маршруте ошибки (failure route), то необходимо вызвать функцию append_branch() после перезаписи RURI, чтобы сообщение ушло новому получателю. 

Зависимости: tm, database (если используем БД)

Модули SIP сигнализации в OpenSIPS

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

Просто, чтобы не вспоминать каждый раз.

# ssh -p 4322 -N -L 10.1.1.6:2222:10.77.20.29:80 myname@localhost