В процессе работы "Фриланс", мне несколько раз попалось ТЗ, в котором меня просили как-то более "интеллектуально" автоматизировать входящие звонки.

После третьего или четвертого ТЗ, я понял, что с этим что-то нужно делать. Так родилось мое собственное техническое задание:

1. Наименование программы

Наименование программы: "База маршрутизации входящих звонков"

2. Назначение и область применения

Программа предназначена для работы совместно с программно-аппаратным комплексом Asterisk (далее ПАКА).

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

Как дополнительный функционал, база данных должна хранить базу данных клиентов и содержать следующие основные данные:

• 2.1. Ф.И.О. пользователей системы (либо идентификатор).
• 2.2. Список CID, с которых может позвонить клиент (до 4-х).
• 2.3. Поле заметок (дополнительные данные о клиенте)
• 2.4. Возможность проведения статистических анализов (статистика базы)
• 2.5. Данные администраторов системы, с делегированием прав.
• 2.6. Данные групп пользователей системы , с привязкой к последующей маршрутизации
• 2.7. Данные возможных маршрутов (назначений звонка), с привязкой к группам пользователей

Так как база планируется, в основном, для использования в качестве базы маршрутизации в службах такси, должна быть возможность хранения в базе дополнительных данных:

• 2.8. Дата рождения.
• 2.9. Позывной водителя.
• 2.10. Марка автомобиля.
• 2.11. Цвет автомобиля.
• 2.11. Номер автомобиля.

Программа предоставляет Веб-интерфейс для управления содержимым базы данных в соответствии с предъявляемыми требованиями по протоколу http.

3.Требования к функциональным характеристикам

Программа должна обеспечивать возможность выполнения перечисленных ниже функций:

3.1. Разделение администраторов, подключаемых через Веб-интерфейс на группы (с делегированием прав под каждую группу):

• 3.1.1. admin
• 3.1.2. BOSS
• 3.1.3. menedger
• 3.1.4. View

Должна быть возможность быстрого добавления (редактирования групп). Также, должна присутствовать возможность изменения прав групп на то- либо иное действие (возможно через ini файлы).

3.2. Разделение пользователей, позвонивших на вход ПАКА по группах (и, соответственно, маршрутизация звонка на основании выбранной группы ):

• 3.2.1. VIP Клиенты
• 3.2.2. Простые клиенты
• 3.2.3. Администрация
• 3.2.4. Белый список
• 3.2.5. Черный список
• 3.2.6. Другое
• 3.2.7. Водителя

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

3.3. Возможность поиска (фильтрации) по базе данных информации

В процессе внедрения ее в реальных условиях, ТЗ немного пополнилось и "обросло" дополнительным задачами:

4.Должен присутствовать билинг

Собственно, полного билингования с расчетом оставшихся потраченных минут не нужно, но часть заказчиков хотели бы иметь возможность ставить определенное количество минут пользователю, которые он смог бы потратить на разговоры через DISA, или на другие сервисы.

Должна быть возможность хранения этого параметра в базе дополнительных данных, с жесткой привязкой к клиенту.

Ну и, соответственно, должна быть возможность редактирования количества этих свободных минут нескольким пользователям одновременно.

6. Расширенные отчеты

Наличие п5 повлекло за собой необходимость отчета о потраченных минутах с возможностью фильтрации по:

• 6.1. Дате
• 6.2. Источнику (пользователю)
• 6.3. Назначению (куда звоним)
• 6.4. Контексту (опционально)
• 6.5. Группе (опционально)

7. Графики востребованности

Также, было бы неплохо иметь возможность визуального отображения загруженности (востребованности) этого сервиса (в виде графика) с распределением по:

• 7.1. Дням
• 7.2. Неделям
• 7.3. Месяцам
• 7.4. Годам

8. Уведомления

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

В уведомлениях должна быть обязательно дополнительная информация:

• 8.1. Ф.И.О или Идентификатор клиента
• 8.2. Группа, к которой принадлежит клиент
• 8.3. Назначение (дальнейший маршрут звонка)

очень желательно, чтобы данная информация отображалась за несколько мгновений до поступления звонка, чтобы оператор мог собраться и подготовиться к приему звонка.

Общие требования

Работа системы не должна быть привязана к операционной системе пользователя, либо эта привязка должна быть минимальна.

Система должна быть максимально лояльна к пользователю и к администратору.

Описание системы

Система делится на три части: серверная, клиентская и AGi. Каждая из частей независима и может работать автономно, соответственно, каждая отвечает за свой функционал. Клиентская или agi часть может повторяться на нескольких ПК, но работать они будут с единой базой.

Давайте рассмотрим более подробно каждую из частей.

Серверная часть

.Написана на PHP (c небольшими включениями javascript, для удобства пользователя ), всю основную информацию , а также и собственные настройки система хранит в Mysql. При написании базы, очень плотно был использован фреймворк "Codeigniter", собственно, возможности фреймворка легли в основу функциональности базы.

Система маршрутизации звонков имеет три клиентские базы данных для сохранения дынных клиентов,

красную, зеленую и белую. Привязка к цвету достаточно тривиальна: их просто как-то нужно было обозвать, не более того.

В каждой из баз хранятся клиенты, принадлежащие к разным группам. Разные администраторы (операторы) системы имеют разные права на каждую из баз. Большее количество баз, как раз и связано с необходимостью разграничения прав операторов.

Скрины системы:

Авторизация базы данных (красная, белая, зеленая.)

Вхождения групп в базы настраивается в ini файле. Также, вполне подлежит настройке количество групп и назначение (дальнейший маршрут) звонка. Также, хорошо видно, что в зеленой базе данных присутствуют дополнительные поля (см п. ТЗ 2.8-2.11).

Добавление пользователя, выбор базы, группы. Группы клиентов, присутствующих в системе. Поиск по категориям.

Редактирование. База администраторов с разграничением прав. Вывод ошибок.

На втором скрине хорошо видно, что каждый администратор системы может принадлежать одной или нескольким группам. Разрешение на то- либо иное действие в базе привязывается к группе. Два последние скрина демонстрируют отслеживание ошибок операторов базы- база не даст сохранить нового клиента до момента, пока все необходимые поля не будут заполнены верно. При попытке удаления пользователя система требует подтверждение.

Лог системы, выставление лимитов, билинг.

Каждое изменение в системе отображается в логе. Лог содержит минимальное количество полей, но этого, в большинстве случаев, достаточно. Лимиты свободных минут можно ставить, как в каждом поле отдельно, так и в поле слева - для всех отображенных пользователей (понятно, что необходимых пользователей можно отфильтровать с помощью фильтров слева сверху.)

Билинг минимальный позволяет увидеть кто звонил, в каком направлении, сколько минут из запаса потрачено.

Графики востребованности .

Первые два скрина - графики востребованности распределение по количеству звонков с масштабированием по днях, неделях. Два последних - то же самое, только с распределением по длительности звонков (в сек). Также, доступно масштабирование по месяцу, году.

Клиентская часть:

Состоит из двух программ, первая утилита snarl, отвечающая за формирование небольших уведомлений в правом нижнем (по умолчанию, настраивается) углу экрана. Вторая, более специализированная утилита, которая умеет взаимодействовать с утилитой snarl и передает ей текст уведомления. Собственно, AGI часть системы как раз взаимодействует с второй утилитой.

Останавливаться более глубоко на данной части не буду - нет смысла, в случае заказа, устанавливать ее буду я. А в свободном распространении базы маршрутизации звонков пока не будет.

Выглядит это все следующим образом:

Текст и поля уведомления - настраиваются.

AGI часть:

Тому, кто в курсе, что такое Agi, объяснять нет надобности, кто нет - скорее всего, оно ему и не нужно, работает - ну и ладненько, как говорится, главное результат.

