B2BPRO.KZ | Рекламное агентство в Алматы

Параметры SIP для других АТС: порт, домен, исходящий прокси, STUN и шифрование SRTP в приложении для звонков

Обложка: Когда АТС просит больше настроек. Пульт с синими ползунками, смартфон и зеленый замок, настройка SIP-приложения для АТС и Битрикс24

Если софтфон подключается не к Битрикс24, а к Asterisk, FreePBX или облачной АТС оператора, логина, пароля и сервера часто не хватает. Остальное задается в расширенных параметрах SIP: порт и транспорт, SIP-домен, исходящий прокси, имя для авторизации, STUN и ICE для обхода NAT, шифрование звука SRTP. Каждое поле решает свою задачу, и заполнять их нужно только по требованию АТС.

Обычно все начинается так: в компании стоит коробочный Битрикс24 и рядом офисная АТС на Asterisk, которую когда-то настроил подрядчик. Менеджеров решили перевести со стационарных аппаратов на смартфоны, установили SIP-клиент, ввели номер и пароль. В офисе по Wi-Fi все работает, а из дома аккаунт регистрируется, но собеседника не слышно. Или регистрация не проходит вообще, хотя пароль верный. Причина почти всегда в одном из расширенных полей.

Базовую настройку аккаунта (где взять сервер, логин и пароль, как добавить учетную запись и проверить статус) мы подробно описали в инструкции как настроить SIP-аккаунт на Android по шагам. Ниже только то, что понадобится, когда АТС требует особых параметров.

Когда расширенные параметры SIP вообще нужны

Расширенные параметры нужны, когда АТС работает не на стандартных настройках: слушает нестандартный порт, принимает только TCP или TLS, ждет имя для авторизации, отличное от номера, стоит за NAT или требует шифрования звука. Если подключение идет к Битрикс24, эти поля оставляют пустыми.

Так прямо сказано на странице приложения B2BPRO Phone для звонков из Битрикс24: дополнительные поля «нужны, если АТС требует особых параметров, для Битрикс24 оставьте пустыми». Приложение при этом остается обычным SIP-клиентом, и для других АТС в нем есть раздел «Дополнительно» с такими полями:

  • транспорт: UDP (по умолчанию), TCP или TLS;
  • порт (по умолчанию 5060);
  • имя для авторизации;
  • SIP-домен;
  • исходящий прокси;
  • STUN-сервер;
  • ICE (обход NAT);
  • шифровать звук (SRTP).

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

Заполняйте только то, что требует ваша АТС. Лишний STUN-сервер или включенное шифрование, которое станция не поддерживает, ломают звонки так же надежно, как пропущенный параметр.

Транспорт и порт: UDP, TCP или TLS

Транспорт и порт должны совпадать с тем, на чем АТС принимает регистрации. По стандарту SIP (спецификация RFC 3261) порт по умолчанию зависит от транспорта: 5060 для UDP и TCP, 5061 для TLS.

Транспорт SIP — это способ, которым приложение доставляет служебные сообщения (регистрацию, вызов, завершение) до АТС. От него не зависит качество голоса, но зависит, дойдет ли регистрация вообще.

Транспорт Порт по стандарту Когда выбирать
UDP 5060 Вариант по умолчанию, подходит большинству АТС в локальной сети и при прямом подключении
TCP 5060 Если АТС принимает только TCP или UDP режется в сети (часть мобильных и гостевых Wi-Fi)
TLS 5061 Если служебный трафик нужно шифровать, например при регистрации через интернет

Частая ошибка: на АТС порт перенесли с 5060 на другой номер, чтобы меньше было попыток подбора паролей, а в приложении оставили значение по умолчанию. Регистрация висит без ответа, сотрудник думает, что сломан пароль. Нестандартный порт администратор АТС знает всегда, его нужно просто спросить и вписать в поле «Порт».

Вторая ошибка: выбран TLS, а порт оставлен 5060. Для Asterisk это два разных транспорта с разными портами, и на TLS-запрос по UDP-порту станция не ответит. Меняя транспорт, сразу проверяйте порт.

Чем SIP-домен отличается от сервера и исходящего прокси?

Сервер в настройках аккаунта отвечает на вопрос «куда физически отправлять запросы», SIP-домен на вопрос «в какой зоне зарегистрирован номер», а исходящий прокси на вопрос «через какой узел пропускать все запросы». В простых схемах это один и тот же адрес, поэтому дополнительные поля пустые.

