VoIP

Voice over Internet Protocol (VoIP) – сегодня это один из самых популярных стандартов для голосовых и видеозвонков в мире Интернет. В этой заметке я попробую на простых примерах рассказать, как работают голосовые и видеозвонок.

Почти каждый день мы с вами используем голосовые либо видеозвонка в различных приложениях, таких как Skype, Viber, Telegram, WhatsApp, Facebook Messenger или Webitel 🙂 В общем, передача аудио либо видео зависит от того, как приложение передаст медиапоток между двумя клиентами. И в большинстве случаем для потоковой передачи мультимедиа мы используем WebRTC.

WebRTC – это стандарт c открытым исходным кодом, который предоставляет браузеры и мобильные приложения возможности взаимодействовать в реальном времени (RTC) через простые API. Все компоненты WebRTC были оптимизированы именно для работы мультимедиа в различных сетях интернет.

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

  • Сигнальный протокол
  • STUN
  • TURN

Что такое сигнализация?

Учитывая последние события, возникла необходимость обезопасить нашу внутреннюю связь. Для этих целей уже давно существует SIPS и SRTP. Давайте посмотрим, как это все работает.

Когда мы используем обычный SIP, то каждый звонок выглядит вот так:

SIP

Достаточно встать вразрез между нами и провайдером, и все звонки, как на ладони. Более того, перехватив RTP трафик, можно и разговоры подслушать.

Вся статистика webitel хранится в хранилище MongoDB в виде JSON файлов с детальным описанием всего маршрута звонка и переменных канала. Но, до сегодня было довольно сложно быстро построить отчет (либо график) по истории звонков. И мы начали поиск решения… Но, решение оказалось ближе, чем мы предполагали 🙂

Уже несколько последних месяцев для сбора и анализа логов я использую связку Elasticsearch+Logstash+Kibana, которая успешно справляется с поставленной задачей. Возникла идея, что если синхронизировать MongoDB с Elasticsearch и с помощью Kibana строить отчеты. Так и решили сделать!

Не так давно мы перенесли наш облачный сервис на площадку DigitalOcean, что позволило не только увеличить производительность, но и добавить новые функции, такие как поддержка IPv6. Вся прелесть в том, что в офисе мы тоже используем IPv6. Так почему, бы не настроить телефоны напрямую, минуя NAT? Так и сделаем!

С Yalink T22 проблем небыло – включил поддержку IPv6 и все просто заработало. А вот на SIP-T20 не завелось… Как я выяснил, по какой-то причине (глюк в прошивке), телефон не подхватывал шлюз:

Yealink SIP-T20

Пришлось прописать вручную. И сразу телефон зарегистрировался на сервере:

SIP IPv6

Что же, Webitel в on-demand теперь доступен как по IPv4, так и по IPv6 – пользуйтесь!

В предыдущих статьях я рассказал о том, что такое Docker и как оно все работает. Так же, рассмотрели пример запуска простого Webitel-приложения в контейнере. Сегодня я покажу практический пример, как быстро запустить FreeSWITCH в контейнере.

Для Webitel мы уже давно используем Docker как основной инструмент управления приложением. Для FreeSWITCH я сделал базовый образ, на основание которого строится автоматически образ для Webitel. Недавно, я расширил его еще и под задачи установки vanilla конфигурации FreeSWITCH. Вы можете его использовать для быстрого разворачивания приложения. Как это сделать – опишу ниже.

Бесплатные звонки – звучит как рекламный лозунг! Нет, это не реклама (хотя…).

Рады представить сообществу Terrasoft новый продукт Webitel Community, который позволяет бесплатно совершать видео и аудио звонки между пользователями bpmonline 7 с использованием технологии WebRTC. Каждой компании, которая оставит заявку на сайте, будут предоставлены 5 лицензий Webitel Community.

Что предлагает Webitel Community?

  • Бесплатные звонки между пользователями
  • Видеозвонки
  • Определение статусов сотрудников
  • Перевод звонка и удержание

Если Вас у Вас есть пожелания – пишите в комментариях.

PS: небольшое видео, как это все работает: https://vimeo.com/97131875

PPS: если Вы установите на свой bpmonline 7 пакет Webitel Community и в другой компании сделано то же самое, то Вы сможете позвонить им тоже бесплатно. Вот оно – Community!

На этой неделе начали тестировать Webitel CTI – небольшая web-панель, которая позволит совершать звонки с любого веб-решения. Первая версия выйдет под bpmonline и вот что мы уже сейчас имеем:

С помощью набора JavaScript библиотек, мы подключаем нашу панель:

main

Для IP-телефонии критичны задержки пакетов в сети, хотя технология обладает некоей толерантностью (устойчивостью) к потерям отдельных пакетов. Так, потеря до 5 % пакетов не приводит к ухудшению разборчивости речи. Максимальное отклонение между последовательной передачей пакетов в сети Интернет не должны превышать 50 мс. Максимальный процент потерь при передачи пакетов в сети Интернет – не более 3%.

Причины задержек в передаче голосовых данных по сети IP в большой степени связаны с особенностями транспорта пакетов. Протокол TCP обеспечивает контроль доставки пакетов, однако достаточно медленный и потому не используется для передачи голоса. UDP быстро отправляет пакеты, однако восстановление потерянных данных не гарантируется, что приводит к потерянным частям разговора при восстановлении (обратном преобразовании) звука. Немалые проблемы приносит джиттер (отклонения в периоде поступления-приёмки пакетов), появляющийся при передаче через большое число узлов в нагруженной IP-сети. Недостаточно высокая пропускная способность сети (например при одновременной нагрузке несколькими пользователями), серьёзно влияет не только на задержки (то есть рост джиттера), но и приводит к большим потерям пакетов.

Между конечными точками пользователей и серверами IP-телефонии, а также между серверами IP-телефонии и оборудованием оператора связи (поставщика VoIP) программных или аппаратных устройств, канал должен отвечать описанным выше требованиям.

Проверить пропускную способность каналов можно с помощью простой утилиты iperf-2.0.5. Предположим, что мы хотим гарантировать 10 одновременных разговоров с использованием G.711 кодека. Рекомендуемое требование к каналу составляет 1 Мбит/с.

На сервере запускаем iperf с параметрами (ожидать на стандартном порте 5001 входящие UDP запросы):
iperf -u -s

На клиенте запускаем тестирование UDP c длиной 160 байт со скоростью 1 Мбит/с в течение 180 секунд на сервер 10.10.10.119:
iperf -u -c 10.10.10.119 -l 160 -b 1M -t 180

Получаем результат:

Канал пригоден для 10 одновременных соединений.