в двух словах - AGI часть скрипта состоит, минимум, из двух частей: собственно, agi скрипта и небольшого класса, написанного мной на PHP. Первый, встраивается в диаплан asterisk, второй - обеспечивает нужный функционал для работы с базой. Также, за вторым остается генерация необходимых логов в консоль asterisk (достаточно немаловажная часть, кто сталкивался - поймет).

Файлов, как я уже говорил, может быть несколько - по количеству мест в диаплане, в который он встраивается.

Еще одним моментом, на котором стоит остановиться есть то, что в назначении каждой группы есть три поля назначения (смотри скрин, где показаны группы) , поля условно разделены на Город, мобильный и цифра. Сделано это умышлено для увеличения гибкости системы. Один скрипт, в зависимости от источника откуда пришел звонок, может отрабатывать ту- либо иную группу по-разному. Сейчас это звучит немного сложно, но посмотрев примеры внедрения, я думаю, вы поймете о чем идет речь.

Пример самого простого внедрения моего скрипта в диаплан представлен ниже.

[agi-checkgroup_digital]                                                                                                        
exten => s,1,NoOp                                                                
exten => s,n,Macro(user-callerid,)                                                                                              
exten => s,n,Set(CHANNEL(language)=ru)                                                                                          
exten => s,n,GotoIF($[${CALLERID(number)}=anonymous]?other)                                                                          
# переход по дефолту                                                                                                            
exten => s,n,Set(FWD_CONTEXT=ivr-4)                                                                                             
exten => s,n,Set(FWD_APP=s)                                                                                                     
exten => s,n,Set(FWD_TO=1)                                                                                                      
exten => s,n,AGI(agi-checkgroup_digital.agi)                                                                                    
exten => s,n,Goto(${FWD_CONTEXT},${FWD_APP},${FWD_TO})                                                                          
#усли номер не определился                                                                                                      
exten => s,n(other),Goto(ivr-4,s,1)                                                        
exten => s,n,Hangup

Принцип работы :

Основой работы системы есть AGI скрипт, который взаимодействует с системой mysql и вытягивает из последней нужную информацию и, в зависимости от ее наличия, маршрутизирует звонок по нужному направлению.

Также, в обязанности скрипта входит уведомление администраторов системы о том, какой звонок поступил и по какому маршруту он смаршрутизирован.

Давайте более подробно рассмотрим принцип маршрутизации, это наиболее важно в данной системе.

Входящий звонок поступает на вход asterisk системы, точнее в специальный контекст диаплан. Диаплан проверяет звонок на валидность, также, смотрит поле CID, если поле не пустое, то передает управление на AGI скрипт. В случае, если поле отсутствует или звонок пришел со скрытого номера - отправляется по маршруту по умолчанию.

Далее есть возможность внести вариацию на счет устройства, с которого пришел номер (поле DID) и, в зависимости от поля, выбрать поле базы для дальнейшего маршрута (выше по тексту я упоминал о полях "цифра", "город", и "мобильный"). Если же у вас только один вариант прихода звонка (например в системе только один trank ), либо этот функционал вас не интересует, данную маршрутизацию не используем.

Agi скрипт вытягивает из переменных канала поле CID, опять проверяет его на соответствие количества символов, если все верно идет в базу и проверяет, есть ли такой номер в базе. Дальше опять же два варианта - если номера нет в базе, отправляем по дефолтному маршруту данного направления (опять же, если есть деление по направлениях прихода звонка) или просто по дефолтному маршруту.

В случае, если же номер телефона присутствует в базе, вытягиваем из базы дополнительные поля: ФИО клиента, группу, в которой он состоит и маршрут для группы (опять же, маршрутов может быть три в зависимости от направления звонка). Далее контексту asterisk передается дальнейший маршрут для данного звонка, а на ПК администратора (операторов) шлется уведомление.