SIP-домен — это часть адреса после знака @ в SIP-адресе вида 101@pbx.company.kz. Многие АТС проверяют, что домен в запросе совпадает с тем, что настроен у номера. Если станция принимает регистрацию только на домен, отличный от адреса сервера (например, сервер задан IP-адресом, а номер заведен в домене компании), домен вписывают отдельно.

Исходящий прокси — это узел, которому клиент отправляет все запросы, даже если адрес назначения указывает на другой сервер. Так его определяет RFC 3261: прокси, который получает запросы от клиента, хотя может и не быть сервером, на который указывает адрес вызова. Обычно его задают вручную.

Где это встречается на практике:

  • оператор облачной АТС публикует один адрес для регистрации, но просит пускать трафик через свой пограничный узел;
  • офисная АТС стоит за межсетевым экраном, а снаружи доступен только пограничный SIP-узел (SBC);
  • номер принадлежит одному домену, а обслуживается кластером серверов, и вход в него один.

Если оператор или администратор АТС не называл исходящий прокси, поле оставляют пустым. Адрес сервера, вписанный в поле прокси «на всякий случай», обычно ничего не меняет. Ошибочный адрес ломает регистрацию.

Имя для авторизации: когда логин и номер не совпадают

Имя для авторизации заполняют, когда АТС проверяет пароль по одному имени, а номер в адресе у сотрудника другой. По умолчанию клиент берет для проверки пароля тот же логин, что и в SIP-адресе, и в большинстве АТС это работает.

Расхождение бывает в двух случаях. Первый: в Asterisk у внутреннего номера 101 отдельная учетная запись для проверки пароля с другим именем (в PJSIP это раздел auth, и имя в нем может не совпадать с номером). Второй: оператор выдает «номер» и отдельно «логин для авторизации» или «Auth ID». В обоих случаях номер пишут в поле логина, а имя для проверки пароля в поле «Имя для авторизации».

Признак проблемы: станция отвечает 401 или 403, хотя пароль скопирован без ошибок. Прежде чем менять пароль на АТС, спросите администратора, совпадает ли имя для авторизации с номером.

Как работают STUN и ICE и нужны ли они вашей АТС

STUN и ICE нужны, когда телефон сотрудника и АТС находятся в разных сетях за NAT и звонок соединяется, но звук идет в одну сторону или не идет совсем. Если АТС и телефон в одной офисной сети, оба поля обычно не нужны.

NAT — это механизм роутера, который прячет устройства локальной сети за одним внешним адресом. Служебные сообщения SIP через него проходят, а голос идет отдельным потоком RTP на адрес и порт, которые телефон сам сообщил АТС. Если телефон сообщил свой внутренний адрес вроде 192.168.1.15, АТС отправляет звук туда, где его никто не ждет.

STUN-сервер — это узел, у которого клиент узнает свой внешний адрес и порт. По описанию протокола STUN в RFC 8489, он помогает другим протоколам проходить через NAT: определяет адрес и порт, выделенные устройству за NAT, проверяет связность и поддерживает привязку NAT активной.

ICE — это процедура, которая перебирает возможные пути для голоса (локальный адрес, внешний адрес из STUN, при наличии ретранслятор TURN) и выбирает рабочий. По стандарту ICE в RFC 8445, она предназначена для обхода NAT при передаче по UDP и использует STUN и его расширение TURN.

ICE должна поддерживать и АТС, об этом часто забывают. Если включить ICE только в приложении, а станция о ней не знает, выигрыша не будет. В Asterisk за это отвечает параметр ice_support у endpoint, по документации он выключен по умолчанию. Включать ICE в приложении имеет смысл только после того, как администратор подтвердил, что АТС ее поддерживает.

Во многих случаях проблему NAT решают на стороне АТС, без STUN на телефоне. В руководстве Asterisk по работе PJSIP через NAT для удаленных телефонов за NAT описаны параметры rtp_symmetric, force_rport, rewrite_contact и direct_media. Смысл у них общий: АТС отправляет ответы и звук туда, откуда пришел пакет, а не туда, куда указал телефон. Если эти параметры настроены, телефону часто хватает базовых полей.

На практике сначала администратор проверяет NAT-настройки endpoint на АТС, затем, если звук все еще в одну сторону, в приложении указывают STUN-сервер, и только после подтверждения поддержки со стороны АТС включают ICE.

Как включить шифрование SRTP и не потерять звук

Шифрование звука SRTP включают, только если АТС настроена принимать шифрованный голос; при несовпадении настроек звонок обрывается или идет без звука. SRTP защищает сам разговор от прослушивания в сети, через которую идет звонок.

