Voip какой порт использует

Обновлено: 02.07.2024

Ваше сетевое оборудование может блокировать порты, необходимые для работы телефонии. Убедитесь, что следующие порты открыты:

Как правило, проверку технических требований может произвести системный администратор вашей компании.

Проблема VoIP с симметричным NAT (Symmetric NAT)

При использовании симметричного NAT, пограничное сетевое устройство динамически изменяет номер порта, на который принимается аудиопоток. Например, при исходящем вызове через SIP-транк оператора, 3CX сперва делает STUN-запрос для определения своего внешнего IP-адреса и текущего номера порта. Затем этот адрес и порт передаются SIP-серверу оператора для взаимных коммуникаций. Но в это время ваш сетевой экран динамически закрывает этот порт (который уже был передан оператору — указан в заголовке INVITE). Возникает сбой передачи аудио. Очевидно, что из-за этой особенности невозможно обеспечить надежную работу VoIP. В руководствах по настройке сетевых экранов такая технология называется симметричный NAT (Symmetric NAT).

Решение проблемы с односторонней слышимостью в VoIP — Full Cone NAT

Для решения проблемы с односторонней слышимостью (или полной «тишиной») следует настроить так называемый конический NAT (Full Cone NAT), который также известен как NAT «один-в-один». В нем нужные порты на внешнем адресе маршрутизатора маппируются (или «пробрасываются») на определенный внутренний адрес (номер порта сохраняется). Внешний хост обменивается RTP-пакетами с внутренним хостом, отправляя их сперва на внешний адрес маршрутизатора и внешний (маппированный) порт.

На самом деле, подавляющее большинство сетевых устройств поддерживают этот режим. Как правило, он называется «Static port mapping». Статическая публикация гарантирует, что определенный порт всегда остается открытым и никогда не изменяется сетевым экраном. Некоторые очень дешёвые маршрутизаторы некорректно реализуют эту функцию, но большинство, как было сказано, позволяют нормально настроить «проброс» портов. В конце статьи приводятся примеры соответствующей настройки различных сетевых устройств.

Проверка корректности работы сетевого экрана сервисом 3CX Firewall Checker

Хороший способ проверки конфигурации сетевого устройства (выяснения, не находитесь ли вы за Symmetric NAT и других проблем с настройкой) — использование сервиса 3CX Firewall Checker.

3CX Firewall Checker позволяет заранее проверить, что ваше пограничное сетевое устройство корректно обрабатывает VoIP-трафик от SIP-операторов, мостов 3CX, внешних SIP-клиентов и подключений по технологии 3CX Tunnel. Рассмотрим на простом примере, как использовать этот сервис. Для примера примем, что сервер 3CX имеет адрес 192.168.0.100, тестирование проводится на порту 9500, а внешний адрес вашей сети 11.22.33.44.

Как было сказано, корректная публикация порта означает, что любой исходящий пакет UDP от сервера АТС с адресом источника source IP::Port — 192.168.0.100::9500 должен дойти до получателя (обычно это SIP-сервер оператора связи, удаленный IP-телефон или другая АТС 3CX) с «переписанным» адресом источника source IP::Port — 11.22.33.44::9500. Несмотря на то, что происходит трансляция адреса (которая необходима для маршрутизации пакета в публичной сети WAN), порт пакета не изменяется. Кроме того, любой UDP пакет, приходящий из WAN, с адресом получателя destination IP::Port — 11.22.33.44::9500 должен достигнуть сервер 3CX с адресом destination IP::Port — 192.168.0.100::9500. 3CX Firewall Checker как раз и используется для проверки корректного преобразования адресов, а также выясняет другую важную.

Для запуска 3CX Firewall Checker зайдите в интерфейс управления 3CX > раздел Главная > секция Состояние АТС > нажмите Сетевой экран > Запустить.

После запуска начнется выполнение сетевых тестов. В зависимости от типа пограничного устройства и фактической конфигурации, вы увидите результат вместе с рекомендациями по устранению проблем.