И управление возвращается на dialplan asterisk.

Вкратце все звучит немного запутано, но проще объяснить не могу.

Примеры внедрения :

Пример 1: call сентр (служба такси)

Задачи тут не сложные, но зачастую трудно реализуемые средствами классической офисной АТС.

• Принять звонок
• Определиться, к какой группе относится позвонивший
• Смаршрутизировать звонок на менеджера (оператора), отвечающего за данное направление
• Уведомить менеджера (оператора) о том, кто звонит, возможно, к какой группе принадлежит позвонивший (если один менеджер отвечает за несколько направлений).
• Как дополнительный функционал, иногда нужен черный или белый список. Первый не дает дозвониться клиентам, входящим в данную группу, второй - ставит их приоритетно на первое место в очереди, либо маршрутизирует на отдельного менеджера.

Принцип работы простой, администратор вносит во время работы клиентские телефоны в базу системы, привязывает их к определенной группе. Agi скрипт во время звонка просматривает эти записи, маршрутизирует звонок.

Пример 2: Callback сервер

В последнее время каждая, уважающая себя, небольшая фирма делает Callback центры для экономии средств своих сотрудников. Да, это, зачастую, стоит на грани законности, и т. д (это не в ходит в рамки обсуждения этой статьи). Но, думаю, ситуация будет иметь место до тех пор, пока мобильные, или не "сильно мобильные" операторы, будут пытаться привязать своих клиентов к своим сетям, играя на ценовой политике.

Принцип работы, зачастую, прост: ставится сервер с фулом GSM шлюзов, в разные порты которого всовываются sim карты разных провайдеров. Также, к серверу подключаются несколько местных провайдеров, возможно, пару зарубежных.

На сервере настраивается определенная маршрутизация и DISA, так званый, авто секретарь, который дает прямой доступ к ресурсам системы.

Работает это все следующим образом: сотрудник компании звонит на определенный номер фула телефонов сервера, последний проверяет на валидность номер, отбивается и перезванивает. Сотрудник, сняв трубку при входящем звонке, слышит в телефоне гудок - приглашение набрать номер, набирает его с клавиатуры через DTMF, сервер соединяет последнего с набранным номером уже через другую gsm-карточку (другой trank), тариф звонка через который на это направление наиболее дешевый.

Безопасность звонков (запрет пользоваться системой если вы не сотрудник компании) обеспечивается, в основном, тремя путями:

• Номер фула номеров сообщается только сотрудникам, другие о нем не знают.
• На DISA ставится пароль, который запрашивается в момент набора номера.
• Входящий звонок на DISA разрешен только нескольким, CID доступ которым обеспечивается на уровне dial Plan asterisk.

Недостатки каждого из методов понятны: номер телефона рано или поздно узнают все, причем часто его менять не вариант, при донаборе еще 4-5 цифр пароля, когда одной рукой нужно держать телефон, а второй номер, который набрать, да еще и не сбиться при этом, за короткое время, которое отведено DISA на набор, достаточно сложно. Третий вариант, вроде бы нормальный, но когда вы попытаетесь занести таким образом не десять сотрудников, а 30 - недостатки сразу станут понятны.

В этом месте я бы как раз и хотел презентовать свою базу - пример внедрения ее в качестве основы Callback сервера, не имеет недостатков описанных выше, к тому же имеет ряд преимуществ:

• 1. Понятное преимущество, относящееся к п3 недостатков - увеличение количества пользователей, не ведет к усложнению плана набора Asterisk (увеличение в разумных пределах до 10000 пользователей), AGI скрипту практически все равно, делает он выборку из базы, где 10 пользователей или где 1000, изменения времени выборки вы не заметите.
• 2. Также, понятно преимущество, относящееся к п1 недостатков. Номера фулов можно сообщать хоть "первому встречному", однако, доступ получат только те, номера телефонов (CID) коих есть в базе.
• 3. С третьим пунктом преимуществ не все так просто. Объяснить его сложнее. В п2 недостатков я говорил о пароле, который трудно набрать на коленке. Беда в том, что набрать номер, на который дозвонимся, также сложно- его, как минимум, нужно держать либо в памяти, либо перед глазами. Решение - по тексту ниже.

