Работа за NAT сервера Oktell

Буквально вчера мы наблюдали начало тестирования последнего обновления Oktell, где была добавлена поддержка работы SIP-сервера за NAT. Решил и я проверить, как оно все работает 🙂

Для чистоты эксперимента, я нахожусь дома, где все устройства работают за WiFi-роутером. И для начало, что бы не играться с пробрасыванием портов, я включу DMZ на своем роутере для ноутбука с установленным Oktell:

DMZ
DMZ

В параметрах аппаратуры для необходимого локального интерфейса прописываем внешний IP-адрес и порт:

Внешний IP
Внешний IP

У SIP шлюза появилось новое свойство «Подставлять внешний ip адрес в пакеты»:

Подставлять внешний ip адрес в пакеты
Подставлять внешний ip адрес в пакеты

В качестве испытуемого выступает удаленный сервер с параметрами «Без регистрации».

Момент истины, принимаем входящий звонок:

Входящий звонок
Входящий звонок

Все прошло успешно, голос не потерялся 😉
Усложняем задачу, на iPhone включаю подключение по EDGE:

EDGE
EDGE

И настраиваем подключение SIP-клиента на Oktell за NAT:

SIP за NAT
SIP за NAT

А вот он у нас успешно зарегистрировался:

SIP-регистрация
SIP-регистрация

И звонит:

SIP звонок за NAT
SIP звонок за NAT

Тест пройден! Теперь можно пробовать на реальных проектах, где раньше приходилось ухитряться… Спасибо разработчикам, за наши счастливые внедрения! 😉

2 комментария on "Работа за NAT сервера Oktell"


  1. Спасибо за доступное разъяснение.
    Подскажите, ЧЯДНТ в следующей конструкции:
    Прокси на CentOS (если это важно) с проброшенными, от безысходности, UDP 1024-65000 на вин-сервер с Oktell. У вин-сервера ДВА сетевых интерфейса. Один получает «серый» адрес изнутри сети по DHCP (static lease), второй — статический белый. На oktell прикручены FXS шлюзы и IP телефоны как снаружи, так и внутри сети ибо есть филиал и ему тоже хочется.
    При указании «белого» IP в качестве SIP-сервера все как и было — подключаются, звонят… При указании IP адреса прокси и настройках Oktell получаем смешную картинку. Первый звонок проходит отлично, а вот второй и последующие — только после перерегистрации.
    Вот логи для первого и второго звонков различаются в строках:
    TRUNK — Prepare Audio answer : create description. descr:8X.XXX.XXX.XXX iface:192.168.111.200 port:13656 (первый звонок пришел через прокси, ушел на «серый» адрес oktell и дальше — куда сказали, туда и пошел)
    и
    TRUNK — Prepare Audio answer : create description. descr:192.168.111.200 iface:192.168.111.200 port:13662
    (а это второй звонок, который почему-то считает, что пришел с самого сервера)
    TRUNK — Preparing audio answer : create audio description! audio format PCMA(8) local address 8X.XXX.XXX.XXX:13656
    и
    TRUNK — Preparing audio answer : create audio description! audio format PCMA(8) local address 192.168.111.200:13662

    Куда копать? Отключить насовсем «белый» интерфейс?

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.