Внимание: Запуск 3CX Firewall Checker останавливает некоторые сервисы 3CX, поэтому в период тестов АТС будет недоступна. Если тестирование порта прошло успешно, оно занимает 1 сек. Неуспешное тестирование порта растягивается на 5-10 сек. По умолчанию, тестируются порты в диапазоне 9000 – 10999. Если изначально все настроено корректно, тестирование займет не более минуты. Если возникнут проблемы — тестирование затягивается на 4-9 мин. Однако в любой момент можно остановить тест.

Сервис использует STUN-сервер компании 3CX, который должен быть установлен в разделе Параметры > Сеть > Публичный IP. Некоторые сетевые экраны эту проверку могут ошибочно квалифицировать как сканирование портов. Если это происходит, 3CX Firewall Checker сообщает о проблеме в самом начале тестирования. Поэтому в сетевом экране следует отключить проверку на сканирование перед началом тестирования.

Тесты 3CX Firewall Checker

Утилита проверяет корректность настройки оборудования, делая различные запросы к STUN-серверам. Проводятся два теста.

Доступность Интернет

Этот тест проверяет доступность серверов STUN с проверяемых портов сервера 3CX. Также проверяется работа DNS (STUN-серверы в 3CX указаны по FQDN).

Если этот тест не пройден, возможны следующие проблемы:

Общая проблема доступа в Интернет. Если на сервере установлен браузер, попробуйте просто зайти на какой-то сайт. Возможно, вам нужно открыть доступ с сервера АТС в интернет по портам, указанных в этом руководстве.
Тест может не пройти, если STUN-сервер недоступен. Проверьте настройки в разделе Параметры > Сеть > Публичный IP или используйте резервный сервер.
Проверьте, какой порт указан для STUN (по умолчанию 3478)
Убедитесь, что сетевой экран на самом сервере 3CX, например брандмауэр Windows, разрешает подключение на тестируемые порты. Антивирусы или другие программы безопасности также могут блокировать порты. Отключите или даже полностью удалите их с сервера на время тестирования (простое отключение не всегда помогает).
Блокировать порты могут также на стороне вашего интернет-оператора — стоит исключить эту возможность.

Корректность публикации портов (Full Cone NAT)

Этот тест проверяет способность сервера, находящегося в Интернет, коммуницировать с сервером 3CX во внутренней сети. Тестируется настройка трансляции портов «один в один» (Full Cone NAT).

3CX Firewall Checker отправляет запрос на STUN-сервер с (номера) порта, который проверяется, и запрашивает STUN-сервер создать соединение с сервером АТС по этому порту с внешнего IP-адреса. Если второй тест не прошел, проверьте следующие настройки:

Ваш сетевой экран должен иметь статическое правило публикации портов «один в один». Недорогие устройства, как правило, предлагают только такой тип правил.
Для некоторых портов требуется правило как для TCP, так и для UDP трафика. См. список портов, необходимых для работы 3CX.

Перечислим результаты теста и ошибки, которые возвращает Firewall Checker.

Success – Port forwarding is correctly implemented for this port. VoIP can work. This configuration is supported (Успех — публикация порта выполнена корректно. VoIP-коммуникации будут работать. Данная конфигурация поддерживается 3CX).

Все тесты успешно пройдены. Ваше пограничное устройство разрешает трафик в интернет с тестируемого порта и корректно выполняет преобразование портов один в один. Конфигурация поддерживается.

STUN server has no second address (STUN-сервер не имеет второго адреса).

Failed – No response received or port mapping is closed. Port forwarding not configured correctly (Неуспешно — ответ не получен или порт закрыт. Некорректная настройка публикации порта).

Некорректно настроена публикация проверяемого порта. В этом случае VoIP-операторы и удаленные IP-телефоны не будут работать. Настройте публикацию портов по этим руководствам.

