Привет! Решил поделиться инструкцией по использованию UniFi Talk с провайдером A&A (Andrews & Arnold) в Великобритании, так как знаю, что это популярный VoIP-провайдер для тех, кто уходит с обычных домашних телефонных линий.
Во-первых, следуя этому руководству, вы получите правильные поля и инструкции по настройке, теперь редактировать sip_from_uri не нужно, можно этот пункт игнорировать:
Следующая загвоздка — если при создании провайдера в UniFi Talk вы используете амперсанд (&) в названии провайдера (как это естественно для A&A), UniFi приложение примет это без проблем. Но UniFi Talk при этом никогда не регистрируется у провайдера. Проверяя логи, я обнаружил, что вся конфигурация игнорировалась базовым приложением FreeSWITCH, которое работает с Talk, из-за некорректного имени. Удаление амперсанда из названия решило проблему.
Теперь вы должны принимать входящие звонки. Но, возможно, не сможете исходящие. Проверка sip-логов показала, что A&A возвращает ошибку "415 unsupported media type" при попытке звонка. В SDP сообщении, отправляемом для установления вызова, включалась строка:
m=audio 12345 RTP/AVP 0 101 13
Это согласование кодеков, и цифры "0 101 13" обозначают кодеки, которые UniFi Talk заявляет как поддерживаемые. 101 и 13 к нашему вопросу не относятся, а вот 0 означает поддержку только кодека "PCMU". A&A поддерживает только "PCMA", поэтому звонок отклоняется. Другими словами, UniFi Talk говорит: «Я хочу позвонить, и поддерживаю только PCMU», а A&A отвечает: «Нет, спасибо».
Для сравнения, вот аналогичная строка из более совместимого телефона:
m=audio 12345 RTP/AVP 9 0 8 3 99 112 18 101
Здесь гораздо больше цифр, что значит — телефон сообщает провайдеру поддержку многих кодеков, в том числе 8, то есть кодека PCMA, который нужен A&A.
FreeSWITCH, который использует UniFi Talk, на самом деле поддерживает PCMA, и эта опция включена (чем и объясняется прием вызовов). Но в файле /usr/share/unifi-talk/app/server.js несколько строк с кодеками жестко зашиты. Я не смог понять, какую конкретно строку UniFi использует для исходящих звонков, поэтому заменил все вхождения "PCMU" на "PCMA" в /usr/share/unifi-talk/app/server.js. В каждой такой строке есть и другие кодеки, но если вы используете только A&A, можно заменить содержимое каждой строки только на PCMA — так я и сделал. Не понимаю, почему UniFi так ограничивает список кодеков для провайдера при исходящих вызовах — это явно источник проблем.
Теперь сохраняете файл, перезапускаете провайдера и сможете совершать звонки
——Дополнительные заметки:
* Если через пару минут после настройки вы перестанете принимать звонки, добавьте кастомные поля:
expire-seconds 120
nat-options-ping true
(Это не баг, а просто параметр, который заставляет приложение Talk поддерживать соединение активным, чтобы фаервол не закрывал входящие вызовы). Мне не пришлось открывать порты, включать статический порт сигнализации или что-то подобное.
* Все описанные баги я находил, используя CLI freeswitch. Для этого зайдите по SSH на устройство с Talk (инструкции по включению SSH есть на сайте UniFi), затем выполните команду “fs_cli”. Она будет выводить отладочную информацию. Чтобы увидеть сами SIP-сообщения (как я выявил проблему с кодеками), включите SIP-трейс командой из fs_cli:
sofia global siptrace on
sofia loglevel all 9
Во-первых, следуя этому руководству, вы получите правильные поля и инструкции по настройке, теперь редактировать sip_from_uri не нужно, можно этот пункт игнорировать:
Следующая загвоздка — если при создании провайдера в UniFi Talk вы используете амперсанд (&) в названии провайдера (как это естественно для A&A), UniFi приложение примет это без проблем. Но UniFi Talk при этом никогда не регистрируется у провайдера. Проверяя логи, я обнаружил, что вся конфигурация игнорировалась базовым приложением FreeSWITCH, которое работает с Talk, из-за некорректного имени. Удаление амперсанда из названия решило проблему.
Теперь вы должны принимать входящие звонки. Но, возможно, не сможете исходящие. Проверка sip-логов показала, что A&A возвращает ошибку "415 unsupported media type" при попытке звонка. В SDP сообщении, отправляемом для установления вызова, включалась строка:
m=audio 12345 RTP/AVP 0 101 13
Это согласование кодеков, и цифры "0 101 13" обозначают кодеки, которые UniFi Talk заявляет как поддерживаемые. 101 и 13 к нашему вопросу не относятся, а вот 0 означает поддержку только кодека "PCMU". A&A поддерживает только "PCMA", поэтому звонок отклоняется. Другими словами, UniFi Talk говорит: «Я хочу позвонить, и поддерживаю только PCMU», а A&A отвечает: «Нет, спасибо».
Для сравнения, вот аналогичная строка из более совместимого телефона:
m=audio 12345 RTP/AVP 9 0 8 3 99 112 18 101
Здесь гораздо больше цифр, что значит — телефон сообщает провайдеру поддержку многих кодеков, в том числе 8, то есть кодека PCMA, который нужен A&A.
FreeSWITCH, который использует UniFi Talk, на самом деле поддерживает PCMA, и эта опция включена (чем и объясняется прием вызовов). Но в файле /usr/share/unifi-talk/app/server.js несколько строк с кодеками жестко зашиты. Я не смог понять, какую конкретно строку UniFi использует для исходящих звонков, поэтому заменил все вхождения "PCMU" на "PCMA" в /usr/share/unifi-talk/app/server.js. В каждой такой строке есть и другие кодеки, но если вы используете только A&A, можно заменить содержимое каждой строки только на PCMA — так я и сделал. Не понимаю, почему UniFi так ограничивает список кодеков для провайдера при исходящих вызовах — это явно источник проблем.
Теперь сохраняете файл, перезапускаете провайдера и сможете совершать звонки
——Дополнительные заметки:
* Если через пару минут после настройки вы перестанете принимать звонки, добавьте кастомные поля:
expire-seconds 120
nat-options-ping true
(Это не баг, а просто параметр, который заставляет приложение Talk поддерживать соединение активным, чтобы фаервол не закрывал входящие вызовы). Мне не пришлось открывать порты, включать статический порт сигнализации или что-то подобное.
* Все описанные баги я находил, используя CLI freeswitch. Для этого зайдите по SSH на устройство с Talk (инструкции по включению SSH есть на сайте UniFi), затем выполните команду “fs_cli”. Она будет выводить отладочную информацию. Чтобы увидеть сами SIP-сообщения (как я выявил проблему с кодеками), включите SIP-трейс командой из fs_cli:
sofia global siptrace on
sofia loglevel all 9