По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет! В статье расскажем о бесплатном способе передачи информации о звонящем в момент звонка из Битрикс24. Проверять мы будем лид и контакт. В качестве системы, куда мы будет отправлять данные будет уютный Telegram :) Погнали.
Создаем Вебхук в Битрикс24
Переходим в Битрикс24 и открываем раскрывающееся меню в верхнем левом углу. Далее, выбираем «Вебхуки»:
Добавляем Входящий вебхук, нажав на зеленую кнопку в правом верхнем углу Добавить вебхук. Делаем следующие настройки:
Название - дайте имя. Например «Внешний доступ к REST API»;
Описание - «cоответствие номера клиента и его имени»;
Права доступа - необходимо выбрать «CRM (crm)»;
Нажимаем «Сохранить». Для нас будет сгенерирован Вебхук. Переходим к настройке скрипта.
Telegram - бот
Перед продолжение настройки, вам необходимо создать Telegram – бота. О том, как это сделать читайте по кнопке:
Создание бота
Скрипт интеграции
Из предыдущего шага, у вас должен быть идентификатор чата в Telegram, токен бота, вебхук и доменное имя вашего Битрикс24. Все, остальное дело скрипта:
#!/usr/bin/php -q
<?php
#подключаем AGI - библиотеку;
require('phpagi.php');
$agi = new AGI();
$cid = $agi->request['agi_callerid'];
#от провайдера, номер на нашу АТС прилетает в формате 79ХХХХХХХХХ. В CRM номера записаны как 89ХХХХХХХХХ. Поэтому, мы стрипаем цифру спереди и подставлем 8ку;
$phone = substr($cid, 1);
$phone = "8$phone";
$phoneFieldset = "Коллеги, входящий звонок. Звонящий: ";
#укажите служебные параметры: токен бота, идентификатор чата, хостовое имя CRM (то, что между https:// и до .bitrix24.ru) и вебхук, который мы получили ранее;
$token = "333333333:MMMMMEEEEE_RRRIIIIOOOO_NNNNEEEETTTT";
$chat_id = "-1001001001001";
$crm_id = "имя_вашего_Битрикс24";
$webhook = "wblhahgytuwrnwer";
#проверяем существование лида по номеру;
$bitrix_lead_url = "https://$crm_id.bitrix24.ru/rest/2/$webhook/crm.lead.list.json?filter[PHONE]=$phone&select[]=TITLE&select[]=NAME&select[]=LAST_NAME";
$btl = curl_init();
curl_setopt ($btl, CURLOPT_URL,$bitrix_lead_url);
curl_setopt ($btl, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6");
curl_setopt ($btl, CURLOPT_TIMEOUT, 60);
curl_setopt ($btl, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt ($btl, CURLOPT_RETURNTRANSFER, 1);
$bitrix_lead = curl_exec ($btl);
curl_close($btl);
$bitrix_lead_o = json_decode($bitrix_lead, true);
$l_total = $bitrix_lead_o['total'];
#проверяем существование контакта по номеру;
$bitrix_contact_url = "https://$crm_id.bitrix24.ru/rest/2/$webhook/crm.contact.list.json?filter[PHONE]=$phone&select[]=TITLE&select[]=NAME&select[]=LAST_NAME";
$btc = curl_init();
curl_setopt ($btc, CURLOPT_URL,$bitrix_contact_url);
curl_setopt ($btc, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6");
curl_setopt ($btc, CURLOPT_TIMEOUT, 60);
curl_setopt ($btc, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt ($btc, CURLOPT_RETURNTRANSFER, 1);
$bitrix_contact = curl_exec ($btc);
curl_close($btc);
$bitrix_contact_o = json_decode($bitrix_contact, true);
$c_total = $bitrix_contact_o ['total'];
#если найден лид, то: формируем массив и кидаем в сторону Telegram: имя, фамилия и идентификатор лида;
if ($l_total >= 1) {
$l_name = $bitrix_lead_o['result'][0]['NAME'];
$l_title = $bitrix_lead_o['result'][0]['TITLE'];
$l_l_name = $bitrix_lead_o['result'][0]['LAST_NAME'];
$l_id = $bitrix_lead_o['result'][0]['ID'];
$l_titleFieldset = "Входящий звонок от лида - ";
$l_FnameFieldset = "Его имя - ";
$l_linkFieldset = "Ссылка на лид - ";
$l_fullname = "$l_name $l_l_name";
$l_link = "https://$crm_id.bitrix24.ru/crm/lead/show/$l_id/";
$arr = array(
$l_titleFieldset => $l_title,
$l_FnameFieldset => $l_fullname,
$l_linkFieldset => $l_link,
);
foreach($arr as $key => $value) {
$txt .= "".$key." ".$value."%0A";
};
fopen("https://api.telegram.org/bot{$token}/sendMessage?chat_id={$chat_id}&parse_mode=html&text={$txt}","r");
}
#если найден контакт, то: формируем массив и кидаем в сторону Telegram: имя, фамилия и идентификатор контакта;
elseif ($c_total >= 1) {
$c_name = $bitrix_contact_o ['result'][0]['NAME'];
$c_c_name = $bitrix_contact_o ['result'][0]['LAST_NAME'];
$c_id = $bitrix_contact_o ['result'][0]['ID'];
$c_FnameFieldset = "Входящий звонок от контакта - ";
$c_linkFieldset = "Ссылка на контакт - ";
$c_fullname = "$c_name $c_c_name";
$c_link = "https://$crm_id.bitrix24.ru/crm/contact/show/$c_id/";
$arr = array(
$c_FnameFieldset => $c_fullname,
$c_linkFieldset => $c_link,
);
foreach($arr as $key => $value) {
$txt .= "".$key." ".$value."%0A";
};
fopen("https://api.telegram.org/bot{$token}/sendMessage?chat_id={$chat_id}&parse_mode=html&text={$txt}","r");
}
else {};
Скачать скрипт
По факту, от вас требуется изменить следующие переменные:
$token - токен вашего бота. Как его получить указано в стате по ссылке «Создание телеграм бота» выше;
$chat_id - идентификатор чата, в котором находится бот. Генерация так же указана в статье;
$crm_id - хостовая часть вашего Битрикс24. Если у вас URL CRM company.bitrix24.ru, то указать нужно company;
$webhook - вебхук. Мы показывали ранее, как его получить в Битрикс24 (у нас wblhahgytuwrnwer);
Сохраняем скрипт как b24.php закидываем его в директорию /var/lib/asterisk/agi-bin.
Адаптируем скрипт в unix – среде:
dos2unix /var/lib/asterisk/agi-bin/b24.php
chown asterisk:asterisk /var/lib/asterisk/agi-bin/b24.php
chmod 775 /var/lib/asterisk/agi-bin/b24.php
В диалплане (вставьте исполнение скрипта в транке, например):
exten => _.,n,AGI(b24.php)
Добавив в скрипт конструкцию вида $agi->set_variable("lookupcid", "$c_fullname"); для контакта или $agi->set_variable("lookupcid", "$l_fullname"); для лида, в диалплане мы сможем сделать следующее: Set(CALLERID(name)=${lookupcid}) мы получим имя звонящего в виде CallerID Name – например, на дисплее телефона.
Можете создать тестового лида (или контакт) со своим номером телефона или дождаться звонка клиента. Наслаждаемся :)
Перед началом убедитесь, что ознакомились с материалом про альтернативные пути без петель.
Нет особой причины, по которой весь SPT должен перестраиваться каждый раз, когда происходит изменение топологии сети или информации о доступности. Рассмотрим рисунок ниже для объяснения.
Предположим, G теряет связь с 2001: db8: 3e8: 100 :: / 64. Устройству A не требуется пересчитывать свой путь к любому из узлов сети. Доступный пункт назначения - это просто лист дерева, даже если это набор хостов, подключенных к одному проводу (например, Ethernet). Нет причин пересчитывать весь SPT, когда один лист (или любой набор листьев) отключается от сети. В этом случае только лист (IP-адрес Интернет-протокола или доступный пункт назначения) должен быть удален из сети (или, скорее, пункт назначения может быть удален из базы данных без каких-либо изменений в сети). Это частичный пересчет SPT.
Предположим, что канал [C, E] не работает. Что делает А в этом случае? Опять же, топология C, B и D не изменилась, поэтому у A нет причин пересчитывать все дерево. В этом случае A может удалить все дерево за пределами E. Чтобы вычислить только измененную часть графа, выполните следующие действия:
Удалите отказавший узел и все узлы, которые нужно достичь через точку E.
Пересчитайте дерево только от предшественника C (в данном случае A), чтобы определить, есть ли альтернативные пути для достижения узлов, ранее доступных через E до того, как канал [C, E] не доступен.
Это называется инкрементным SPF.
Расчет LFA и rLFA.
В предыдущих лекциях (первой части) по теме «Пути одноадресной передачи без петель» рассматривается теория, лежащая в основе LFA и rLFA. Bellman-Ford не вычисляет ни соседей ниже по потоку, ни LFA, и, похоже, не располагает необходимой для этого информацией. DUAL по умолчанию вычисляет нисходящих соседей и использует их во время конвергенции. А как насчет протоколов на основе Дейкстры (и, соответственно, аналогичных алгоритмов SPF)? На рисунке ниже показан простой механизм, который эти протоколы могут использовать для поиска LFA и соседних узлов ниже по потоку.
Определение нисходящего соседа - это такое, при котором стоимость достижения соседом пункта назначения меньше, чем локальная стоимость достижения пункта назначения. С точки зрения А:
A знает местную стоимость проезда к месту назначения на основе SPT, созданного с помощью SPF Дейкстры.
A знает стоимость B и C, чтобы добраться до места назначения, вычитая стоимость каналов [A, B] и [A, C] из рассчитанной на местном уровне стоимости.
Следовательно, A может сравнивать локальную стоимость со стоимостью от каждого соседа, чтобы определить, находится ли какой-либо сосед в нисходящем направлении по отношению к любому конкретному месту назначения. Определение LFA:
Если затраты соседа для «меня» плюс затраты соседа на достижение пункта назначения ниже, чем местные затраты, соседом является LFA.
Вернее, учитывая:
NC - это стоимость соседа до пункта назначения.
BC - это стоимость соседа для меня.
LC - местная стоимость до места назначения.
Если NC + BC < LC, то соседом является LFA. В этом случае A знает стоимость каналов [B, A] и [C, A] с точки зрения соседа (она будет содержаться в таблице топологии, хотя не используется при вычислении SPT с использованием алгоритма Дейкстры). Таким образом, LFA и нисходящие соседи требуют очень небольшой дополнительной работы для расчета, но как насчет удаленных LFA? Модель P/Q Space обеспечивает простейший способ для алгоритмов на основе Дейкстры вычисления соседних узлов и LFA. Рисунок ниже используется для иллюстрации изнутри P/Q Space.
Определение пространства P - это набор узлов, доступных с одного конца защищенного соединения, а определение пространства Q - это набор узлов, достижимых без пересечения защищенного канала. Это должно предложить довольно простой способ вычисления этих двух пространств с помощью Дейкстры:
Рассчитайте SPT с точки зрения устройства, подключенного к одному концу линии связи; удалить линию связи без пересчета SPT. Остальные узлы доступны с этого конца линии.
На рисунке E может:
Вычислите пространство Q, удалив линию [E, D] из копии локального SPT и всех узлов, для достижения которых E использует D.
Вычислите пространство P, вычислив SPT с точки зрения D (используя D в качестве корня дерева), удалив линию [D, E], а затем все узлы, для достижения которых D использует E.
Найдите ближайший узел, достижимый как из E, так и из D, с удаленной линией [E, D].
SPF Дейкстры - это универсальный, широко используемый алгоритм для вычисления Shortest Path Trees через сеть.
Решение Cisco Unified Contact Center Enterprise предназначено для крупных контактных центров, которые имею географически распределенные площадки и большое количество персонала, работающего в рамках центра.
Выделим следующие основные преимущества UCCE:
Интеллектуальная маршрутизация с универсальными очередями;
Computer Telephony Integration (CTI) в рамках модели сеть – рабочее место;
Возможность обрабатывать различные канала взаимодействия (звонки, чаты, e-mail, web – обращения, sms и так далее.);
Голосовое меню IVR;
«Умный» алгоритм очередей;
Интеграция со устаревшими моделями телефонных станций;
Единая платформа отчетности.
Рассмотрим архитектуру решения UCCE:
Компонент Intelligent Contact Manager (ICM) это элемент, ответственный за принятие решений о маршрутизации вызова, отчетности и CTI интеграции. Параллельно, с развертыванием ICM компоненты, устанавливается множество других важных узлов, таких как:
Контроллер: делится на две компоненты:
Router («роутер») - выполняет функции направления и контроля почти всех событий происходящих в рамках ICM. С точки зрения маршрутизации, роутер ответственен за обработку входящих запросов на маршрутизацию и отвечает на исходящие события. Запрос на маршрутизацию может приходить из сети провайдера или других периферийных устройств (ACD, IVR IP PBX и так далее);
Logger («логгер») - так же называется сервер базы данных. Главная функция логгера это быть базой данных для ICM компонента. В предыдущих версиях ICM, логгер содержал только информацию об ICM. Текущие актуальные версии логгера выполняют копии конфигурации ICM и другие административные задачи, такие как уведомления в случае ошибок. Логгер частично содержит историческую отчетность, которая, в большинстве своем, передается на Administration & Data Server (сервер администрирования и информации), на котором хранится историческая отчетность и отчетность типа Real – time (реального времени);
Network Interface Controller (NIC) - интерфейс взаимодействия с провайдером. Не все ICM системы напрямую подключаются к провайдеру услуг. Так же ICM может быть развернут без NIC. В рамках разворачиваемой архитектуры, NIC может быть развернут как сторонним сервере, так и на одном сервере с компонентом Router;
Administration & Data Server - интерфейс пользователя для взаимодействия с конфигурацией и отчетностью;
Периферийный шлюз (Peripheral gateway, PG) - термин «переферийный» используется для обозначения того, что любое внешнее устройство может быть подключено к ICM через PG. Внешними устройствами, или как принято говорить «периферийными», могут быть устаревшие типы ACD, IVR – системы, Cisco Unified Communications Manager, Cisco Unified CVP [7] (Customer Voice Portal) и многие другие. Периферийный шлюз это интерфейс между контроллером и периферией.
Взгляните на архитектуру контактного центра Unified Contact Center Enterprise:
В итоге получаем, что сочетание ICM, CUCM и IVR, и есть Unified Contact Center Enterprise.
Рассмотрим требования Unified CCE к программному обеспечению:
Microsoft Windows Server 2003 SP2 или Microsoft Windows Server 2003 R2 SP2 (стандартный или корпоративный). Данные системы необходимы для таких компонент, как Router, Administration & Data Server, Logger, PG и CTI сервер;
SQl Server 2005;
Только 32-х битная архитектура;
Microsoft SQL Server 2005 SP3 (стандартный или корпоративный). Необходим для таких компонент как Logger и Administration & Data Server;
Требования к аппаратной платформе ниже:
MCS сервера;
Виртуализация возможна только для некоторых компонент;
Многоядерный процессор;
Полнодуплексные сетевые интерфейсы.
Лицензирование
Лицензирование UCCE происходит по двум принципам. Первый, это покупка обязательных лицензий для компонентов и агентов. Вторая часть, это покупка дополнительных лицензий, таких как интеграция со сторонними IVR системами и лицензии на сложные модели развертывания.
К любой системе Unified CCE необходимо приобрести одну (или несколько) категорий лицензий для конкретных клиентских каналов взаимодействия центра, такие как:
Голосовые взаимодействия: Лицензия на развертывание компонент Router/Logger, PG, отказоустойчивые компоненты IVR PG, AWDB, HDS, NIC и так далее;
Взаимодействие по каналу e-mail: Лицензия на развертывание обязательных компонент для обработки e-mail транзакций, таких как Services Server, Application Server, Database Server и так далее;
Взаимодействие по каналу WEB: Для общения с клиентом через WEB формы на сайте компании, необходимо приобрести соответствующие лицензии на компоненты, указанные выше. Лицензия включает встраиваемые шаблоны HTML для взаимодействия по каналу WEB, коннекторы в базы данных и так далее;
Существует 4 возможных схемы лицензирования агентов для обработки голосовых транзакций:
Стандартная лицензия - включает в себя Cisco Agent Desktop (CAD) или Cisco Supervisor Desktop. Приложение CAD является тонким клиентом, где агент может работать с входящим и исходящими вызовами;
Расширенная лицензия - включает в себя Enhanced Cisco Agent Desktop или Enhanced Cisco Supervisor Desktop. Расширение представляет из себя возможность «кастомизации» агентского интерфейса;
Премиум лицензия - в рамках данной лицензии предоставляется возможность выбора одного из агентских рабочих мест, а именно:
Cisco Finesse Agent Desktop - представляет из себя WEB – интерфейс, в котором агент может производить обработку различных событий. Обладает широчайшими возможностями «кастомизации»;
Cisco Toolkit Desktop (CTI OS) - разновидность агентского рабочего места. Представляет широкий набор возможностей обработки вызова, таких как набор номера, ответ, отбой, удержание, подключение, помощь супервизора и так далее;
Premium CAD и Supervisor Desktop - максимальный функциональный набор;
CRM Agent Licenses - включает в себя Cisco Unified CRM Connector для Siebel CRM.