Сотрудничая с клиентами, которые имеют разветвленную сеть подразделений по всей России, мы чаще всего советуем им экономичное решение – подключить прямые городские мобильные номера Мегафон по sip, используя услугу Мультифон. Опыт использования этого решения наших клиентов показал очень явные плюсы (дешевизна – 70 рублей в месяц, не ограниченная линейность, прекрасное продвижение благодаря городским телефонным номерам в выдаче поиска и контекстной рекламе Гугла и Яндекса), но есть и очень большой недостаток.
Недостаток связан с непонятным, неуловимым изменением роутинга на мегафоновском sip сервере, используя услугу Мультифон. Для клиентов, которые имеют 1-2 номера мультифона, скорее всего, не воспримут это изменение как проблему, всего лишь как маленький «глюк». Запускаешь приложение Мультифон и выбираешь из списка, куда отправлять внешние звонки.
Совсем другая ситуация, если у заказчика подключено пятьдесят и больше таких номеров. Тогда такая перенастройка роутинга отнимает очень много времени, не говоря о том, насколько процедура нудная и муторная. Чтобы по-максимуму уменьшить негатив и скоратить в простои в работе телефонии, разработали сценарий автоматической проверки работы роутинга и если нужно автоматического перенаправления на необходимое значение. Все итоги работы сценария автоматически сохраняются в лог-файле и затем отправляются на электронную почту. Полный сценарий выглядит таким образом (рисунок 1).
Первоначально создается SQL таблица, в которую входят четыре поля: Сity (город), ID (идентификатор), Nomer (номер телефона), пароль от мультифона Pass. Все номера мультифона заносятся в таблицу. Затем нужно перейти к рассмотрению сценария по блокам.
Желтым выделен участок сценария, отвечающий за создания файла, куда будет записываться лог. Детальнее рассмотрим эту часть. В компоненте «Присвоение 2» есть 3 переменные, хранящие дату, часы и минуты (рисунок 2).
В компоненте «Присвоение 3» дата преобразуется для понятного отображения (рисунок 3).
В компоненте «Присвоение 4» создается переменная, которая будет хранить путь лог-файла (рисунок 4).
В компоненте «Файловая операция 1» создается лог-файл по пути из переменной «Путь», куда в последующем будет фиксироваться вся информация (рисунок 5).
Рассмотрим вторую часть сценария, выделенную красным цветом. Это главная часть сценария, которая отвечает за выгрузку данных из SQL таблицы (рисунок 6)
и фиксация их в вебзапросе, отвечающем за роутинг мультифона (рисунок 7)
В компоненте «Присвоение 26» записываются результаты в переменную kod, которые возвращают нам вебзапрос мультифона (рисунок 8)
Компонент «Сравнение 1» подвергает анализу переменную «kod», в которой находится ответ вебзапроса. Если получен ответ «200OK», то все прекрасно и этот ответ фиксируется в лог-файле. Если ответ отличается от «200OK», то делается второй вебзапрос, но теперь уже с параметром «». Опять анализируем ответ и, отталкиваясь от него, вносим запись в лог-файл. Зацикливаем данную операцию количество раз, соответствующее количеству записей, хранящемуся в нашей SQL таблице.
После выполнения всех циклов наш лог-файл отправляем на электронную почту. Файл приходит в таком виде (рисунок 9)
Запускать этот сценарий можно как в автоматическом режиме по определенному расписанию, так и в ручном режиме. Изменения дадут возможность выполнять запуск сценария дозвоном до внутреннего телефонного номера и получать отчет в режиме коммутации в звуковом формате.
