VoIP

Учитывая последние события, возникла необходимость обезопасить нашу внутреннюю связь. Для этих целей уже давно существует 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 одновременных соединений.

Icons_39x39_RoutingВ разделе [Маршрутизация] мы можем указать префикс для набранного направления либо несколько префиксов через разделитель “|”. К примеру, что бы указать выбор направлений на оператора Life, можем задать: 063|093. Но, что делать, если наши пользователи не придерживаются стандарта? А могут набрать номер того же Life в несколько способов: +38063 , 38063, 8063 или 063.

“Можно создать сразу 4 маршрута”, – скажите Вы.
“Достаточно создать только 1 маршрут”, – отвечу я 🙂

Для этого воспользуемся регулярными выражениями. В системных настройках Terrasoft, активируйте ключ “WebitelConfigExpertMode”:

WebitelConfigExpertMode

Перезапустите Terrasoft. Теперь в настройках Маршрутизации мы можем использовать регулярные выражения. Все наши 4 варианта можно прописать одной строкой:

Life_RegExp

Обратите внимание! Теперь в направлениях у Вас будет открыт доступ к управлению того, что надо отдавать на шлюз. Здесь достаточно указать сколько последних цифр из выражения отправлять. Если нам не нужны с Life “+38”, тогда поставим просто 10 – десять последних знаков в строке. Выглядит это так:

Dialplan

В переменной ${destination_number} храниться то, что набрал пользователь. Из этой переменной я вырезаю 10 последних цифр: (\d{10})$ и результат возвращаю в первую переменную канала (то, что пойдет к оператору): %1