Workaround для прокси-серверов, не уважающих Route

[alx]

Введение

Платы VE-01 и VE-02 содержат в себе SIP UA и SIP прокси. UA для сетевой коммуникации (приема/передачи сообщений SIP) использует адрес/порт 127.0.0.1:6060 и, таким образом, недоступен из-за пределов платы. Вся коммуникация с UA может производиться только через прокси-сервер, имеющий доступные из внешней сети транспорты. Для того чтобы запросы SIP всегда передавались через прокси-сервер, в них используется заголовок Route. Пример обмена сообщениями двух UA через два прокси-сервера как он должен происходить:

Проблема

За период производства плат со встроенным прокси-сервером (около 7 лет) стало известно о нескольких случаях неправильной работы внешних прокси-серверов, с которыми столкнулись потребители. Последний из таких случаев заключался в том, что прокси-сервер, работающий в сети пользователя, выбрасывал из запросов SIP заголовки Route и пытался передать сообщение так, как будто никакого маршрута в нем не было, то есть пытался доставить сообщение непосредственно адресату из Request-URI:

Так как в случае платы VE-01 UAS имеет адрес 127.0.0.1, недостижимый напрямую из внешней сети, запрос ACK не достигает получателя.

Задача

Предлагается рассмотреть и обсудить варианты обхода описанной выше проблемы. Варианты будем добавлять в комментарии к этому тикету.

[alx]

Вариант 1: решение "в лоб"

Если прокси-сервер непременно хочет доставлять сообщения напрямую UA, надо сделать так, чтобы UA был напрямую достижим из сети (то есть "пересадить" его с адреса 127.0.0.1 на внешний адрес платы). В этом случае сценарий будет выглядеть примерно так:

Плюсы

• Не очень сложно реализовать.

Минусы

• Так как последующие сообщения в диалоге минуют прокси-сервер платы VE-01, не будут правильно работать многие функции, реализованные в прокси, например:
  • CDR;
  • перехват вызова;
  • громкий бой;
  • и т.д...

• Придется кроме существующего транспорта UDP реализовать в UA также транспорты TCP и TLS.

[alx]

Вариант 2: обход проблемы

1. Если прокси-сервер непременно хочет доставлять сообщения напрямую UA, то в URI поля Cоntact вместо адреса 127.0.0.1 должен указываться внешний адрес платы. Порт оставляет 6060 (или любой другой не занятый, например 60606 - это не важно). В этом случае сообщения от прокси 1 будут попадать в плату. Но вместо того чтобы сразу попадать в UA, полученный пакет средствами iptables в ядре принудительно перенаправляется на порт 5060, то есть в прокси-сервер. Прокси-сервер же для каждого входящего запроса проверяет request URI, и если видит там свой внешний адрес, но порт 6060 (или 60606 - тот, который был прописан ранее в поле Contact), заменяет его на 127.0.0.1:6060. Сценарий должен получиться примерно такой:

Иными словами, в данном сценарии iptables исправляет ошибку прокси-сервера, принудительно перенаправляя пакет, который прокси отправил напрямую UAS, туда, куда пакет и должен был быть отправлен - в прокси-сервер P2.

Плюсы

• Так как в конечном итоге сообщение проходит ровно тот путь, какой и должно было пройти, то в полном объеме должны работать все функции платы (реализованные в прокси-сервере).
• Потребуется минимальная доработка UA.

Минусы

• Потребуется "доработка" прокси-сервера чтобы сделать необходимую замену request URI во всех входящих запросах;
• В платах VE-01 потребуется обновление ядра (сейчас там ядро собрано без поддержки iptables). В VE-02 поддержка iptables уже есть.

[alx]

Подправил диаграмму (для большей наглядности).

[alx]

Еще чуть-чуть подправил диаграммы.