Failed – Firewall check failed. Some errors were detected. Please check your firewall configuration and try the test again (Неуспешно — проверка сетевого экрана не удалась. Обнаружены ошибки. Проверьте конфигурацию сетевого экрана и попробуйте снова).

Failed – Malformed response received – (aka Symmetric NAT). Port forwarding not correctly implemented (Неуспешно — получен некорректный ответ (возможно, симметричный NAT). Некорректно настроена публикация портов).

Ответ говорит о том, что у вас некорректно работает Full Cone NAT.

STUN server did not answer or port forwarding is not configured on your firewall (STUN-сервер не ответил или не настроена публикация портов на сетевом экране).

Ваш STUN-сервер не отвечает. Возможные причины:

STUN-сервер недоступен с сервера 3CX.
STUN-сервер в данный момент отключен.
Не настроена публикация портов.

Не удалось определить IP-адрес STUN-сервера по его имени. Это может говорить о проблемах с вашим DNS-сервером, но также и о том, что данный STUN-сервер навсегда прекратил работу.

Failed – Malformed or no response received from configured STUN servers. Check your internet connection, DNS settings, or change STUN servers from Settings → Network → External IP Configuration section (Неуспешно — получен некорректный ответ от настроенных STUN-серверов. Проверьте подключение к Интернет, настройки DNS или используйте другой STUN в разделе Параметры → Сеть → Внешний IP).

Ответ говорит, что публикация портов выполнена корректно или ваш сетевой экран блокирует пакеты.

