infotag set med_language prefix "ru";

    SelectLanguageMenu;

    return;

    }

Процедура act_Setup вызывается IVR-скриптом при поступлении нового звонка. Именно с нее, по сути, начинается обработка звонка клиента. Почему именно с нее? Имя этой функции определено как обработчик события ev_setup_indication, которое генерируется при каждом новом звонке. За это отвечает строчка:

set ivr_fsm(CALLCOMES,ev_setup_indication) "act_Setup same_state";

в конце нашего скрипта.

Тут следует ненадолго перейти к теме FSM. Перед выполнением IVR-скрипта требуется определить имя массива, который будет содержать в себе все состояния звонка, функции-обработчики событий, которые могут возникнуть при этом состоянии, и имя следующего состояния, в которое перейдет звонок при выполнении этой функции, а также стартовое состояние звонка. Заметьте: не после выполнения функции, а непосредственно сразу (одновременно). Учтите также, что все вызовы функции и команд в TCL IVR API «не блокирующие», и для выполнения последующей команды скрипт не будет дожидаться завершения предыдущей. Это может смутить программистов, работавших ранее с такими языками, как Си, но к этому необходимо привыкнуть. Например, если в процедуре написаны следующие команды:

leg collectdigits 1 callInfo

leg collectdigits 2 callInfo

leg setup 295786 setupInfo $callID5

puts " This will be executed immediately i.e. before the collect digits or call setup is actually complete"

то все они будут выполнены одна за другой, не дожидаясь завершения предыдущей. В данном случае начнется процесс сбора цифр на виртуальных составляющих звонка leg 1 и leg 2, процесс установки соединения на $callID5 и выдано отладочное сообщение командой puts. Далее IVR-приложение начнет ожидать получения событий от этих процессов и вызвать соответствующие функции-обработчики.

Командой fsm define (в конце нашего скрипта) определяется имя массива, описанного выше ivr_fsm, и первоначальное состояние звонка CALLCOMES. Командой set ivr_fsm мы будем добавлять к этому массиву новые элементы, создавая так называемые «FSM-переходы». Общий синтаксис этой команды таков:

set array(curr_state,curr_event) “act_proc NEXTSTATE”

где:

n  array – это имя определенного командой fsm define массива.

n  curr_state – имя текущего состояния скрипта, при котором получено событие curr_event.

n  act_proc – имя функции-обработчика события, которую необходимо выполнить при поступлении события curr_event в состоянии curr_state.

n  NEXTSTATE – имя состояния, в которое должен перейти звонок.

При определении FSM можно использовать следующие мета-определения:

n  any_state – определяет любое состояние звонка, для которого не установлен иной обработчик в другом FSM-переходе; может быть использовано в левой части (индексе массива) FSM-перехода.

n  same_state – трактуется как «то же состояние»; может быть использовано в правой части (значении элемента массива) определения FSM-перехода.

n  ev_any_event – определяет любое событие, которое может получить скрипт.

Теперь, глядя на строчку:

set ivr_fsm(CALLCOMES,ev_setup_indication) "act_Setup same_state";

мы легко можем понять, что при получении события ev_setup_indication в состоянии CALLCOMES будет выполнена функция act_Setup и звонок останется в прежнем состоянии (same_state).

Возвращаясь к нашей функции act_Setup, мы видим, что в ней вызывается процедура init_perCallVars для объявления и инициализации глобальных переменных, которым необходимо иметь возможность менять свое значение при каждом отдельно взятом звонке. Командой leg setupack посылается сообщение setup acknowledgement, чтобы перевести наш звонок в состояние, при котором возможно получение клиентом голосовых сообщений.

Команда infotag set med_language prefix «ru» устанавливает текущий язык голосового интерфейса и фактически указывает скрипту, где ему следует искать звуковые файлы для этого языка. Помните строчку в глобальной конфигурации шлюза: