На работе появилась задача реализовать дозвон на внутренние номера организации. В качестве IP АТС у нас используется Cisco CallManager 4.2, а для колл-центра используется Customer Response Solutions 4.0 (IPCC). Для написания скрипта использовался Cisco Customer Response Solutions Editor, который поставляется вместе с CRS. За основу взят скрипт из пакета поставки редактора — aa.aef.
На данный момент скрипт уж очень простой и не содержит никаких голосовых приветствий, обработки различных событий (вроде сигнала «занято», неверно набранного номера). В дальнейшем я планирую его усовершенствовать до полноценного скрипта с приветствиями, запросами и всеми возможными проверками «на дурака». Сейчас опишу подробно, как сделать донабор номера.
Запускаем редактор и создаем новый скрипт.
Создадим две переменные: одна для хранения номера, другая — для запроса. Запрос у будет пустым, т.к. диалог требует присутствия этого параметра в настройках.
Теперь нужно добавить обработчики событий для входящего звонка. Вот такой получился скрипт:
По порядку пройдемся по основным элементам. Первый оператор Start по-умолчанию присутствует во всех скриптах и означает начало. Два последующих принимают вызов. Следующая функция Get Digit String позволяет получить от абонента набираемые цифры. Ее нужно настроить. После того, как вытащили ее с панели объектов в тело скрипта, нажмите на ней правой кнопкой мыши и выберите Properties. На первой вкладке General в списке Result Digit String выбираем переменную intNum. Далее на вкладке Prompt в списке Prompt выбираем переменную prompt. На вкладке Input вы можете настроить параметры получения цифр от абонента. Я оставил все по-умолчанию. И наконец, на вкладке Filter нужно задать количество цифр, которое будет ожидаться от абонента. Я выставил число 4 в поле Input Length, так как у меня четырехзначный внутренний номерной план.
Так как пока учитываем, что пользователь все ввел верно, добавляем функцию Call Redirect в условие Successful. Эта функция будет переадресовывать звонок на номер, который ввел абонент. Ее так же надо настроить. В свойствах Call Redirect в поле Destination выберите переменную intNum.
Добавляем в условие Successful функции Call Redirect функцию Set Contact Info. Нажимаем на ней ПКМ и в табличке Attributes напротив параметра Handled выбираем — Marked --. После добавляем оператор End. Это отметит звонок абонента как «обработанный» и завершит сессию.
В конце скрипта добавляем Terminate и End. На этом скрипт закончен. Сохраняем его на диске, после чего мы его зальем на сервер CRS.
Открываем админку CRS, выбираем пункт Script Management.
Перед нами список скриптов присутствующих в системе. Нужно добавить свой, только что созданный. Нажимайте на ссылку Upload New Scripts.
Выбирайте сохраненный скрипт и нажимайте кнопку Upload. Теперь, когда скрипт залит, нужно создать приложение. Приложение в CRS определяет скрипт, используемый JTAPI для обработки вызовов, а также задает начальные параметры для скрипта, если такие имеются.
Выбираем пункт Application Management.
Видим список имеющихся приложений в системе:
Нажимаем Add a New Application. В окошке появившемся в списке выбирайте Cisco Script Application.
Называем приложение как больше нравится. Я назвал его CityToInternal. Description — напишите что-то, что позволит вам в будущем вспомнить, зачем это приложение. ID — задается системой автоматически, но вы можете его поменять например на 666, если такое уже не занято другим приложением. Maximum number of sessions — максимальное количество звонков одновременно обрабатываемых приложением. Script — выбираем скрипт, в моем случае CTI.aef. Нажимаем Update.
Теперь нужно создать Media Termination Dialog Group. Медиа группы нужны для взаимодействия с абонентами, а именно для обработки DTMF тонов.
Выбираем пункт Cisco media.
Получаем список групп. Нажимаем Add a New CMT Dialog Control Group.
На появившейся странице задаем поля Description (что-нибудь, чтобы идентифицировать группу) и Maximum Number Of Channels (в моем случае 10). На самом деле под все приложения можно создать одну группу на 100 каналов, например. Но я предпочел разделить их.
Нажимаем Add и группа добавлена (на моем скриншоте Update, т.к. я скринил уже созданную группу).
Теперь выбираем пункт JTAPI и слева нажимаем на JTAPI Call Control Group. Нужно создать группу контроля вызова. Эта группа создаст необходимое количество CTI портов, на которые будет переадресовывать вызов абонента и уже с него активироваться приложение и наш скрипт.
Нажимаем Add a New JTAPI Call Control Group.
Заполняем поля. Group ID — заполняется системой автоматически, но вы опять же можете поставить что угодно, кроме уже используемых. Description — описание группы, поставьте что-то узнаваемое. Часто поля Description используются для отображения элементов в списках настроек, вместо ID. Number of CTI ports — я установил 10, это количество CTI портов, которое будет создано. Starting directory number — для этой группы потребуется 10 номеров и тут нужно указать номер первого порта (в моем случае 9980). Эти номера не должны быть назначены абонентам или Hunt-группам. Device name prefix — префикс для именование CTI портов. Device pool — выбрал Default. Media resource group list — выберите свой основной MRGL. Display — описание CTI портов, фактически то, что будет отображаться рядом с номером на экране телефона (Alerting name), когда CTI будет вам звонить. Жмем Add.
Теперь нужно создать триггер. Триггер — это некий номер, который абонент будет набирать, чтобы получить доступ к нашему приложению. Тот же пункт JTAPI, выбираем слева JTAPI Triggers. Видим список триггеров в системе.
Нажимаем Add a New JTAPI Trigger.
Directory number — номер, на котором будет активироваться наше приложение. Уточню, у меня указан 7-значный городской номер. Эти номера попадают на CCM с роутера, на который приходит PRI-поток, посредством dial-peer voip. В вашем случае, это может быть все что угодно — внутренний или любой другой номер, который попадает на CCM. Application name — выбираем приложение (в моем случае CityToInternal). Maximum number of sessions — максимальное количество сессий, ставим 10. Call control group — группа контроля вызова (JTAPI Call control group). Primary dialog group — медиа группа (Media Termination Dialog Group). Device Name и Description — задаются автоматически на основе Prefix(DN) + Directory Number, но вы можете их изменить под себя. Нажимаем Add и все готово.
Dial-peer на моем voice-gateway выглядит следующим образом:
1.2.3.4 — IP-адресс Cisco CallManager.
Теперь можно проверить работу приложения, позвонив на номер указанный в JTAPI триггере.
На этом пока все. Надеюсь моя статья сможет вам пригодиться.
На данный момент скрипт уж очень простой и не содержит никаких голосовых приветствий, обработки различных событий (вроде сигнала «занято», неверно набранного номера). В дальнейшем я планирую его усовершенствовать до полноценного скрипта с приветствиями, запросами и всеми возможными проверками «на дурака». Сейчас опишу подробно, как сделать донабор номера.
Написание скрипта
Запускаем редактор и создаем новый скрипт.
Создадим две переменные: одна для хранения номера, другая — для запроса. Запрос у будет пустым, т.к. диалог требует присутствия этого параметра в настройках.
Теперь нужно добавить обработчики событий для входящего звонка. Вот такой получился скрипт:
По порядку пройдемся по основным элементам. Первый оператор Start по-умолчанию присутствует во всех скриптах и означает начало. Два последующих принимают вызов. Следующая функция Get Digit String позволяет получить от абонента набираемые цифры. Ее нужно настроить. После того, как вытащили ее с панели объектов в тело скрипта, нажмите на ней правой кнопкой мыши и выберите Properties. На первой вкладке General в списке Result Digit String выбираем переменную intNum. Далее на вкладке Prompt в списке Prompt выбираем переменную prompt. На вкладке Input вы можете настроить параметры получения цифр от абонента. Я оставил все по-умолчанию. И наконец, на вкладке Filter нужно задать количество цифр, которое будет ожидаться от абонента. Я выставил число 4 в поле Input Length, так как у меня четырехзначный внутренний номерной план.
Так как пока учитываем, что пользователь все ввел верно, добавляем функцию Call Redirect в условие Successful. Эта функция будет переадресовывать звонок на номер, который ввел абонент. Ее так же надо настроить. В свойствах Call Redirect в поле Destination выберите переменную intNum.
Добавляем в условие Successful функции Call Redirect функцию Set Contact Info. Нажимаем на ней ПКМ и в табличке Attributes напротив параметра Handled выбираем — Marked --. После добавляем оператор End. Это отметит звонок абонента как «обработанный» и завершит сессию.
В конце скрипта добавляем Terminate и End. На этом скрипт закончен. Сохраняем его на диске, после чего мы его зальем на сервер CRS.
Настройка CRS
Открываем админку CRS, выбираем пункт Script Management.
Перед нами список скриптов присутствующих в системе. Нужно добавить свой, только что созданный. Нажимайте на ссылку Upload New Scripts.
Выбирайте сохраненный скрипт и нажимайте кнопку Upload. Теперь, когда скрипт залит, нужно создать приложение. Приложение в CRS определяет скрипт, используемый JTAPI для обработки вызовов, а также задает начальные параметры для скрипта, если такие имеются.
Выбираем пункт Application Management.
Видим список имеющихся приложений в системе:
Нажимаем Add a New Application. В окошке появившемся в списке выбирайте Cisco Script Application.
Называем приложение как больше нравится. Я назвал его CityToInternal. Description — напишите что-то, что позволит вам в будущем вспомнить, зачем это приложение. ID — задается системой автоматически, но вы можете его поменять например на 666, если такое уже не занято другим приложением. Maximum number of sessions — максимальное количество звонков одновременно обрабатываемых приложением. Script — выбираем скрипт, в моем случае CTI.aef. Нажимаем Update.
Теперь нужно создать Media Termination Dialog Group. Медиа группы нужны для взаимодействия с абонентами, а именно для обработки DTMF тонов.
Выбираем пункт Cisco media.
Получаем список групп. Нажимаем Add a New CMT Dialog Control Group.
На появившейся странице задаем поля Description (что-нибудь, чтобы идентифицировать группу) и Maximum Number Of Channels (в моем случае 10). На самом деле под все приложения можно создать одну группу на 100 каналов, например. Но я предпочел разделить их.
Нажимаем Add и группа добавлена (на моем скриншоте Update, т.к. я скринил уже созданную группу).
Теперь выбираем пункт JTAPI и слева нажимаем на JTAPI Call Control Group. Нужно создать группу контроля вызова. Эта группа создаст необходимое количество CTI портов, на которые будет переадресовывать вызов абонента и уже с него активироваться приложение и наш скрипт.
Нажимаем Add a New JTAPI Call Control Group.
Заполняем поля. Group ID — заполняется системой автоматически, но вы опять же можете поставить что угодно, кроме уже используемых. Description — описание группы, поставьте что-то узнаваемое. Часто поля Description используются для отображения элементов в списках настроек, вместо ID. Number of CTI ports — я установил 10, это количество CTI портов, которое будет создано. Starting directory number — для этой группы потребуется 10 номеров и тут нужно указать номер первого порта (в моем случае 9980). Эти номера не должны быть назначены абонентам или Hunt-группам. Device name prefix — префикс для именование CTI портов. Device pool — выбрал Default. Media resource group list — выберите свой основной MRGL. Display — описание CTI портов, фактически то, что будет отображаться рядом с номером на экране телефона (Alerting name), когда CTI будет вам звонить. Жмем Add.
Теперь нужно создать триггер. Триггер — это некий номер, который абонент будет набирать, чтобы получить доступ к нашему приложению. Тот же пункт JTAPI, выбираем слева JTAPI Triggers. Видим список триггеров в системе.
Нажимаем Add a New JTAPI Trigger.
Directory number — номер, на котором будет активироваться наше приложение. Уточню, у меня указан 7-значный городской номер. Эти номера попадают на CCM с роутера, на который приходит PRI-поток, посредством dial-peer voip. В вашем случае, это может быть все что угодно — внутренний или любой другой номер, который попадает на CCM. Application name — выбираем приложение (в моем случае CityToInternal). Maximum number of sessions — максимальное количество сессий, ставим 10. Call control group — группа контроля вызова (JTAPI Call control group). Primary dialog group — медиа группа (Media Termination Dialog Group). Device Name и Description — задаются автоматически на основе Prefix(DN) + Directory Number, но вы можете их изменить под себя. Нажимаем Add и все готово.
Конфигурация роутера
Dial-peer на моем voice-gateway выглядит следующим образом:
dial-peer voice 254 voip
description === 1234567 ===
destination-pattern 1234567
session target ipv4:1.2.3.4
dtmf-relay h245-signal h245-alphanumeric
codec g711ulaw
1.2.3.4 — IP-адресс Cisco CallManager.
Теперь можно проверить работу приложения, позвонив на номер указанный в JTAPI триггере.
На этом пока все. Надеюсь моя статья сможет вам пригодиться.
