VoIP провайдеры и шлюзы: теоретические основы взаимодействия с 3CX

lj5ebdpjДанная статья рекомендуется всем специалистам, настраивающим 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.

image

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

Если ответ от STUN сервера не приходит, в логе появляется сообщение об ошибке.

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.

image

Из сообщений об успешном ответе STUN сервера, приведенных выше, можно увидеть, что строка Resolved SIP external IP:port содержит правильный внешний IP адрес 3CX сервера, который дополнительно может быть проверен на странице статуса NAT роутера (большинство NAT устройств имеют страницу статуса, на которой, в числе прочего, можно увидеть WAN IP адрес). Если в NAT роутере “проброс” портов настроен корректно, не происходит подмены порта источника (PAT —  Port Address Translation). То есть, когда 3CX связывается со STUN сервером, 3CX передает свой внешний SIP порт 5060, а не какой-либо другой порт, назначенный NAT устройством. Если “проброс” порта 5060 не сделан, существует вероятность того, что NAT устройство подменит порт источника 5060 на другой динамический порт. Таким образом, при прохождении SIP запроса через NAT будет изменен и IP адрес и порт источника. Эта ситуация может привести к различным проблемам со связью. Ниже показан пример такой нежелательной трансляции.

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 сервера.

image

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

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

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

image

Определение IP адреса VoIP провайдера происходит так: сначала 3CX делает запрос специальной SRV записи для SIP сервиса в домене провайдера и если ее не обнаруживает, то делает запрос А записи. Процесс разрешения (DNS resolution) A записи выполняется стандартным образом в пространстве имен DNS. SRV записи, с другой стороны, очень напоминают MX записи для почтовых серверов. Например, если VoIP провайдер назван в консоли 3CX как example.com, 3CX ищет SRV запись _sip._udp.example.com в домене example.com.

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

_sip._udp.example.com. 86400 IN SRV 10 60 5060 bigbox.example.com.
_sip._udp.example.com. 86400 IN SRV 10 20 5060 smallbox1.example.com.

_sip._udp.example.com. 86400 IN SRV 10 10 5060 smallbox2.example.com.

_sip._udp.example.com. 86400 IN SRV 10 10 5066 smallbox2.example.com.

_sip._udp.example.com. 86400 IN SRV 20 0 5060 backupbox.example.com.

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

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

Nslookup -q=srv _sip._udp.3cx.com
Server:  UnKnown
Address:  192.168.0.1

Non-authoritative answer:
_sip._udp.3cx.com       SRV service location:
priority       = 0
weight         = 1
port           = 5060
svr hostname   = sip.3cx.com

sip.3cx.com     internet address = 78.158.130.238

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

Какой сетевой интерфейс использует 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 провайдеры с регистрацией по имени пользователя / паролю.

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

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

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

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

  1. Сервер VoIP провайдера не получил запрос регистрации
  2. Сервер VoIP провайдера не отправил подтверждение регистрации
  3. Подтверждение регистрации по какой-то причине не дошло до 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 авторизации можно узнать из соответствующей литературы.

В конечном счете, в логе 3CX должно появиться сообщение об успешной или неуспешной регистрации на VoIP провайдере.

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) транки

VoIP провайдеры без регистрации, которые также называются SIP (VoIP) транками, не трубуют регистрации со стороны VoIP АТС. Это связано с тем, что IP адрес 3CX сервера явно указывается в настройках VoIP провайдера. Обычно, пользователю предоставляется некий WEB интерфейс, в котором он прописывает IP адрес своего сервера (и другие настройки, если необходимо). Кроме отсутствия регистрации, SIP транк также не требует авторизации. Авторизация не нужна, т.к. VoIP провайдер автоматически доверяет всем вызовам, приходящим с IP адреса сервера (с заданного IP адреса источника – Source IP). При создании SIP транка в консоли 3CX не требуется задавать пароль (в версии 8 пароль и логин могут быть любыми). 3CX не предпринимает никаких попыток регистрации / авторизации VoIP линии – SIP транка. Успешное подключение к VoIP провайдеру “подразумевается” по умолчанию.

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

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

При регистрации на VoIP провайдере, по логину / паролю или IP адресу, провайдер присваивает вашей VoIP линии SIP номер. Этот номер и другую полезную информацию можно увидеть в вашем “личном кабинете” на сайте провайдера. Когда на ваш SIP номер откуда-то извне приходит вызов, провайдер точно знает, куда этот вызов направить. Провайдер направляет на IP адрес вашей АТС 3CX запрос INVITE (“приглашение к разговору”), который можно увидеть в логе 3CX.

INVITE sip:8632606@72.14.207.99:5060;rinstance=7303026702615448 SIP/2.0
Record-Route: <sip:217.10.79.23;lr=on;ftag=as21013b10>

Record-Route: <sip:172.20.40.4;lr=on>

Record-Route: <sip:217.10.79.23;lr=on;ftag=as21013b10>

Via: SIP/2.0/UDP 217.10.79.23:5060;branch=z9hG4bK11d4.8a4bf394.0

Via: SIP/2.0/UDP 172.20.40.4;branch=z9hG4bK11d4.8a4bf394.0

Via: SIP/2.0/UDP 217.10.79.23:5060;received=217.10.68.6;branch=z9hG4bK7d2a0377

Via: SIP/2.0/UDP 217.10.66.71:5060;branch=z9hG4bK7d2a0377;rport=5060

From: “0015552368? <sip: 0015552368@sipgate.co.uk>;tag=as21013b10

To: <sip: 8632606@sipgate.co.uk>

Contact: <sip: 0015552368@217.10.66.71>

Call-ID: 38b34a2512c9c1903d5d5940348c18f4@sipgate.co.uk

CSeq: 102 INVITE

Max-Forwards: 67

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY

Supported: replaces

Content-Type: application/sdp

Content-Length: 446

Рассмотрим процесс идентификации сервером 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.

image

В левой части создаваемого правила выставляются 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.

To: <sip: 00495552368@myexampleprovider.de>

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

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

Заголовок Via в SIP запросе указывает количество хостов (хопов – hops) через которые этот запрос прошел. Последние хосты указываются в верху списка. Ответы на такие SIP запросы отсылаются назад по тому же маршруту, определенному списком хостов. То есть, коммуникации между двумя SIP устройствами всегда проходят по маршруту, указанному в списке “хопов», начиная с верхнего.

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

Заголовок Record Route может быть вставлен одним из транзитных SIP Proxy серверов для того, чтобы этот сервер всегда участвовал в обмене сообщениями между SIP абонентами. Так, заголовок Record Route используется в технологии 3CX SIP Bridge. 3CX SIP Bridge служит для объединения нескольких АТС 3CX в разных офисах с помощью своеобразного VPN туннеля. Благодаря заголовку Record Route, SIP клиент в одном офисе отправляет запросы другому клиенту не напрямую, а через 3CX SIP Bridge, т.е. через серверы 3CX в обоих офисах.

Share