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, можно в отдельном роуте (как процедура)
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
-можно делать и через rules, тогда в таблице dr_rules указываем groupid и gwlist, prefix оставляем пустым, при этом убирая ограничение NOT NULL со столбца, и выбираем шлюз командой do_routing($groupid); тогда можно управлять приоритетами шлюзов без перезапуска OpenSIPS, используя только "mi dr_reload"
-в маршруте 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
-для GeoIP результат запроса сохраняем в avp, чтобы была привязка переменной к конкретному запросу
7) Чистый stateless прокси
-чистый stateless не имеет смысла, потому что в отсутствии record-route UAS будет слать последующие запросы на URI из поля CONTACT, т.е. мимо прокси
Комментариев нет:
Отправить комментарий