Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
Скажите, как заставить сипфон на компьютере сделать исходящий звонок из браузера? Никак? Совершенно верно.
Имеется ввиду программный сипфон? Почему же никак не сделать. Включить обработку ссылок sip/phone/callto (sip:79123456789). Другое дело что не все софтфоны обрабатывают такие ссылки. У нас именно так построена работа по исходящим звонкам.
У нас не только ручные звонки, иногда нужно позвонить автоматически на группу номеров, прежде чем оператор начнет обработку данных.
Также планируется predictive, но это уже больше история со входящими, чем с ненастоящими исходящими.
Также планируется predictive, но это уже больше история со входящими, чем с ненастоящими исходящими.
> Скажите, как заставить сипфон на компьютере сделать исходящий звонок из браузера? Никак? Совершенно верно
Вам про одно вы несколько про другое. Ваша фраза про «невозможность исходящих звонков из браузера» ложна. Месяца два назад перевели коллцентр с «копипасть номер — открывай программку вставь и нажми звонить», на кликни в вебинтерфейсе на телефон и говори. Два разных колцентра, в одном линфон в другом x-lite. У второго из коробки работает интеграцию для звонков при клике по ссылкам «sip:7xxxx». Для линфона пришлось писать reg-файлик с правильными путями.
И уже два месяца коллцентр в москве и львове кликает по ссылкам и совершают «исходящие звонки».
Не вводите людей в заблуждения
Вам про одно вы несколько про другое. Ваша фраза про «невозможность исходящих звонков из браузера» ложна. Месяца два назад перевели коллцентр с «копипасть номер — открывай программку вставь и нажми звонить», на кликни в вебинтерфейсе на телефон и говори. Два разных колцентра, в одном линфон в другом x-lite. У второго из коробки работает интеграцию для звонков при клике по ссылкам «sip:7xxxx». Для линфона пришлось писать reg-файлик с правильными путями.
И уже два месяца коллцентр в москве и львове кликает по ссылкам и совершают «исходящие звонки».
Не вводите людей в заблуждения
Да, думаю я был не точен в формулировке.
Если так: «Скажите, как заставить сипфон на компьютере сделать исходящий звонок на список номеров из браузера »?
Если так: «Скажите, как заставить сипфон на компьютере сделать исходящий звонок на список номеров из браузера »?
Если я вас правильно понял то вот так:
создаете ссылку на странице
потом на компе оператора коллцентра нужно зарегать обработчик для ссылок вида «sip:xxx», X-lite сам при установке пишет в реестр нужные параметры. Линфон тоже пишет, но он там лажает с кавычками в путях и при кликах по таким ссылкам ниче не запускается
лечится сменой в реестре настроек на «правильные»
вот для Linphone:
Win64 gist.github.com/mekegi/8019206 Win32 gist.github.com/mekegi/7951345
П.С. hostname_or_ip прописать тот который в настройках сип клиентов (если вбивать номер в сипклиент вручную то звонки идут, а вот при клике приходится прописывать и хост, по крайней мере с нашими сипклиентами была такая особенность)
создаете ссылку на странице
<a href="sip:89115551111@hostname_or_ip">call via sip</a>
потом на компе оператора коллцентра нужно зарегать обработчик для ссылок вида «sip:xxx», X-lite сам при установке пишет в реестр нужные параметры. Линфон тоже пишет, но он там лажает с кавычками в путях и при кликах по таким ссылкам ниче не запускается
лечится сменой в реестре настроек на «правильные»
вот для Linphone:
Win64 gist.github.com/mekegi/8019206 Win32 gist.github.com/mekegi/7951345
П.С. hostname_or_ip прописать тот который в настройках сип клиентов (если вбивать номер в сипклиент вручную то звонки идут, а вот при клике приходится прописывать и хост, по крайней мере с нашими сипклиентами была такая особенность)
Я немного о другом говорил.
Вот есть, например, клиент. У него больше одного телефона. Мы должны последовательно прозвонить все до первого ответа (у нас же цель не позвонить на конкретный номер, а дозвониться).
Желательно начинать с мобильного (это можно и в ручном режиме элементарной сортировкой выводимых оператору телефонов решить).
Насколько я знаю (может и ошибаюсь), оператор, кликая по ссылкам вида «sip/callto/phone» сможет вручную только последовательно перебрать номера.
А необходимо, чтобы оператор нажал «позвонить» один раз и пошел вызов на список номеров со стороны АТС, либо вообще не нажимал, а отправка команды при неком событии вызывалась.
Очевидный бонус при наборе номеров «пачкой» — оператор не тыкает поочередно по номерам, а изучает необходимую информацию, пока АТС пытается дозвониться.
Вот есть, например, клиент. У него больше одного телефона. Мы должны последовательно прозвонить все до первого ответа (у нас же цель не позвонить на конкретный номер, а дозвониться).
Желательно начинать с мобильного (это можно и в ручном режиме элементарной сортировкой выводимых оператору телефонов решить).
Насколько я знаю (может и ошибаюсь), оператор, кликая по ссылкам вида «sip/callto/phone» сможет вручную только последовательно перебрать номера.
А необходимо, чтобы оператор нажал «позвонить» один раз и пошел вызов на список номеров со стороны АТС, либо вообще не нажимал, а отправка команды при неком событии вызывалась.
Очевидный бонус при наборе номеров «пачкой» — оператор не тыкает поочередно по номерам, а изучает необходимую информацию, пока АТС пытается дозвониться.
И тем не менее сип-ссылки это лучше чем просто текст.
Насчет последовательного прозвона. У нас есть тоже примерно такая же запланированная фича, где у операторов будет страница с одной кнопкой «позвонить», оператор кликает на нее, а дальше уже мы на сервере через апи поставщика сипуслуг (у нас нет своих астериксов, мы пользуемся услугами сторонней фирмы) начинаем попытки дозвона до клиентов (у каждого несколько телефонов, и клиенты и телефоны ранжированы по приоритету)
ну и когда мы дозваниваемся то идет редирект на страницу заказа конкретного клиента, при этом идет вызов и на самого оператора. Т.е. в такой схеме для оператора выходит что это «входящий звонок».
Естественно никакой сипклиент установленный на компе не сможет такого, да и не нужно ему это.
Разные инструменты для разных задач.
Насчет последовательного прозвона. У нас есть тоже примерно такая же запланированная фича, где у операторов будет страница с одной кнопкой «позвонить», оператор кликает на нее, а дальше уже мы на сервере через апи поставщика сипуслуг (у нас нет своих астериксов, мы пользуемся услугами сторонней фирмы) начинаем попытки дозвона до клиентов (у каждого несколько телефонов, и клиенты и телефоны ранжированы по приоритету)
ну и когда мы дозваниваемся то идет редирект на страницу заказа конкретного клиента, при этом идет вызов и на самого оператора. Т.е. в такой схеме для оператора выходит что это «входящий звонок».
Естественно никакой сипклиент установленный на компе не сможет такого, да и не нужно ему это.
Разные инструменты для разных задач.
Буквально на той неделе закончил подобную задачу по дозвону в 1 клик. правда мы использовали AMI как более подходящий для таких целей интерфейс. Asterisk работает в Realtime режиме, так что всё завязано на базе данных. Все просто:
Делаю выборку из базы через диалплан по количеству номеров для данного абонента. Затем прозваниваем каждый номер получая ${DIALSTATUS}. В зависимости от результата делаем нужные действия.
От AGI отказались сразу: очень сильно нагружает систему. Лучше уж FastAGI на отдельной машине использовать. Но если есть возможность делать через AMI. Далее. Учитывая задачи WebSocket использовать не очень целесообразно. так как сам звонок все равно проходит через аппарат. Другое дело если бы это был webphone, но это совсем отдельная тема требующая отдельного поста. потом напишу обязательно о своих приключениях с ним.
Делаю выборку из базы через диалплан по количеству номеров для данного абонента. Затем прозваниваем каждый номер получая ${DIALSTATUS}. В зависимости от результата делаем нужные действия.
От AGI отказались сразу: очень сильно нагружает систему. Лучше уж FastAGI на отдельной машине использовать. Но если есть возможность делать через AMI. Далее. Учитывая задачи WebSocket использовать не очень целесообразно. так как сам звонок все равно проходит через аппарат. Другое дело если бы это был webphone, но это совсем отдельная тема требующая отдельного поста. потом напишу обязательно о своих приключениях с ним.
Да, хорошее решение.
Мы были связаны сроками и наработками от сторонних интеграторов, вполне возможно что в будущем систему доработаем.
У нас операторы на софтфонах сидят, а не на физических аппаратах.
Мы были связаны сроками и наработками от сторонних интеграторов, вполне возможно что в будущем систему доработаем.
У нас операторы на софтфонах сидят, а не на физических аппаратах.
Скажите, а что за CRM систему используете?
Какая у вас версия астериска используется?
Короткий комментарий, хотя может и до целой статьи созрею в конце концов.
Вот какие методы интеграции с Asterisk используем мы у себя при разработке RegionSoft CRM:
1. Для инициализации звонков с клиентской стороны (если менеджер использует железный телефон) наиболее стабильно работает метод AMI ORIGINATE. Если Ваша CRM не десктопная, можно использовать AJAM — команды полностью аналогичны.
2. Для инициализации звонков со стороны сервера можно использовать метод call-файлов, но как и AGI, он приемлем только для локальной работы внутри сервера. Впрочем, это никак не мешает создать скрипт, дергаемый, например, по HTTP и создающий эти самые call-файлы.
3. Для автоматической маршрутизации в самых простых случаях можно использовать func_odbc внутри диал-плана стандартного маршрута, но если логика не сводится к простому select'у из базы, лучше использовать AGI-скрипт.
4. Отслеживание входящих и подъем можно реализовать, написав монитор линии, который слушает AMI или AJAM с фильтром по конкретной линии, но работает это не так стабильно, как хотелось бы — поэтому в стандартном случае мы просто используем встроенный в RegionSoft CRM софтфон (выходит в релизе 5.0), а с AMI/AJAM работаем только, если клиент хочет работать с «железными» телефонами.
Запись разговоров с встроенным софтфоном сильно облегчает жизнь, потому как во варианте с использованием AMI/AJAM нужно постоянно дергать БД CDR, что не есть хорошо.
Вот какие методы интеграции с Asterisk используем мы у себя при разработке RegionSoft CRM:
1. Для инициализации звонков с клиентской стороны (если менеджер использует железный телефон) наиболее стабильно работает метод AMI ORIGINATE. Если Ваша CRM не десктопная, можно использовать AJAM — команды полностью аналогичны.
2. Для инициализации звонков со стороны сервера можно использовать метод call-файлов, но как и AGI, он приемлем только для локальной работы внутри сервера. Впрочем, это никак не мешает создать скрипт, дергаемый, например, по HTTP и создающий эти самые call-файлы.
3. Для автоматической маршрутизации в самых простых случаях можно использовать func_odbc внутри диал-плана стандартного маршрута, но если логика не сводится к простому select'у из базы, лучше использовать AGI-скрипт.
4. Отслеживание входящих и подъем можно реализовать, написав монитор линии, который слушает AMI или AJAM с фильтром по конкретной линии, но работает это не так стабильно, как хотелось бы — поэтому в стандартном случае мы просто используем встроенный в RegionSoft CRM софтфон (выходит в релизе 5.0), а с AMI/AJAM работаем только, если клиент хочет работать с «железными» телефонами.
Запись разговоров с встроенным софтфоном сильно облегчает жизнь, потому как во варианте с использованием AMI/AJAM нужно постоянно дергать БД CDR, что не есть хорошо.
Правильный подход)
Спасибо.
По п.4 скажу, что при входящих вариант с сокетом лично мне кажется удобнее и изящнее любого AJAX-варианта в силу того, что он (веб-сокет) событийный, а AJAX / Lazy AJAX менее стабильный ИМХО.
С другой стороны управлять интерфейсом событийно через веб-сокет, который тоже работает событийно с астериском — тоже задача требующая очень внимательного отношения к возможным вариантам развития событий, коих больше, чем в AJAX. Хотя бы потому что даже в «асинхронном» запросе мы знаем, что отправили запрос и нам точно что-то придет, причем в определенной последовательности, а с работой через веб-сокет никто такой гарантии не даст.
По п.4 скажу, что при входящих вариант с сокетом лично мне кажется удобнее и изящнее любого AJAX-варианта в силу того, что он (веб-сокет) событийный, а AJAX / Lazy AJAX менее стабильный ИМХО.
С другой стороны управлять интерфейсом событийно через веб-сокет, который тоже работает событийно с астериском — тоже задача требующая очень внимательного отношения к возможным вариантам развития событий, коих больше, чем в AJAX. Хотя бы потому что даже в «асинхронном» запросе мы знаем, что отправили запрос и нам точно что-то придет, причем в определенной последовательности, а с работой через веб-сокет никто такой гарантии не даст.
Касательно записи разговоров — а есть ли варианты, каким образом сливать все записи, ибо:
1. Нужно хранить _все_ записи разговоров (годами)
2. Нужно иметь возможность оперативно прослушать разговор в течение пары минут после его окончания (т.е. за эти пару минут нужно сделать копирование, конвертацию и т.д.).
1. Нужно хранить _все_ записи разговоров (годами)
2. Нужно иметь возможность оперативно прослушать разговор в течение пары минут после его окончания (т.е. за эти пару минут нужно сделать копирование, конвертацию и т.д.).
1.На каждом extension'е включаем запись звонков (чаще всего у клиента стоит Asterisk уже в паре с FreePBX) -> как результат, получаем поле recording в cdr-таблице Asterisk'а.
2. Натравливаем самбу на /var/spool/asterisk/monitor/ — теперь мы можем получить запись к файлам записей
3. Фильтруем CDR-таблицу как нам надо. Дергаем нужный нам файл по сетевой шаре.
0. Не забываем, что дисковое место может кончиться и ставим большой хард под /var/spool/asterisk/monitor/
2. Натравливаем самбу на /var/spool/asterisk/monitor/ — теперь мы можем получить запись к файлам записей
3. Фильтруем CDR-таблицу как нам надо. Дергаем нужный нам файл по сетевой шаре.
0. Не забываем, что дисковое место может кончиться и ставим большой хард под /var/spool/asterisk/monitor/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интеграция телефонии в распределенных колл-центрах