Failed – Port is in use by another application on this computer ИЛИ SIP port is in use by process . The 3CX Firewall checker requires the SIP port to be free (Неуспешно — порт используется другим приложением на этом сервере ИЛИ SIP-порт используется процессом . Сервису 3CX Firewall checker необходим свободный порт SIP.

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

netstat -ano | findstr /I /C:"PID" /C:":9500"

где 9500 — номер порта. В колонке PID вы увидите ID процесса. Используете Диспетчер задач для идентификации процесса. Также можно выполнить команду

tasklist /fi "pid eq 4"

где 4 — ID процесса.

STUN servers are not reachable. Cannot perform Firewall check. This configuration is not supported (STUN-серверы недоступны. Невозможно выполнить проверку сетевого экрана. Конфигурация не поддерживается).

Если вы планируете подключение к VoIP-провайдеру или используете удаленные добавочные номера (которые подключаются к АТС через Интернет), потребуется настройка сетевого экрана. Она необходима для корректного прохождения VoIP-трафика между Интернетом и локальной сетью организации. В этой главе рассматриваются общие вопросы настройки маршрутизаторов и сетевых экранов для работы с 3CX. Для вашего удобства мы подготовили подробные инструкции по настройке для популярных маршрутизаторов. Рекомендуется ознакомиться с подробным описанием работы маршрутизаторов и сетевых экранов с VoIP-трафиком .

Настройка портов для SIP-транка / VoIP-провайдера

Для работы 3CX с SIP-транками / VoIP-провайдерами и использования технологии WebRTC, создайте в сетевом экране статические правила публикации следующих портов:

Порт 5060 (на вход, UDP) и 5060-5061 (на вход, TCP) для SIP-трафика
Порт 9000-10999 (на вход, UDP) для RTP (Audio) трафика, который передает голос. Каждый вызов использует два RTP порта: один для управления, другой для передачи данных. Это значит, что на каждый одновременных вызов, который примет 3CX, вы должны открыть два порта (т.е. портов должно быть вдвое больше, чем вызовов).

Настройка портов для удаленных приложений 3CX

Для подключения удаленных приложений 3CX для Android, iOS, Mac и Windows, опубликуйте следующие порты:

Настройка портов для удаленных IP-телефонов / мостов 3CX при подключений Direct SIP

Для удаленных IP-телефонов и межстанционных транках 3CX существует два вида подключений: 3CX SBC (Tunnel) или Direct SIP (прямое SIP-подключение). Сервис 3CX SBC (Session Border Controller) объединяет VoIP трафик от всех удаленных устройств в один зашифрованный канал передачи данных. Это значительно упрощает настройку сетевых экранов и повышает надежность связи. 3CX SBC не требует дополнительной настройки сетевого экрана, поскольку использует те же порты, которые используют приложения 3CX. Подробнее о 3CX SBC можно узнать здесь .

При подключении удаленных устройств (добавочных номеров) непосредственно по SIP через Интернет (Direct SIP), необходимо открыть ряд портов на сетевом экране (большинство этих портов совпадают с портами, которые вы уже открыли при подключении SIP транков от операторов связи):

Настройка портов для видеоконференций 3CX

Чтобы пользователи могли создавать или участвовать в видеоконференциях, облачный сервис видеоконференций 3CX и локальная АТС 3CX должны обмениваться данными. Для этого необходимо открыть следующие порты:

Порт 443 (на вход, TCP) должен быть открыт, чтобы участники могли подключиться к вашей системе 3CX.
Система 3CX. Порт 443 (на выход, TCP) должен быть открыт, чтобы подключаться к облачной инфраструктуре видеоконференций 3CX.
Участники конференции. Порты 443 (на выход, TCP) и 48000-65535 (на выход, UDP) должны быть открыты для обмена аудио- и видеоданными между участниками.

Другие сервисы (SMTP и сервер активации)

Также сервер АТС подключается к некоторым вспомогательным облачным сервисам 3CX:

Отключение SIP ALG

Для использования с 3CX выбирайте сетевой экран без сервиса SIP ALG (Application Layer Gateway) / SIP Helper или с возможностью его отключения. Ниже приведены руководства по отключению SIP ALG в распространенных маршрутизаторах:

Запуск утилиты Firewall Checker

После публикации портов проверьте корректность настройки сетевого экрана с помощью утилиты 3CX Firewall Checker !

Подробные инструкции по настройке для распространенных сетевых экранов

Руководства по публикации портов 3CX в популярных маршрутизаторах / сетевых экранах:

Данная статья рекомендуется всем специалистам, настраивающим 3CX Phone System для работы с различными VoIP провайдерами и голосовыми шлюзами. Она рассматривает важные аспекты, на которые следует обратить внимание в процессе настройки:

конфигурация NAT
работа STUN сервера
работа DNS сервера в VoIP сети
особенности конфигурации для различных топологий сети
различные типы VoIP провайдеров
идентификация источника (Source Identification) при работе с VoIP провайдером или шлюзом
заголовки Via и Record Route

Конфигурация NAT

Начиная настройку 3CX для работы с любым VoIP провайдером, прежде всего следует обратить внимание на корректную публикацию (или “проброс”) портов на вашем NAT роутере. В стандартной схеме подключения, которая присутствует в большинстве компаний, 3CX работает в сети за одним NAT роутером. NAT роутер должен уметь корректно “пробросить” нужные пакеты на 3CX сервер из сети Интернет. Пробрасывать нужно UDP пакеты протоколов SIP (сигнализацию вызова) и RTP (голосовой поток). Если 3CX настроена на стандартный SIP порт 5060, то NAT должен “пробрасывать” UDP порт 5060. Для голосовых данных, по умолчанию, следует пробросить порты 9000-9049. Эти порты устанавливаются в разделе Settings > Network в консоли 3CX.

C другой стороны, 3CX сервер также должен иметь возможность отсылать запросы в Интернет:

порт 5060 (источника и получателя) – SIP сигнализация
порты 9000-9049 (источника) – отправка RTP данных
порт 3478 (получателя) – отправка STUN запросов

Как правило, в начале настройки рекомендуется открыть все порты “на исход” с сервера 3CX во избежание лишних проблем.

Работа STUN сервера

Для нормального прохождения сигнальных и голосовых данных через NAT, 3CX сервер должен иметь информацию о своем внешнем IP адресе (на внешнем интерфейсе NAT роутера) и типе NAT роутера. Эта информация необходима 3CX для того, чтобы “понять”, как он выглядит со стороны сервера VoIP провайдера. Получение 3CX сервером такой информации обеспечивается благодаря внешнему STUN серверу. Записи об успешном STUN разрешении появляются в логе 3CX сразу после старта системы и выглядят следующим образом.

14:40:27.703 StunClient::process [CM506002]: Resolved SIP external IP:port (64.233.167.99:5060) on Transport 192.168.0.1:5060
14:40:27.265 StunClient::onInitTests [CM506001]: STUN request to resolve SIP external IP:port mapping is sent to STUN server 64.69.76.23:3478 over Transport 192.168.0.1:5060

11:14:38.687 StunClient::onTestTout [CM506004]: STUN request to STUN server 64.69.76.23 has timed out; used Transport: 10.172.0.132:5060

Внимание! В некоторых случаях следует отключать STUN сервер в 3CX. Например, в том случае, если 3CX имеет “белый” IP адрес и NAT не используется. Подробнее о том, когда следует отключать STUN можно прочитать здесь. Для отключения STUN сервера, удалите его из раздела Settings > Network > STUN в консоли 3CX.

14:40:27.703 StunClient::process [CM506002]: Resolved SIP external IP:port (64.233.167.99:24842) on Transport 192.168.0.1:5060
14:40:27.265 StunClient::onInitTests [CM506001]: STUN request to resolve SIP external IP:port mapping is sent to STUN server 64.69.76.23:3478 over Transport 192.168.0.1:5060

Внимание! Работа с VoIP провайдером без “проброса” порта 5060 также возможна. Тем не менее, из-за не всегда высокого качества реализации NAT у того или иного производителя, возможны проблемы с прохождением VoIP трафика. Поэтому конфигурация без проброса порта не рекомендуется, хотя и допустима.

Полученный, благодаря STUN серверу, внешний IP адрес и порт используется системой 3CX для связи с VoIP провайдером. Если ваш внешний IP часто меняется (динамический IP адрес) – весьма вероятны перебои в голосовых коммуникациях. Поэтому использование динамического IP крайне нежелательно. Если этого нельзя избежать, уменьшите параметр Query STUN server every (sec) в опциях STUN сервера.

Изменение внешнего IP адреса можно увидеть на странице статуса вашего NAT устройства, либо в логе сервера 3CX.

Работа DNS сервера в VoIP сети

Для успешной связи с VoIP провайдером, 3CX сервер должен определить его IP адрес по FQDN имени, указанном в настройках этого провайдера в консоли 3CX (если IP адрес провайдера не указан явным образом).

В ответ может быть получены как одна A запись SIP сервера, так и список А записей, упорядоченных по приоритету (точно так же, как в MX записи).

Получив набор A записей SIP серверов, 3CX пытается подключиться к первому серверу (с наименьшим приоритетом), предварительно получив его IP адрес стандартным способом.

Совет. Чтобы вручную получить список SIP серверов для данного домена, используйте команду Nslookup с ключами.

Особенности конфигурации для различных топологий сети

Какой сетевой интерфейс использует 3CX для отправки SIP запросов? 3CX использует таблицу маршрутизации Windows для отправки SIP запросов. Таким образом, если на сервере установлено несколько сетевых адаптеров, следует правильно настроить локальную таблицу маршрутизации. Получить ее можно с помощью команды route print.

Как 3CX определяет локальные и внешние подсети (устройства)? По умолчанию, 3CX считает все подсети (и устройства в них) локальными, если они соответствуют RFC 3330: 10.0.0.0/8,169.254.0.0/16,172.16.0.0/12,192.168.0.0/16

Если у вас имеются дополнительные подсети, которые должны восприниматься 3CX как локальные, укажите их в файле 3CXPhoneSystem.ini в разделе [Network], параметр localSubnets. Тут укажите список подсетей, разделенный запятой, в формате a.b.c.d/maskLen. Обратите внимание, что следует перечислить все локальные подсети, включая и сети по RFC 3330!

Пример файла 3CXPhoneSystem.ini по умолчанию:

[Network]
localSubnets=
; IP will be treated as local only if it is directly accessible (residing in the same network as PBX host).

Пример модифицированного файла 3CXPhoneSystem.ini:

[Network]
localSubnets=172.99.95.0/24,45.23.68.0/24
; IP will be treated as local if it is directly accessible (IP Address in same subnet as PBX)
; or has IP in range 172.99.95.0/24 or 45.23.68.0/24

Различные типы VoIP провайдеров

1. VoIP провайдеры с регистрацией по имени пользователя / паролю.

Перед регистрацией 3CX обращается к STUN серверу, и если ответ STUN не будет получен, попыток регистрации не делается. В случае, если ответ STUN получен, начинается процесс регистрации VoIP линии на VoIP провайдере:

12:35:31.675 ClientRegs::Register [CM504003]: Sent registration request for 10000@sipgate

Если ответа на запрос REGISTER не поступает, возможны три ситуации:

Сервер VoIP провайдера не получил запрос регистрации
Сервер VoIP провайдера не отправил подтверждение регистрации
Подтверждение регистрации по какой-то причине не дошло до 3CX

В таком случае рекомендуется проверить следующее:

Работает ли STUN разрешение? Проверьте взаимодействие 3CX со STUN в Server Activity Log.
Запрос REGISTER должен выглядеть следующим образом: адрес хоста (Host Part) в заголовке Contact (Contact Header) SIP URI должно содержать внешний (публичный) IP адрес и порт вашего NAT роутера.
“Проброс” портов на вашем NAT роутере должен быть выполнен корректно.

Обычно, на запрос REGISTER VoIP провайдер отвечает запросом авторизации (407 Proxy Authentication Required). В ответ 3CX отсылает новый запрос REGISTER, который включает Proxy-Authorization Header и Call Sequence Header. VoIP провайдер сравнивает хеш, полученный от 3CX со своим хешем, и, если они совпадают, авторизует 3CX VoIP линию. Подробнее о SIP авторизации можно узнать из соответствующей литературы.

13:40:08.953 ClientRegs::onFailure [CM504005]: Registration failed for: 10000@sipgate
13:41:53.328 ClientRegs::onSuccess [CM504004]: Registration succeeded for: 10000@sipgate

Если регистрации неуспешна, причина скорее всего кроется в несовпадении логина и пароля в консоли 3CX с этими данными у VoIP провайдера. Попробуйте напрямую подключиться к провайдеру обычным программный IP телефоном, например, 3CX Phone.

2. VoIP провайдеры без регистрации (или с регистрацией по IP адресу) – SIP (VoIP) транки

13:41:53.328 ClientRegs::onSuccess [CM504004]: Registration succeeded for: user@siptrunkprovider

Идентификация источника (Source Identification) при работе с VoIP провайдером

Рассмотрим процесс идентификации сервером 3CX запроса INVITE.

1. Идентификация источника по умолчанию

Когда АТС 3CX получает запрос INVITE, она пытается идентифицировать источник этого запроса. Идентификация источника необходима для того, чтобы выяснить, корректен ли запрос в целом и из разрешенного ли он домена. По умолчанию 3CX проверяет User Part в заголовке Request Line запроса INVITE на соответствие Authentication ID, указанному в настройках VoIP линии в 3CX. Только после прохождения этой начальной проверки 3CX продолжает обрабатывать запрос в соответствии с входящими правилами, указанными для этой линии. Для примера, рассмотрим процедуру идентификации источника так, как она происходит по умолчанию. Положим, VoIP линия настроена в 3CX следующим образом:

External Number : 415551234
Authentication ID : 8632606
Authentication Pass : $ecret_W0rd

Request Line в запросе INVITE от этого провайдера выглядит следующим образом:

INVITE sip:8632606@72.14.207.99:5060;rinstance=7303026702615448 SIP/2.0

В этом запросе User Part имеет значение 8632606. Это значение соответствует значению Authentication ID 8632606 в настройках VoIP линии в 3CX.

Итак, по умолчанию 3CX использует следующие правила идентификации источника:

1. Для PSTN провайдеров должны совпадать следующие поля:

LineID в заголовке Contact ИЛИ User Part в заголовке Request Line
Gateway host/port в заголовке Contact

2. Для VoIP провайдеров должны совпадать следующие поля:

AuthID в заголовке Contact ИЛИ User Part в заголовке Request Line
External number в заголовке To ИЛИ User Part в заголовке Request Line

2. Идентификация источника, установленная пользователем

К сожалению, не все VoIP провайдеры отправляют запрос INVITE в строгом соответствии со стандартом SIP (в поле Request Line). Для таких провайдеров 3CX предусматривает ручную настройку правил (полей) идентификации источника в свойствах шлюза или VoIP провайдера в консоли 3CX.

В левой части создаваемого правила выставляются SIP поля (заголовки), а в правой – значения, с которыми эти поля следует сравнивать. Если SIP поле соответствует полученному значению (из запроса INVITE провайдера), идентификация источника (т. е. провайдера) считается успешной и 3CX продолжает обработку вызова. Можно указать несколько правил соответствия и сравнивать их по принципу ИЛИ (Match any fields) или И (Match all fields). Если используется принцип И, то несовпадение хотя бы одного правила в списке приведет к отказу идентификации источника. Такие отказы можно увидеть и проанализировать в логе событий 3CX сервера.

Для успешного создания правил идентификации вручную следует проанализировать запрос INVITE от провайдера и выяснить, какие поля этого запроса постоянны, то есть не изменяются от вызова к вызову и однозначно могут идентифицировать провайдера или шлюз. Можно порекомендовать использовать следующие поля:

Authentication ID
External number (DID)
домен или IP адрес VoIP провайдера, если провайдер использует единственный IP адрес для своего SIP сервера

Request Line URI: User Part сравнивается с LineNumber external number of line. Такое правило работает, если VoIP провайдер вставляет DID номер или внешний номер VoIP линии в поле (заголовок) Request Line вместо поля Authentication VoIP аккаунта, как того требует SIP стандарт.

IDINVITE sip: 0015552368@ 72.14.207.99:5060;rinstance=800f2f60c40d1d10 SIP/2.0

TO: User Part сравнивается с LineNumber external number of line. Такое правило работает, если VoIP провайдер вставляет внешний номер VoIP линии (т.е. 0015552368) в User Part заголовка To в запросе INVITE.

From: Host Part сравнивается с GWHostPort gateway/provider host/port. Такое правило сравнивает IP адрес и порт SIP сервера провайдера, указанные в 3CX, с Host Part заголовка SIP URI в запросе INVITE от VoIP провайдера.

Заголовки Via и Record Route

Заголовок Record Route выполняет ту же функцию, что и заголовок Via, но с некоторыми отличиями. Via, как было сказано, указывает по какому маршруту отсылать ответы на SIP запросы. Заголовок Record Route, наоборот, указывает, по какому маршруту направлять новые SIP запросы. То есть, хост A указывает хосту B маршрут, по которому хост В должен отправлять новые запросы для хоста А.

Читайте также:

Voip какой порт использует

Рекомендации

Выбор оператора связи

Список рекомендуемых операторов связи

Выбор оборудования

Выбор маршрутизатора

Выбор устройства для звонков

Дополнительные параметры для настройки программных и аппаратных телефонов

Выбор браузера

Выбор гарнитуры

Почему не рекомендуем использовать аналоговые гарнитуры?