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

 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 при дальнейшей пересылке

3) Нормализация номеров (модуль dialplan)

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

-для изменения заголовков RURI используем core функцию setuser или напрямую пишем в переменные $ru или $rU, они r/w

-для изменения заголовков FROM и TO используем модуль UAC, для заголовка CONTACT модуль b2b_logic

-ну или тупо удаляем/добавляем заголовок модулем sipmsgops

4) Роутинг и балансировка (модуль drouting)

-тип и период keep-alive сообщений задаются параметрами модуля

-там же важно задать коды ответов шлюза probing_reply_codes, кроме "200". Астериск может вернуть "404", например

-для нашего случая достаточно добавить два шлюза в таблицу dr_gateways и выбирать доступный командой route_to_gw("gw1,gw2")

-добавление или изменение данных в таблице dr_gateways можно зафиксировать только перезапуском OpenSIPS. Через команды mi можно только перегрузить правила rules

-в маршруте failure_route можно командой t_check_status проверить код ответа шлюза и, при необходимости, перенаправить вызов на другой шлюз командой use_next_gw()

-если шлюз не отвечает, то модуль tm возвращает код "408", по нему тоже можно вызвать use_next_gw()

4.1) Балансировка (модуль load_balancer)

-во многом принцип тот же, что и у drouting

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

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

-как и в drouting, можно перенаправить вызов на следующий шлюз в failure_route на основе ответа на INVITE

-команда mi lb_reload полностью обновляет список шлюзов данными из таблицы load_balancer

5) NAT и media_proxy

-модули nat_traversal и nathelper обеспечивают примерно одинаковый функционал, выбирать по вкусу

-rtpproxy качается с git, собирается элементарно, параметром запуска указывается сокет обмена данными с OpenSIPS (-s)

-параметром запуска модуля rtpproxy указываем IP адрес, который будет подставляться в SDP

-функция rtpproxy_engage() в начальном INVITE сама следит за модификацией SDP последующих запросов

6) Кастомные запросы к БД (sqlops)

-тут единственный момент, что sqlops появляется в версии >= 3.5, а в 3.4 используется avpops с функцией avp_db_query

7) Чистый stateless прокси

-чистый stateless не имеет смысла, потому что в отсутствии record-route UAS будет слать последующие запросы на URI из поля CONTACT, т.е. мимо прокси