Достаточно серьезной проблемой при организации callback серверов есть неверные наборы, как раз по вине пользователя, если телефон сенсорный или клавиатура неудобная - наборы двоятся, троятся и т. д.

Идеальным решением была бы возможность запоминать подобные наборы в телефонную книгу аппарата. Современные "мобилки" дают возможность запомнить в наборе до 25 а то и более символов, но, как говорится, "не все так просто". Оператор связи никогда не пропустит через свою сигнализацию номер с количеством цифр, отличающихся от количества принятого в номерном плане его сети.

Но решение нашлось: посмотрите на картинку слева. Вот такой номер вы без проблем сможете сохранить в памяти телефона и дозвониться на номер другой сети, как будто вы звоните по тарифам сети, в которой находитесь. Идея состоит в том, что, на самом деле, вы набираете только номер 0679999999 символ разделения говорит мобилке о том, что остальную часть номера нужно набирать в виде DTMF уже после снятия трубки на удаленной стороне. Понятно, что за то короткое время, пока мобилка ждет на удаленной стороне, должна пройти аутентификация пользователя, сервер должен снять трубку и активировать DISA для данного канала. В последнем вам очень поможет "база маршрутизации входящих звонков"

Имею реальный опыт долгих пререканий с клиентом, которому делал Callback сервер. Остро стояла проблема сбоев при наборе. После анализа логов было выявлено две проблемы: сбои при наборе через аналоговые шлюзы и неверные наборы.

После того, как шлюзы сменили на цифровые и я предложил ему вот такую систему с запоминанием номера в телефонной книге - клиент был просто счастлив.

Рекомендую к внедрению без ограничений - проверено на реальном опыте.

• 4. Ну и четвертым, но не самым последним, пунктом преимуществ есть возможность выставления лимита свободных минут для клиентов системы.

Понятно, что подобное возможно только, если использовать стороннее программное обеспечение - средствами asterisk это сделать невозможно. Я специально не делал полное билингование с подсчетом минут с ценами на направления, что казалось бы логичным. Такое уже сделано и давно используется - Abilling + модуль Callback к нему. Проблема в том, что сложность системы большая и, зачастую, не нужна. Уже сам факт осознания того, что у тебя не безлимитный, а минуты могут закончится - дает реальную экономию, видную на глаз.

Пример 3: Избранные

.

Часто, для особенных клиентов или сотрудников компании, нужно добавить какой-то дополнительный функционал, возможно, даже невидимый для остальных пользователей. Идеальным вариантом было бы, чтобы этот функционал был добавлен на существующей системе. Примером такого функционала может быть расширенное IVR меню. Для одних пользователей оно одно, для других - более широкое, например, дополнительные VIP пункты.

Принцип, по которому это организовывается - простой. Вместо ссылки на конкретный пункт в DialPlan, делается ссылка на AGI скрипт, который, в зависимости от CID звонка, перенаправляет работу DialPlan по разным направлениям.

И, как заключение, хочу сказать о том, что достаточно редко мои заказчики используют какое-то конкретное решение. Зачастую, примеры, которые я привел, пересекаются на одном сервере, причем, в нескольких местах Диалплана. Это совершенно не мешает им нормально работать.

Условия заказа :

До заказа этого решения, я бы хотел, чтобы вы продумали его реализацию и мне уже высылали свои мысли в виде небольшого технического задания. Особых требований к последнему нет - это может быть обычный текст на 1-2 страницы, в котором вы опишите, что уже сделано и что бы вы хотели получить.

Для заказа воспользуйтесь формой заказа.

С уважением, Свердло Вадим.