11.8. Сервисы связи реального времени
Службы связи в реальном времени (RTC) включают голосовую связь, видео/веб-камеру, обмен мгновенными сообщениями (IM) и общий доступ к рабочему столу. В этой главе дается краткое описание трёх служб, необходимых для работы RTC, включая сервер TURN, сервер SIP и сервер XMPP. Подробные сведения о планировании, установке и управлении этими службами доступны в Кратком руководстве по обмену данными в реальном времени, которое включает примеры, специфичные для Debian.
И SIP, и XMPP могут обеспечивать одинаковую функциональность. SIP более известен в передаче голоса и видео, тогда как XMPP традиционно считается протоколом обмена мгновенными сообщениями. Фактически, они оба могут быть использованы для любой из этих целей. Чтобы максимизировать возможности подключения, рекомендуется запускать оба варианта параллельно.
Эти службы используют сертификаты X.509 как для целей аутентификации, так и для обеспечения конфиденциальности. См.
Раздел 10.2, «X.509 certificates» для получения дополнительной информации.
11.8.1. Настройки DNS для служб RTC
; сервер, на котором все будет работать
server1 IN A 198.51.100.19
server1 IN AAAA 2001:DB8:1000:2000::19
; IPv4 сейчас только для TURN, некоторые клиенты глючат с IPv6
turn-server IN A 198.51.100.19
; IPv4 and IPv6 addresses for SIP
sip-proxy IN A 198.51.100.19
sip-proxy IN AAAA 2001:DB8:1000:2000::19
; IPv4 и IPv6 адреса для XMPP
xmpp-gw IN A 198.51.100.19
xmpp-gw IN AAAA 2001:DB8:1000:2000::19
; DNS SRV и NAPTR для STUN / TURN
_stun._udp IN SRV 0 1 3467 turn-server.falcot.com.
_turn._udp IN SRV 0 1 3467 turn-server.falcot.com.
@ IN NAPTR 10 0 "s" "RELAY:turn.udp" "" _turn._udp.falcot.com.
; DNS SRV и NAPTR записи для SIP
_sips._tcp IN SRV 0 1 5061 sip-proxy.falcot.com.
@ IN NAPTR 10 0 "s" "SIPS+D2T" "" _sips._tcp.falcot.com.
; DNS SRV записи для XMPP Server и Client режимов:
_xmpp-client._tcp IN SRV 5 0 5222 xmpp-gw.falcot.com.
_xmpp-server._tcp IN SRV 5 0 5269 xmpp-gw.falcot.com.
TURN — это служба, которая помогает клиентам, находящимся за маршрутизаторами NAT и межсетевыми экранами, находить наиболее эффективный способ взаимодействия с другими клиентами и ретрансляции медиапотоков, если прямой путь к мультимедиа не найден. Настоятельно рекомендуется установить сервер TURN до того, как конечным пользователям будут предложены какие-либо другие службы RTC.
TURN и связанный с ним протокол ICE являются открытыми стандартами. Чтобы извлечь выгоду из этих протоколов, максимизировать возможности подключения и свести к минимуму разочарование пользователей, важно убедиться, что всё клиентское программное обеспечение поддерживает ICE и TURN.
Для эффективной работы алгоритма ICE сервер должен иметь два общедоступных IPv4-адреса.
Установите пакет coturn и отредактируйте /etc/turnserver.conf файл конфигурации. По умолчанию база данных SQLite сконфигурирована в /var/db/turndb для настроек учётной записи пользователя, но при желании вместо неё можно настроить PostgreSQL, MySQL или Redis. Самое важное — это вставить IP-адреса сервера.
Сервер можно запустить turnserver из пакета coturn. Мы хотим, чтобы сервер был автоматически запускаемой системной службой. Это поведение по умолчанию при использовании systemd. Только при использовании более старой версии SysVinit вам придется редактировать файл вроде этого /etc/default/coturn:
#
# Раскомментируйте, если хотите, чтобы turnserver работал как
# демон автоматического сервиса
#
TURNSERVER_ENABLED=1
По умолчанию сервер TURN использует анонимный доступ. Нам нужно добавить пользователей, которых мы хотим использовать:
# turnadmin -a -u roland -p secret_password -r falcot.com
# turnadmin -A -u admin -p secret_password
Мы используем аргумент -a чтобы добавить обычного пользователя и -A чтобы добавить администратора.
Прокси-сервер SIP управляет входящими и исходящими SIP-соединениями между другими организациями, провайдерами SIP-транкинга, SIP-УАТС, такими как Asterisk, SIP-телефонами, программными телефонами на основе SIP и приложениями WebRTC.
Настоятельно рекомендуется установить и настроить SIP-прокси перед попыткой настройки SIP-АТС. Прокси-сервер SIP нормализует большую часть трафика, поступающего на УАТС, и обеспечивает более высокое качество подключения и устойчивость.
11.8.3.1. Установите SIP-прокси
Установите пакет kamailio и пакет для серверной части базы данных. Администраторы Falcot выбрали MySQL, поэтому устанавливают kamailio-mysql-modules и mariadb-server. /etc/kamailio/kamctlrc - это файл конфигурации для инструментов управления kamctl и kamdbctl. Вам необходимо отредактировать и установить SIP_DOMAIN для вашего домена службы SIP и установить DBENGINE для MySQL, можно использовать другой бэкенд базы данных.
[...]
## ваш SIP домен
SIP_DOMAIN=sip.falcot.com
## chrooted каталог
# CHROOT_DIR="/path/to/chrooted/directory"
## тип базы данных: MYSQL, PGSQL, ORACLE, DB_BERKELEY, DBTEXT, или SQLITE
# по умолчанию none загружено
#
# Если вы хотите настроить базу данных с kamdbctl, вы должны как минимум указать
# этот параметр.
DBENGINE=MYSQL
[...]
Теперь сосредоточимся на файле конфигурации /etc/kamailio/kamailio.cfg. Falcot необходима аутентификация пользователя и постоянное местоположение пользователя, поэтому они добавляют #!define директивы в верхней части этого файла:
#!KAMAILIO
#
# Kamailio (OpenSER) SIP Server v5.2 - умолчальный конфигурационный скрипт
# - web: https://www.kamailio.org
# - git: https://github.com/kamailio/kamailio
#!define WITH_MYSQL
#!define WITH_AUTH
#!define WITH_USRLOCDB
[...]
Kamailio нужна структура базы данных, которую мы можем создать, работая kamdbctl create как root. Наконец, мы можем добавить некоторых пользователей с помощью kamctl.
# kamdbctl create
[...]
# kamctl add roland secret_password
Как только всё будет правильно настроено, вы можете запустить или перезапустить службу с помощью
systemctl restart kamailio, вы можете подключиться к SIP-клиенту, указав IP-адрес и порт (5090 — порт по умолчанию). Пользователи имеют следующий идентификатор:
roland@sip.falcot.com, и они могут войти в систему с помощью клиента (см.
Раздел 13.9, «Программное обеспечение коммуникации в реальном времени»).
Сервер XMPP управляет подключением между локальными пользователями XMPP и пользователями XMPP в других доменах общедоступного Интернета.
prosody — популярный сервер XMPP, который надёжно работает на серверах Debian.
11.8.4.1. Установить XMPP-сервер
Установите пакет prosody.
Просмотрите файл конфигурации /etc/prosody/prosody.cfg.lua. Самое важное — это указать JID-ы пользователей, которым разрешено управлять сервером.
admins = { "joe@falcot.com" }
Для каждого домена также необходим отдельный файл конфигурации. Скопируйте образец из /etc/prosody/conf.avail/example.com.cfg.lua и используйте его как отправную точку. Вот здесь falcot.com.cfg.lua:
VirtualHost "falcot.com"
enabled = true
ssl = {
key = "/etc/ssl/private/falcot.com.key";
certificate = "/etc/ssl/certs/falcot.com.pem";
}
-- Set up a MUC (multi-user chat) room server on conference.example.com:
Component "conference.falcot.com" "muc"
Чтобы включить домен, должна быть символическая ссылка с /etc/prosody/conf.d/. Создайте это так:
# ln -s /etc/prosody/conf.avail/falcot.com.cfg.lua /etc/prosody/conf.d/
Перезапустите службу, чтобы использовать новую конфигурацию.
11.8.4.2. Управление XMPP-сервером
Некоторые операции управления можно выполнить с помощью prosodyctl утилиты командной строки. Например, чтобы добавить учётную запись администратора, указанную в /etc/prosody/prosody.cfg.lua:
# prosodyctl adduser joe@falcot.com
11.8.5. Запуск служб на порту 443
Некоторые администраторы предпочитают запускать все свои службы RTC на порту 443. Это помогает пользователям подключаться из удалённых мест, таких как отели и аэропорты, где другие порты могут быть заблокированы или интернет-трафик направляется через прокси-серверы HTTP.
Чтобы использовать эту стратегию, каждой службе (SIP, XMPP и TURN) нужен отдельный IP-адрес. Все службы по-прежнему могут находиться на одном хосте, поскольку Linux поддерживает несколько IP-адресов на одном хосте. Номер порта 443 должен быть указан в файлах конфигурации для каждого процесса, а также в записях DNS SRV.
11.8.6. Добавление WebRTC
Falcot хочет позволить клиентам совершать телефонные звонки прямо с веб-сайта. Администраторы Falcot также хотят использовать WebRTC как часть своего плана аварийного восстановления, чтобы сотрудники могли использовать веб-браузеры дома для входа в телефонную систему компании и нормально работать в чрезвычайной ситуации.
WebRTC — это быстро развивающаяся технология, поэтому важно использовать пакеты из Testing дистрибутива. Другой вариант — скомпилировать программное обеспечение.
WebRTC использует простой API для предоставления RTC браузерам и мобильным приложениям. Это бесплатное программное обеспечение, разрабатываемое Google.
Очень гибкий подход — использование реализации WebRTC GStreamer. Он позволяет создавать мультимедийные приложения на основе конвейеров, что позволяет разрабатывать интересные и высокоэффективные приложения. Хорошей отправной точкой является следующая демонстрация от Centricular, основной компании, которая её разрабатывает:
Более продвинутые веб-сайты с возможностью звонка по щелчку обычно используют серверные сценарии для создания файла
config.js динамически. Исходный код
DruCall демонстрирует, как это сделать с помощью PHP.
В этой главе представлена лишь часть доступного серверного программного обеспечения; однако было описано большинство распространённых сетевых служб. Теперь настало время для ещё более технической главы: мы углубимся в детали некоторых концепций, опишем массовое развертывание и виртуализацию.