SRTP — это защищенный вариант протокола передачи голоса RTP. По спецификации SRTP в RFC 3711, он обеспечивает конфиденциальность, проверку подлинности сообщений и защиту от повторной отправки для голосового трафика и его служебного канала RTCP.

В Asterisk шифрование голоса задает параметр media_encryption у endpoint: по документации он определяет, будет ли станция использовать и требовать шифрования медиа для этого номера. Есть и мягкий режим media_encryption_optimistic, при котором шифрование используется, если получилось договориться, а звонок не обрывается, если нет.

Порядок включения:

  1. Уточните у администратора АТС, включено ли шифрование медиа на endpoint сотрудника и обязательно ли оно.
  2. Если шифрование обязательно, включите в приложении «Шифровать звук (SRTP)». Без этого станция откажет в вызове.
  3. Если на АТС шифрование выключено, оставьте переключатель выключенным.
  4. Сделайте тестовые звонки в обе стороны и убедитесь, что слышно обоих собеседников.

Шифрование голоса и транспорт TLS решают разные задачи: TLS защищает служебные сообщения, SRTP защищает разговор. Ключи для шифрования голоса в распространенных схемах передаются внутри служебных сообщений, поэтому SRTP обычно используют вместе с TLS. Конкретную схему для вашей станции лучше согласовать с тем, кто ее обслуживает.

Порядок настройки для Asterisk и других АТС

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

  1. Получите у администратора АТС полный список: адрес сервера, порт, транспорт, номер, имя для авторизации, домен, исходящий прокси, нужен ли STUN, поддерживает ли станция ICE, обязательно ли шифрование.
  2. Введите сервер, логин и пароль и проверьте регистрацию в офисной сети. Если она прошла, базовые данные верны.
  3. Задайте транспорт и порт, если они отличаются от UDP и 5060. Проверьте регистрацию снова.
  4. Добавьте имя для авторизации, домен и исходящий прокси, если АТС их требует.
  5. Переключите телефон на мобильный интернет и позвоните. Если звук в одну сторону, это NAT: попросите администратора проверить NAT-настройки endpoint, затем при необходимости укажите STUN-сервер.
  6. Включайте ICE и SRTP последними и только по подтверждению со стороны АТС.
  7. Когда все работает, перенесите параметры в QR-код и раздайте его сотрудникам.

На проектах B2BPRO.KZ мы чаще всего видим, что звонки ломает не один неверный параметр, а сочетание двух: например, сменили транспорт на TCP, а на АТС TCP не включен, или включили шифрование в приложении, а станция его не ждет. Пошаговая проверка такие сочетания отлавливает быстро.

Какой параметр проверять по симптому

Большинство сбоев с другими АТС узнаются по симптому, и каждому соответствуют одна-две группы параметров.

Симптом Что проверить в первую очередь
Регистрация висит без ответа Порт и транспорт, адрес исходящего прокси
Ответ 401 или 403 при верном пароле Имя для авторизации, SIP-домен
Регистрация проходит в офисе, но не из дома Доступность АТС снаружи, транспорт (TCP вместо UDP)
Звонок соединяется, звук в одну сторону NAT-настройки endpoint на АТС, затем STUN
Звонок обрывается сразу после ответа Совпадение настроек SRTP на АТС и в приложении
Через 30-60 секунд пропадает звук или связь Таймауты NAT на роутере и NAT-настройки АТС

Если входящие не приходят, когда экран телефона погашен, расширенные параметры SIP обычно ни при чем: это вопрос работы приложения в фоне и оптимизации батареи Android, и решается он в настройках телефона.

Коробочный Битрикс24 и офисная АТС: как связать звонки с CRM

Чтобы звонки с офисной АТС попадали в карточки клиентов, АТС подключают к Битрикс24, а софтфон сотрудника регистрируется на самой АТС. В этой схеме расширенные параметры SIP задаются для станции, и ровно для нее они и нужны.

Схема с коробочной версией встречается у компаний, которые держат CRM и телефонию на своих серверах. По справке Битрикс24 о выборе и подключении SIP АТС, для подключения офисной АТС ей нужен публичный IP-адрес, чтобы серверы телефонии могли с ней связаться. Отсюда и NAT, и исходящие прокси, и вопросы шифрования: станция смотрит в интернет, а сотрудники звонят из разных сетей.

