По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Одним из полезнейших инструментов в повседневной работе современного бизнеса является интеграция CRM – системы и офисной телефонии. Это позволяет совершать исходящие звонки по нажатию на номер клиента, иметь всю историю звонков заказчика в CRM, прослушивать его аудиозапись разговоров, автоматически направлять вызов на ответственного менеджера и конечно, видеть карточку клиента при входящем звонке. Сегодня мы хотим рассказать об интеграции облачной Битрикс24 и IP – АТС Asterisk. Как это работает? Настройки рассмотрим на базе решения «Простые звонки». После обращения в компанию, на почту придет ссылку на модуль для Asterisk и инструкция по настройке. Архитектура работы решения следующая: на офисной IP – АТС Asterisk развертывается модуль коннектора, с указанием необходимых настроек. В свою очередь, на стороне Битрикс24 устанавливается приложение и расширение для браузера, в котором указываются реквизиты для подключения к коннектору на IP – АТС. Данное решение работает только в браузере GoogleChrome Настройка Asterisk Переходим к установке модуля АТС – коннектора на стороне Asterisk: Содержимое архива prostiezvonki извлекаем в директорию Asterisk /var/www/html/admin/modules/ и переходим дальше по файловой структуре в директорию /var/www/html/admin/modules/prostiezvonki/module Если вы используете 32 битную систему, то скопируйте файлл libProtocolLib.so в директорию /usr/lib и cel_prostiezvonki.so в директорию /usr/lib/asterisk/modules. Если у вас установлена 64 битная система, то загрузите их в /usr/lib64 и /usr/lib64/asterisk/modules соответственно. Файл из архива cel.conf переместите в директорию /etc/asterisk После настроек, переходим в интерфейс FreePBX. Перейдите во вкладку Admin → Module Admin. Находим модуль «Простые звонки» и производим его установку. После этого, приступаем к настройке: переходи во вкладку Admin → Module Admin: Рассмотрим опции настройки модуля: Общая настройка модуля Пароль - пароль, с помощью которого, Битрикс24 будет подключаться к АТС – коннектору. В данном примере пароль простой - P@ssw0rd Лог файл - полный путь к лог - файлу, в котором коннектор будет фиксировать детали своей работы Уровень записи лога - глубина логирования. Это значение имеет смысл менять на debug на этапе отладаки и "траблшутинга" Порт - порт, на котором АТС - коннектор будет "слушать" подключение от Битрикс24 Лицензия - лицензионный ключ, который вам прислала команда технической поддержки Размер очереди событий - параметр регламентирует размер очереди, в которой накапливается история звонков в случае отсутствия соединения между коннектором на АТС и CRM - системой Общая настройка модуля Префикс для входящих - префикс, который система будет подставлять к входящим звонкам, в момент передачи в Битрикс24 Префикс для исходящих - при использовании функции "Click - to - Call", то есть звонок по нажатию, коннектор будет подставлять префикс для исходящих вызовов Тип канала - в нашем примере мы работает по протоколу SIP Длина внутренних номеров - например, если вы используете внутреннюю нумерацию с 100 - 199, то данное значение будет равно 3 Настройка записи телефонных разговоров Внешняя директория - директория, в которой содержатся файлы системы записи. Здесь содержится внешний IP – адрес нашего маршрутизатора и проброшенный порт. Своего рода это префикс для ссылок на аудио - файл, который коннектор будет подставлять при передаче их в Битрикс24. Мы подробно расскажем о настройке этого поля далее. Настройка умной переадресации Таймаут поиска - время, в течение которого, коннектор ожидает получить номер ответственного сотрудника от Битрикс24 Таймаут ответа - время, в течение которого будет звонить телефон ответственного менеджера Для использования функции «Умная переадресация» (перевод звонка на ответственного менеджера), установите соответствующую галочку в настройках входящих маршрутов Ссылки на запись разговора в Битрикс24 Подключитесь к серверу IP – АТС Asterisk по SSH. Создадим директорию audio в корневой директории WEB – сервера /var/www/html/: [root@asterisk ~]# mkdir /var/www/html/audio После этого смонтируем папку, где хранятся файлы системы записи разговоров Asterisk в созданную директорию. Для этого, откройте файл /etc/fstab: [root@asterisk ~]# vim /etc/fstab Добавьте в файл следующую запись: /var/spool/asterisk/monitor/ /var/www/html/audio/ none rbind 0 0 Примените изменения командой mount -a Настройка Битрикс24 для работы с коннектором Приступаем к настройке Битрикс24. Для этого, переходим в раздел Приложения → Все приложения→ IP-телефония → Простые звонки. Произведите установку указанного приложения: Теперь устанавливаем расширение для браузера Google Chrome. Кликните по кнопке ниже и установите указанное расширение: Расширение для Google Chrome Переходим по пути Настройка → «Инструменты → «Расширения. Находим «Простые звонки» и нажимаем Настройки для конфигурации опций подключения к АТС – коннектору: Опции настройки: Внутренний номер телефона - ваш внутренний номер (Extension) Адрес АТС-коннектора - в нашей примере указано адрес 1.2.3.4:56789 - это внешний IP - адрес нашего маршрутизатора и проброшенный порт. То есть, при обращение на этот адрес "извне", происходит проброс на внутренний адрес 192.168.1.2:10150, где 192.168.1.2 - это IP - адрес Asterisk, а 10150 - порт, который мы ранее указывали в настройках АТС - коннектора Пароль - пароль, который мы указали в настройка АТС - коннектора Кол-во секунд для определения клиента по номеру телефона - если у вас на этапе эксплуатации не определяется клиент по известному номеру, увеличьте это значение Автоматическое создание лида - создавать ли лида, если звонок пришел с неизвестного номера Готово. Нажимаем «Сохранить и подключить». Как видно, наш коннектор находится в статусе «Подключен». Сделаем тестовый звонок: Использование нового API Bitrix24 При установленной галочке "Использование нового API Bitrix24 (бета)", как показано на скриншоте ниже, происходят изменения в работе всплывающих окон:
img
До сих пор в этой серии статей примеры перераспределения маршрутов, над которыми мы работали, использовали один роутер, выполняющий перераспределение между нашими автономными системами. Однако с точки зрения проекта, глядя на этот роутер понимаем, что это единственная уязвимая точка, то есть точка отказа. Для избыточности давайте подумаем о добавлении второго роутера для перераспределения между несколькими автономными системами. То, что мы, вероятно, не хотим, чтобы маршрут объявлялся, скажем, из AS1 в AS2, а затем AS2 объявлял тот же самый маршрут обратно в AS1, как показано на рисунке. Хорошая новость заключается в том, что с настройками по умолчанию, скорее всего не будет проблем. Например, на приведенном выше рисунке роутер CTR2 узнал бы два способа добраться до Сети A. Один из способов — это через OSPF, к которому он подключен. Другой путь был бы через EIGRP AS, через роутер CTR1 и обратно в OSPF AS. Обычно, когда роутер знает, как добраться до сети через два протокола маршрутизации, он сравнивает значения административного расстояния (AD) протоколов маршрутизации и доверяет протоколу маршрутизации с более низким AD. В этом примере, хотя EIGRP AD обычно составляет 90, что более правдоподобно, чем OSPF AD 110, AD EIGRP External route (т. е. маршрута, который возник в другом AS) составляет 170. В результате OSPF-изученный маршрут CTR2 к сети A имеет более низкую AD (т. е. 110), чем AD (т. е. 170) EIGRP-изученного маршрута к сети A. Что в итоге? CTR2 отправляет трафик в Сеть A, отправляя этот трафик в OSPF AS, без необходимости передавать EIGRP AS. Время от времени, однако, нам потребуется произвести настройки некоторых не дефолтных параметров AD, или же нам понадобятся creative metrics, применяемые к перераспределенным маршрутам. В таких случаях мы подвергаемся риску развития событий, описанных на предыдущем рисунке. Давайте обсудим, как бороться с такой проблемой. Рассмотрим следующую топологию. В этой топологии у нас есть две автономные системы, одна из которых работает под управлением OSPF, а другая- под управлением EIGRP. Роутеры CTR1 и CTR2 в настоящее время настроены для выполнения взаимного перераспределения маршрутов между OSPF и EIGRP. Давайте взглянем на таблицы IP-маршрутизации этих магистральных роутеров. Обратите внимание, в приведенном выше примере, что с точки зрения роутера CTR2, лучший способ добраться до Сети 192.0.2.0 / 30 — это next-hop на следующий IP-адрес 192.0.2.5 (который является роутером OFF1). Это означает, что если бы роутер CTR2 хотел отправить трафик в сеть 192.0.2.0 /30, то этот трафик остался бы в пределах OSPF AS. Интересно, что процесс маршрутизации EIGRP, запущенный на роутере CTR2, также знает, как добраться до Сети 192.0.2.0 / 30 из-за того, что роутер CTR1 перераспределяет этот маршрут в Интересно, что процесс маршрутизации EIGRP, запущенный на роутере CTR2, также знает, как добраться до Сети 192.0.2.0 / 30 из-за того, что роутер CTR1 перераспределяет этот маршрут в EIGRP AS, но этот маршрут считается EIGRP External route. Поскольку EIGRP External route AD 170 больше, чем OSPF AD 110, в OSPF маршрут прописывается в таблице IP-маршрутизации роутера CTR2. Именно так обычно работает Route redistribution, когда у нас есть несколько роутеров, выполняющих перераспределение маршрутов между двумя автономными системами. Однако, что мы можем сделать, если что-то идет не так, как ожидалось (или как мы хотели)? Как мы можем предотвратить перераспределение маршрута, перераспределенного в AS, из этого AS и обратно в исходное AS, например, в примере, показанном на следующем рисунке. В приведенном выше примере роутер OFF1 объявляет сеть 192.168.1.0 / 24 роутеру CTR1, который перераспределяет этот маршрут из AS1 в AS2. Роутер OFF2 получает объявление маршрута от роутера CTR1 и отправляет объявление для этого маршрута вниз к роутеру CTR2. Роутер CTR2 затем берет этот недавно изученный маршрут и перераспределяет его от AS2 к AS1, откуда он пришел. Мы, скорее всего, не хотим, чтобы это произошло, потому что это создает неоптимальный маршрут. Общий подход к решению такой проблемы заключается в использовании route map в сочетании с tag (тегом). В частности, когда маршрут перераспределяется из одного AS в другой, мы можем установить тег на этом маршруте. Затем мы можем настроить все роутеры, выполняющие перераспределение, чтобы блокировать маршрут с этим тегом от перераспределения обратно в его исходный AS, как показано на следующем рисунке. Обратите внимание, что в приведенной выше топологии, когда маршрут перераспределяется от AS1 к AS2, он получает тег 10. Кроме того, роутер CTR2 имеет инструкцию (настроенную в карте маршрутов), чтобы не перераспределять любые маршруты из AS2 в AS1, которые имеют тег 10. В результате маршрут, первоначально объявленный роутером OFF1 в AS1, никогда не перераспределяется обратно в AS1, тем самым потенциально избегая неоптимального маршрута. Далее давайте еще раз рассмотрим, как мы можем настроить этот подход к тегированию, используя следующую топологию. В частности, на роутерах CTR1 и CTR2 давайте установим тег 10 на любом маршруте, перераспределяемом из OSPF в EIGRP. Затем, на тех же самых роутерах, мы предотвратим любой маршрут с тегом 10 от перераспределения из EIGRP обратно в OSPF. Для начала на роутере CTR1 мы создаем карту маршрутов, целью которой является присвоение тегу значения 10. CTR1 # conf term CTR1 (config) # route-map TAG10 CTR1 (config-route-map) # set tag 10 CTR1 (config-route-map) #exit CTR1 (config) # Обратите внимание, что мы не указали permit как часть инструкции route-map, и мы не указали порядковый номер. Причина в том, что permit — это действие по умолчанию, и карта маршрута TAG10 имела только одну запись. Далее мы перейдем к роутеру CTR2 и создадим карту маршрутов, которая предотвратит перераспределение любых маршрутов с тегом 10 в OSPF. Кроме того, мы хотим, чтобы роутер CTR2 маркировал маршруты, которые он перераспределяет из OSPF в EIGRP со значением тега 10. Это означает, что мы хотим, чтобы роутер CTR1 предотвратил перераспределение этих маршрутов (со значением тега 10) обратно в OSPF. Итак, пока мы находимся здесь на роутере CTR1, давайте настроим route-map, которая предотвратит Route redistribution со значением тега 10 в OSPF. CTR1 (config) # route-map DENYTAG10 deny 10 CTR1 (config-route-map) # match tag 10 CTR1 (config-route-map) # exit CTR1 (config) # route-map DENYTAG10 permit 20 CTR1 (config-route-map) # end CTR1 # Эта недавно созданная route-map (DENYTAG10) использует ключевые слова permit и deny, и у нее есть порядковые номера. Порядковый номер 10 используется для запрещения маршрутов с тегом 10. Затем имеем следующий порядковый номер (который мы пронумеровали 20), чтобы разрешить перераспределение всех других маршрутов. Теперь, когда мы создали наши две карты маршрутов, давайте применим TAG10 route map к команде EIGRP redistribute (к тегу routes, перераспределяемому в EIGRP со значением 10). Кроме того, мы хотим применить DENYTAG10 route map к команде OSPF redistribute (чтобы предотвратить перераспределение маршрутов, помеченных значением 10, обратно в OSPF AS). CTR1 # conf term CTR1 (config) # router eigrp 100 CTR1 (config-router) # redistribute ospf 1 route-map TAG10 CTR1 (config-router) # router ospf 1 CTR1 (config-router) # redistribute eigrp 100 subnets route-map DENYTAG10 CTR1 (config-router) # end CTR1 # Теперь нам нужно ввести зеркальную конфигурацию на роутере CTR2. CTR2#conf term CTR2(config)#route-map TAG10 CTR2(config-route-map) # set tag 10 CTR2(config-route-map) # exit CTR2(config)#route-map DENYTAG10 deny 10 CTR2(config-route-map) # match tag 10 CTR2(config-route-map) # exit CTR2(config) # route-map DENYTAG10 permit 20 CTR2(config-route-map) # exit CTR2(config) # router eigrp 100 CTR2(config-router) # redistribute ospf 1 route-map TAG10 CTR2(config-router) # router ospf 1 CTR2(config-router) # redistribute eigrp 100 subnets route-map DENYTAG10 CTR2(config-router) # end CTR2# Просто чтобы убедиться, что наши маршруты помечены, давайте проверим таблицу топологии EIGRP роутера OFF2. Обратите внимание, что все маршруты, перераспределенные в EIGRP из OSPF, теперь имеют тег 10, и мы сказали роутерам CTR1 и CTR2 не перераспределять эти маршруты обратно в OSPF. Именно так мы можем решить некоторые потенциальные проблемы, возникающие при перераспределении маршрутов. Дело за малым - прочитайте нашу статью про route redistribution с помощью IPv6.
img
В статье мы попытаемся разобраться в том, что такое Ephone и Ephone-DN в CME (CUCME) , в чем их отличие и как с ними работать. Если описать все в двух словах, то для CME Ephone это телефонный аппарат, а Ephone-DN это телефонный номер. А теперь рассмотрим это подробнее. Настройка Ephone-DN Ephone-DN в простом представлении это телефонный номер (Directory Number), который может быть назначен на одну или несколько кнопок IP телефона Cisco. Каждый созданный ephone-dn можно настроить в режиме single-line или dual-line. Вот в чем разница: Single-line ephone-dn: в этом режиме ephone-dn может одновременно посылать и принимать только один вызов. Если звонок приходит на ephone-dn, который уже учавствует в разговоре, то вызывающий абонент услышит сигнал “занято” Dual-line ephone-dn: в этом режиме телефон может управиться с двумя одновременными вызовами. Это полезно для функций консультативного трансфера, конференций и функции ожидания вызова. Обычно dual-line используется для IP-телефонов пользователей, а single-line для сетевых функций, таких как интерком или пейджинг. Рассмотрим конфигурацию этих двух вариантов: CME#conf t – вход в режим конфигурации CME(config)#ephone-dn 1 – создание ephone-dn c меткой 1 (метка используется при привязке к ephone, ограничивается параметром max-dn) CME(config-ephone-dn)# number 1000 – указание номера (до 16 цифр) CME(config-ephone-dn)#exit – выход в предыдущее меню CME(config)#ephone-dn 2 dual-line – создание ephone-dn в режиме dual-line CME(config-ephone-dn)#number 1001 – указание номера Новые версии IOS поддерживают конфигурацию octo-line, которая включает поддержку восьми звонков на линии. Такая конфигурация можно использоваться для телефонов на ресепшене, shared lines (когда много людей используют один и тот же номер) или как ресурс конференции. Также при создании ephone-dn можно указать дополнительный номер, используя команду secondary, например для приема вызовов с ТфОП используя DID(Direct Inward Dial) . CME(config)#ephone-dn 2 dual-line CME(config-ephone-dn)#number 1001 secondary 849964919131001 Настройка Ephone Ephone представляет собой конфигурацию, которая применяется к определенному IP-телефону Cisco или софтфону. Для добавления телефона необходимо ввести команду ephone, затем метку (метка ограничивается параметром max-ephones), после чего мы провалимся в раздел конфигурации ephone, где нужно логически связать ephone-dn с физическим IP телефоном, который он представляет. Для этого используется MAC-адрес телефона Cisco, узнать можно который тремя способами: он написан на коробке из под телефона, он написан на задней панели самого телефона и его можно найти в настройках самого телефона в меню настроек. Рассмотрим пример: CME(config)#ephone 1 – создание ephone с меткой 1 CME(config)#mac-address 0014.1c48.12ab – MAC-адрес телефона, с которым будет связан ephone 1 Связывание Ephone и Ephone-dn Теперь можно связать созданные Ephone и Ephone-dn, и делается это при помощи присваивания ephone-dn к физической кнопке телефона ephone . Синтаксис команды следующий: button [физическая кнопка] [разделитель] [метка ephone-dn] Например, рассмотрим пример, в котором мы присваиваем ephone-dn 2 на первую клавишу на телефоне ephone 1: CME(config)#ephone 1 – вход в меню настройки ephone CME(config-ephone)#button 1:2 – сопоставление ephone-dn с клавишей CME(config-ephone)#restart – перезагружает телефон, после чего он перекачивает конфигурационный файл с tftp сервера. Разделитель в виде двоеточия обозначает, что это будет обычный звонок. Существует несколько видов разделителей: : - обычный звонок, визуальная индикация включена b – звуковой сигнал (beep). Визуальная индикация на телефоне такая же, как и при обычном звонке f – функциональный звонок. Тип звонка отличается при внутренних и внешних вызовах m – режим мониторинга на общей линии (shared line). Индикатор состояния линии показывает, используется ли линия. Может использоваться как быстрый набор для просматриваемой линии. Отсутствует возможность принимать звонки. w – режим просмотра для всех линий, у которых этот номер является основным s – тихий звонок, подавляет звуковые сигналы и звук ожидания вызова для этой линии. Визуальная индикация такая же, как и при обычном звонке. Выглядеть это будет так: На телефон можно назначить несколько линий, путем ввода нескольких команд button в режиме конфигурации ephone. Для проверки можно использовать команду show ephone: CME# show ephone ephone-1 Mac:0014.1c48:12ab TCP socket: [5] activeLine:0 REGISTERED in SCCP ver 8 and Server in ver 8 mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 caps:7 IP: 192.168.1.6 14719 7912 keepalive 2702 max_line 2 dual-line button 1: dn 2 number 1001 CH1 IDLE CH2 IDLE button 2: dn 1 number 1000 CH1 IDLE
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59