PBX

Довольно часто наши клиенты сталкиваются с необходимостью выгрузить информацию о звонках из раздела Call Detail Record к себе. Как вы уже знаете (даже если взять во внимание предыдущую запись в этом блоге, а именно Липкость звонка), вся историческая статистика хранится в базе elasticsearch. В документации вы так же могли увидеть пример получения данных с помощью нашего REST API. Но, что если звонков несколько сотен? Или несколько тысяч? Как правильно получить такой объем данных? Сегодня я расскажу как работать с большими объемами данных.

Scroll

Для получения большого количества данных, в elasticsearch предусмотрен функционал scroll, который мы повторили и в нашем REST API. Рассмотрим на примере:

Использование IVR меню, в большинстве случаем, позволяет эффективно распределять входящие звонки и снижать нагрузку с секретаря. Клиент звонит, выбирает нужный отдел либо до набирает внутренний номер сотрудника и достигает цели. Но, как быть в ситуации, когда клиент не знает кому он звонит? Что если это наш менеджер не смог дозвонится клиенту, который перезвонил и попал на IVR? В данном случае будет полезным функционал “Липкости звонка”. Мы уже рассматривали реализацию: Входящий звонок с маршрутизацией на ответственного в bpm’online. Сегодня мы рассмотрим пример маршрутизации в первую очередь на того, кто сегодня уже общался с данным номером либо звонил ему. Приступим!

Kibana нам в помощь

Для решения поставленной задачи нам понадобится приложение cdr, которое предназначено для поиска по журналу звонков в elasticsearch. В начале, нам нужно написать правильный запрос. Делаем тестовый звонок и открываем интерфейс Kibana, раздел Discover. Выбираем для отображения колонки extension (номер сотрудника), caller_id_number (номер абонента), destination (номер назначения).

Теперь сделаем запрос с фильтрацией по номеру абонента, он может быть либо в номере назначения (для исходящих) либо в номере абонента (для входящих):

destination_number:/0969716158/ OR caller_id_number:/0969716158/

Как результат, мы получаем номер сотрудника, extension, который общался либо звонил абоненту. И обязательно открываем Response (ответ со стороны elasticsearh), он нам пригодится ниже:

И так, как искать мы уже поняли, а теперь, добавим это все в маршрутизацию на стороне Webitel.

Сегодня мы поговорим о SIP телефонах. А именно, об опыте использования SIP телефонов в локальной сети офиса, которые подключаются к SIP серверу через публичную сеть Интернет. Если вы используете SIP-телефоны вместе с нашим облачным сервисом, то данная заметка будет полезна и поможет избежать основных проблем при работе IP телефонии за NAT.

Что такое NAT?

Начнем с того, а что же такое этот NAT?

Не буду копировать из wiki умные вещи, попробую объяснить проще – NAT (Network Address Translation) — это механизм, который позволяет маршрутизатору (наш сервер, роутер, модем – все, что используем для выхода в Интернет) определять какие сервисы находятся за роутером и должны быть доступны из интернета, чтобы пользователи оттуда могли этими сервисами пользоваться. Так как, в большинстве случаев, у нас всего 1 внешний (белый, публичный – как кому больше нравится) IP адрес, а устройств в сети много, то мы используем локальные (серые) IP адреса. Они не доступны из Интернета, а NAT помогает нам опубликовать в мир какой-то порт из локальной сети.

Надеюсь, что здесь пока все понятно…

Лет 7 тому назад, я уже писал на тему обработки входящего звонка от клиента, с поиском внутреннего номера сотрудника, который последним звонил на номер клиента. Теперь пришло время написать похожую статью, как такое реализовать в webitel, тем более, что начиная с версии 3.8.2 (UPD: как оказалось, нужна версия старше 3.8.2) у нас в маршрутизации появилось отдельное приложение для запросов в базу elasticsearch, где и хранится вся информация о звонках. Давайте рассмотрим пример, как научить webitel соединять клиентов с последним звонившим.

Предположим, что у нас уже имеется любая существующая схема с IVR и другими полезностями. Мы хотим добавить в начале проверку по номеру телефона, звонящего к нам в офис, кто из сотрудников последним звонил на данный номер. Дополнительно мы еще добавим ограничение в “за последние 30 минут”. Все это мы можем сделать с помощью запроса в cdr:

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

Кода Вы открываете настройку исходящей маршрутизации, то можете увидеть вот такой кошмар:

Давайте на данном примере попытаемся понять, что и как работает.

^\+?38?(0[679]3\d{7})$

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

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

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

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

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

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

Вчера проводил небольшой внутренний вебинар на тему нашего автодайлера: какие типы, как настраивать и как все работает. Хотя вебинар и внутренний, но для подписчиков канала в telegram ссылочку я выложил. Так, что – подписывайтесь, если хотите быть в курсе всего нового!

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

И вот они, кубики:

Почти в каждом внедрение Webitel мы настраиваем создание Активности или Лида в bpm’online при звонке в нерабочее время. Сегодня я решил описать простой механизм создания Лида с помощью веб-службы DataService. Что бы было интересней, мы воспользуемся средствами преобразования текста в голос и распознавания голоса в webitel. Приступаем к реализации!

В справочнике Тип потребности bpm’online я создам новую запись с названием Заказ обратного звонка:

А в справочнике Каналы Лида добавлю наш номер, что бы было легче идентифицировать на какой номер звонил клиент:

Теперь перейдем к настройкам маршрутизации в webitel. Наша схема состоит из нескольких блоков.

Не так давно наша компания начала активно использовать Slack в качестве внутреннего корпоративного чата. Одним из больших преимуществ данного приложения (как и в webitel) – множество механизмов для веб-интеграций. Сегодня рассмотрим пример уведомления пользователей о пропущенных звонках.

Первое, что необходимо сделать – настроить входящий WebHook:

Настройте изображением, название и скопируйте сгенерированный входящий URL.

Дальше, в public маршрутизации нашего городского номера на событие OnDisconnect добавляем: