Добавить конфигурацию имени домена для SIP-пользователей

[alx]

Сейчас SIP-пользователи могут использовать только IP адрес платы в качестве домена. Надо добавить глобальный конфигурационный параметр для установки имени домена. На это имя будет проверяться домен всех входящих запросов (INVITE, REGISTER).

[alx]

В настоящее время в веб-интерфейсе в списке SIP-пользователей платы VE-1/VE-02 задается только имя пользователя, но не домен. Однако при добавлении пользователя в repro необходимо указывать и имя, и домен.

В качестве домена используется IPv4 адрес интерфейсе WAN (eth0). Что уже нехорошо, так как это может быть не единственный адрес интерфейса.

Адрес интерфейса может меняться, поэтому его приходится отслеживать, и в случае изменения менять домен всем имеющимся в базе данных пользователям.

Предлагается рассмотреть и решить описанную в тикете задачу более широко и в несколько этапов.

Этап 1.

Изменить поведение repro таким образом, чтобы в его базе данных пользователей не требовалось указывать реальный домен. Например заменить все домены на "*" или пустую строку (""). Одновременно изменить код, который ищет пользователей в базе данных таким образом, чтобы вместо realm/domain он указывал "*" или "". Таких обращений сейчас, насколько я вижу, три, и все они находятся внутри UserAuthGrabber::process:

• проверка пароля для DigestAuthenticator (вызывает getUserAuthInfo());
• проверка пароля для ServerAuthManager (вызывает getUserAuthInfo());
• проверка существования юзера для Presence server (вызывает getUserInfo()).

Благодаря этому изменению:

• поведение платы при существующих настройках будет сохранено (так как прокси находит пользователя при любом домене и/или IP адресе);
• дополнительно плата будет находить пользователя с адресом IPv6 в качестве домена.
• отпадает необходимость менять домены в базе данных пользователей при каждой смене IP.

Этап 2

Дать возможность сосуществовать пользователям без указания домена и пользователям с указанием домена. Это потребует доработки веб-интерфейса конфигурации в SW-01 (а может и нет, если разрешить указывать пользователей в форме "user@domain"!).

Поведение repro в указанной выше функции UserAuthGrabber::process изменить таким образом, чтобы она сначала пыталась найти в базе данных пользователя с "настоящим" доменом (то есть как это есть есйчас), и только если такого пользователя в базе нет, делать вторую попытку, указывая вместо домена "*" (или "").

Аналогично надо будет изменить в нашем коде функцию repro_get_user_info().

Еще имя пользователя является ключом к хэшу userExtraDataMap. Доступ к нему надо будет также переделать (добавить метод, принимающий URI, и пробующий сначала найти "user@domain", а в случае неудачи - просто "user").

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

Этап 2.1

Добавить глобальный конфигурационный параметр, в котором плате будет передаваться дополнительный список ее доменов (аналог параметра Domains в repro.conf). "Дополнительный" - потому что "localhost", "127.0.0.1", "::1" и текущие IP адреса eth0 по-прежнему добавляются в этот список автоматически.

Одновременно первый домен из этого списка предлагается использовать как tlsDomain - домен сервера для TLS транспорта (типа "главный" домен). Сейчас в этом качестве используется адрес IPv4 интерфейсе eth0.

[alx]

С этапом 1 есть дополнительная трудность: сейчас repro хранит в базе данных пользователей хэши паролей, при вычислении которых используется имя домена. Таким образом, прежде чем реализовать этап 1, потребуется изменить логику работы repro таким образом, чтобы вместо хэша в базе данных пользователей хранились пароли в открытом виде, а хэш вычислялся каждый раз, когда требуется аутентификация.

[alx]

Так как несколько попыток реализации этапа 1 не увенчались успехом, предлагается другой подход.

1. В repro.cpp должен храниться список пользователей userList, переданный из

sw-01.

2. Каждый пользователь из userList добавляется в базу данных repro дважды - с доменом в виде адреса IPv4 и с доменом в виде адреса IPv6 (при их наличии). Когда и если в будущем плате будут назначаться дополнительные домены, "бездоменные" пользователи будут добавляться в БД и с ними тоже. Если же в конфигурации пользователю уже назначен домен, то пользователь добавляется в БД только с этим доменом (возможно, IP адреса должны использоваться тоже - это пока открытый вопрос).

[san]

Недавно(#412) разбирали случай, когда вызов на нашу плату приходил с указанным в URI "чужим" доменом.
Изменить URI вызова пользователь не мог (Ростелеком хочет чтобы был именно такой домен).
Пользователь решил проблему добавив нужный домен в Domains в /etc/repro.config, однако у такого решения есть недостаток - после обновления ПО платы, изменения внесённые пользователем в конфиг прокси пропадут.
Я хотел предложить добавить плате конфигурационный параметр, в котором будет дополнительный список ее доменов, но я вижу, в этогм тикете уже было такое предложение:

Этап 2.1
Добавить глобальный конфигурационный параметр, в котором плате будет передаваться дополнительный список ее доменов (аналог параметра Domains в repro.conf). "Дополнительный" - потому что "localhost", "127.0.0.1", "::1" и текущие IP адреса eth0 по-прежнему добавляются в этот список автоматически.

Алексей, как ты думаешь, нужно ли мне создать отдельный тикет с предложением или хватит этого?

[alx]

Replying to san:

Алексей, как ты думаешь, нужно ли мне создать отдельный тикет с предложением или хватит этого?

Нет, не нужно, ведь тикет с таким предложением уже есть.

[alx]

In 2152/sip_ua:

Создана ветка для добавленая доменов в repro.
See #121.