Связка состоит из трех частей: АТС с ее NAT-параметрами, подключение АТС к порталу и телефоны сотрудников. Если хоть одна часть собрана «как получилось», руководитель видит в CRM не все звонки, а менеджеры жалуются на тишину в трубке. Если нужно разобраться со всей цепочкой разом, посмотрите наши услуги по внедрению и настройке Битрикс24: телефонию подключаем вместе с CRM.

Для самих телефонов можно использовать любой SIP-клиент, который поддерживает нужные параметры: Linphone, Zoiper, MicroSIP на компьютере и другие. B2BPRO Phone построен на Linphone SDK и подходит, если сотрудники работают по сменам с одного Android-смартфона или вы хотите раздавать настройки QR-кодом. Набирать в нем можно и номера, и полные SIP-адреса, а если указать название компании, тексты в приложении становятся нейтральными и не упоминают Битрикс24. Работу с другими АТС мы проверяем на конкретных примерах: если нужна проверка вашей станции, напишите нам. Клиентам техподдержки Битрикс24 от B2BPRO.KZ приложение бесплатно, остальным доступен пробный период 14 дней, затем подписка по ключу. Подробности на странице SIP-телефона для Битрикс24 на Android.

Пример: перевод отдела продаж с офисных аппаратов на смартфоны

Это иллюстрация, а не описание конкретного клиента. В компании коробочный Битрикс24 и Asterisk на своем сервере, восемь менеджеров. Станция доступна из интернета по TLS на порту 5061, внутри сети работает UDP на 5060. У номеров в PJSIP отдельные записи auth с именами, не совпадающими с номерами.

Администратор начинает с офиса: вводит сервер, номер и пароль, выбирает TLS и порт 5061, добавляет имя для авторизации. Регистрация проходит. Затем телефон переключают на мобильный интернет: звонок соединяется, но клиент не слышит менеджера. На АТС у endpoint включают rtp_symmetric, force_rport и rewrite_contact, после чего звук идет в обе стороны без STUN на телефоне.

Шифрование голоса на станции включено обязательным, поэтому в приложении включают SRTP и проверяют звонок еще раз. Когда первый телефон работает во всех сетях, администратор переносит параметры в генератор QR-кода и делает коды для остальных семи номеров. Сотрудникам остается отсканировать код и разрешить работу в фоне.

Поскольку параметры включали по одному, после каждого шага было видно, что изменилось. Искать причину «нет звука» вслепую не пришлось.

Частые вопросы

Нужно ли заполнять расширенные параметры SIP для Битрикс24?

Нет, для подключения к Битрикс24 расширенные поля оставляют пустыми. Достаточно сервера, логина и пароля из раздела «Телефония» → «Пользователи». Порт, домен, прокси, STUN и шифрование заполняют только для других АТС и провайдеров, если станция требует особых параметров.

Какой порт указывать для SIP через TLS?

По стандарту SIP для TLS используется порт 5061, а для UDP и TCP порт 5060. Но администратор может перенести SIP на другой порт, поэтому точное значение лучше уточнить у того, кто обслуживает АТС. При смене транспорта всегда проверяйте и порт: TLS-запрос на UDP-порт станция не примет.

Почему звонок соединяется, но собеседника не слышно?

Чаще всего так проявляется NAT: служебные сообщения доходят, а голос уходит на внутренний адрес телефона. Сначала проверьте NAT-настройки номера на АТС, в Asterisk это rtp_symmetric, force_rport и rewrite_contact. Если не помогло, укажите в приложении STUN-сервер. ICE включайте, только если ее поддерживает станция.

Можно ли включить SRTP, если АТС не поддерживает шифрование?

Нет, включенное в приложении шифрование при выключенном шифровании на АТС обычно ведет к обрыву звонка или звонку без звука. Настройки SRTP на станции и в приложении должны совпадать. Если шифрование нужно, его сначала включает администратор АТС, а затем переключатель включают в приложении.

Можно ли передать расширенные параметры сотруднику через QR-код?

Да, в генераторе QR-кода на странице B2BPRO Phone есть блок «Другие АТС и провайдеры» с полями порта, имени для авторизации, домена, исходящего прокси, STUN, ICE и SRTP. Администратор заполняет их один раз, сотрудник сканирует код, и параметры встают сами. Код содержит пароль, поэтому передавайте его лично.

Техподдержка Битрикс24

Телефоны не регистрируются на офисной АТС или пропадает звук?

Проверим порт, транспорт, NAT и шифрование на АТС и в приложениях сотрудников, а затем подключение станции к Битрикс24. Линия поддержки работает круглосуточно.

Написать в поддержку

Прокрутить вверх