Канальное окончание не может аутентифицироваться при определении номера вызывающего

[alx]

ДАНО:

Канальное окончание SIP, работающее с соединительной линией (например 1IND) регистрируется на внешнем сервере SIP, принимает вызовы из канала TDM и передает их во внешний SIP-коммутатор. Для доступа к коммутатору требуется аутентификация.

ПРОБЛЕМА:

При использовании определения номера вызывающего абонента (АОН в случае 1IND) канальное окончание не может аутентифицироваться на внешнем коммутаторе, из-за чего вызов оказывается неуспешным.

ПРИЧИНА:

При создании канального окончания имя и пароль для его аутентификации помещаются в специальное хранилище, организованное библиотекой libeXosip2. При получении ответов 401/407 на отправленное сообщение (например INVITE или REGISTER) libeXosip2 ищет данные аутентификации в этом хранилище, и если находит, автоматически повторяет отправку сообщения, добавив к нему поле аутентификации.

Когда канальное окончание, работающее с соединительной линией, отправляет INVITE, и при этом знает номер вызывающего абонента (например успешно получена кодограмма АОН окончанием 1IND), номер вызывающего абонента помещается в поле FROM сообщения INVITE вместо имени пользователя (username), заданного в URI канального окончания (конфигурационный параметр SIP URI). При получении ответов 401/407 на отправленный INVITE библиотека libeXosip не может найти данные аутентификации в хранилище, так как ключом, по которому выполняется поиск, является имя пользователя URI поля From.

ВОЗМОЖНЫЕ РЕШЕНИЯ:

1. Отказаться от использования поля From для передачи номера вызывающего абонента, и вместо этого использовать поля типа P-Asserted-Identity/RPID. Недостаток этого решения - не все UAS понимают PAI/RPID.
2. "Закат солнца вручную" - отказаться от аутентификации средствами libeXosip, и при получении ответа 401/407 своими силами добавлять в запрос поля аутентификации.

[alx]

Вариант 1 реализован. Будем считать, что этого достаточно. Закат солнца вручную производить не будем. :)