Я решил заморозить данный блог.
Свежую информацию о Webitel вы сможете найти:
— в корпоративном блоге: https://docs.webitel.com/pages/viewrecentblogposts.action?key=W3
— в telegram канале: https://t.me/webitel
Мой личный дневник (українською мовою): https://www.kovalyshyn.pp.ua/
Довольно часто наши клиенты сталкиваются с необходимостью выгрузить информацию о звонках из раздела Call Detail Record к себе. Как вы уже знаете (даже если взять во внимание предыдущую запись в этом блоге, а именно Липкость звонка), вся историческая статистика хранится в базе elasticsearch. В документации вы так же могли увидеть пример получения данных с помощью нашего REST API. Но, что если звонков несколько сотен? Или несколько тысяч? Как правильно получить такой объем данных? Сегодня я расскажу как работать с большими объемами данных.
Для получения большого количества данных, в 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.
Цього року вирішив запустити окремий блог українською мовою де описуватиму досвід використання OpenSource та воасні хобі. Цей блог залишиться лише із професійними матеріалами. Перший запис у новому блозі про встановлення Linux на USB «флешку» із зашифрованою файловою системою.
Сегодня мы поговорим о SIP телефонах. А именно, об опыте использования SIP телефонов в локальной сети офиса, которые подключаются к SIP серверу через публичную сеть Интернет. Если вы используете SIP-телефоны вместе с нашим облачным сервисом, то данная заметка будет полезна и поможет избежать основных проблем при работе IP телефонии за 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 недостаточно, а именно:
Вчера проводил небольшой внутренний вебинар на тему нашего автодайлера: какие типы, как настраивать и как все работает. Хотя вебинар и внутренний, но для подписчиков канала в telegram ссылочку я выложил. Так, что — подписывайтесь, если хотите быть в курсе всего нового!
Если вы думаете, что дошли до абсолютного предела, не верьте – на самом деле вы задействовали только 40 процентов своих возможностей. Нас ограничивает не тело. Нас ограничивает мозг.
Сьогодні їдемо на Grand Prix Lviv Half Marathon 2017, доща не має, але це зовсім не означає, що його не буде, як тільки ми подолаємо стартовий коридор. Дорогою думаю про те, чи не даремно минув мій рік тренувань після моєї першої спроби у Києві, чи зможу вийти за 2 години, адже цієї весни мені так і не вдалося цього зробити.
Заходжу в стартовий коридор у самому кінці та припасовуюся поряд із пейсмейкерами на 2:00. Моя задача на сьогодні — пробити цю кляту двійку! Під звуки AC/DC, із великою посмішкою, розпочинаю бігти. Polar показує темп 5:40 і я не поспішаючи пробиваюся крізь натовп. Перші 3 кілометри біжу доволі спокійно, тримаюся пейсмейкерів та слухаю музику. Плейлист дуже добре відповідає такту та пульсу — просто насолоджуюся бігом. Коли добігаємо до Погулянки, розумію, що можу швидше, а Марія запитує, чи не захворів, як і вона 🙂 Перевіряю — не захворів! Збільшую темп до 5:05.
На 9 кілометрі розпочинається дощ (куди без нього!), а хлопці з Bullet for My Valentine заспівали про маленкий брудний секрет і в цей момент я бачу гірку на Горбачевського… Затяжний підйом… Серце починає працювати швидше… На допомогу приходить SOAD із китайським рагу, відновлюю дихання та долаю цю гірку — ура! Тепер під мелодійну пісню про маму, можна й по рівному побігти.