А.П. Сушков, ведущий инженер группы "Телеком" отдела новых технологий ЗАО "Петер-Сервис"
Январь 2006
/врезка/
В настоящее время все больше предприятий автоматизируют свои бизнес-процессы. Существенную роль в этом играет использование современных приложений компьютерной телефонии (CTI), например автоинформатора, автосекретаря, голосовой и универсальной (Unified Messaging) почты, call- или контакт-центра.
В данной статье показаны преимущества CTI-платформы, реализованной с использованием технологии передачи голоса по IP-сетям (VoIP), по сравнению с традиционными технологиями, основанными на коммутации каналов TDM. Особое внимание уделено вопросам, которые необходимо решить производителям CTI-платформы при использовании технологии VoIP в своих разработках.
/конец врезки/
Многие современные учрежденческие АТС имеют встроенные телефонные приложения. Однако их набор, как правило, невелик и есть существенные функциональные ограничения, связанные с невозможностью гибкой настройки под конкретные нужды заказчика, изменения логики работы и интеграции информационной системы предприятия. В УАТС отсутствуют и такие дополнительные возможности, как запись телефонных разговоров, преобразование текстовых данных в голосовые (TTS, Text-To-Speech), автоматическое распознавание речи (ASR, Automatic Speech Recognition). Поэтому корпоративные заказчики пользуются встроенными возможностями УАТС лишь на начальном этапе. Затем возникает необходимость приобрести полнофункциональную CTI-платформу.
В настоящее время все большее распространение в корпоративной телефонии получает технология VoIP, и производители CTI-решений включают поддержку VoIP-протоколов в свои платформы. Существует несколько протоколов VoIP, наиболее распространенными из которых являются ITU-T H.323 и IETF SIP (Session Initiation Protocol). CTI-систему на базе IP является более предпочтительным решением для предприятий по сравнению с традиционными технологиями по следующим причинам:
· IP-CTI-систему дешевле вводить в эксплуатацию благодаря отсутствию необходимости в приобретении дорогостоящих телефонных плат в компьютер. В традиционных CTI-системах связь с УАТС осуществляется с помощью телефонных плат, а в среде IP платы отсутствуют, поскольку IP-CTI-система использует сетевой интерфейс компьютера;
· IP-CTI-систему проще интегрировать с существующей УАТС, так как нет необходимости стыковать параметры протоколов сигнализации между УАТС и телефонной платой. В традиционной CTI-системе для согласования протокола сигнализации необходимо настраивать параметры на стороне как телефонной станции, так и CTI-системы. Причем многочисленность этих параметров может сделать интеграцию невозможной. При использовании IP -- настроек немного и они достаточно очевидны, а в некоторых случаях вообще отсутствуют;
· Для масштабирования CTI-платформы не нужно приобретать дополнительные телефонные платы, как в случае с традиционными CTI-системами. Расширение достигается гибким лицензированием, что обходится дешевле, поскольку оплачивается только необходимое количество портов;
· Помимо услуг классической телефонии можно обеспечить пользователей дополнительными IP-сервисами. Например, при наличии "программного" телефона (софтфона) не нужен телефонный аппарат: голос может идти непосредственно на компьютер и воспроизводиться через гарнитуру. При наличии IP-телефона CTI-система может выводить на его дисплей данные из информационной системы предприятия. Такая функциональность особенно актуально для CRM-систем, когда вместе со звонком на операторское место должна поступать и информация об абоненте;
· IP-CTI-решение независимо от местоположения УАТС и может быть установлено и настроено в любом кабинете или филиале компании, где есть IP-сеть. Традиционная система CTI должна располагаться в непосредственной близости к телефонной станции, куда проведены провода для ее подключения.
При выборе CTI-системы сразу возникает вопрос об ее подключении к имеющейся УАТС. Если на предприятии установлена IP- или конвергентная УАТС, то приобретение IP-CTI-системы является очевидным решением.
Рассмотрим более распространенный на сегодняшний день вариант, когда имеется традиционная УАТС, вообще не поддерживающая IP. В данном случае для подключения IP-CTI-системы необходим VoIP-шлюз, который стоит недешево, однако при этом его функции не ограничиваются подключением CTI-системы, и он может служить для решения и других задач:
· обеспечение сотрудников IP-телефонами. На сегодняшний день IP-телефоны дороже цифровых, и тем более аналоговых, но цена на них постоянно снижается, а удобство использования и уменьшение затрат на обслуживание делают их использование оправданным. Например, перенос IP-телефона из одного помещения офиса в другое сводится к отключению от одной сетевой розетки и подключению к другой (поскольку IP-сеть на предприятии есть практически всегда), тогда как в случае с традиционной телефонией необходимо провести дополнительные телефонные провода и изменить настройки телефонной станции;
· сокращение расходов на междугородные/международные телефонные разговоры;
· снижение затрат на администрирование и подключение новых удаленных офисов к глобальной сети предприятия, так как вместо двух сетей остается лишь одна.
Не нужно забывать, что в случае подключения традиционной CTI-системы к УАТС необходимо приобрести телефонные платы в компьютер, цена которых сравнима со стоимостью шлюза, а кроме того, при этом теряются преимущества IP-решения.
Обычно предприятие выделяет несколько телефонных номеров, позвонив на которые, клиент попадает на необходимые корпоративные голосовые службы. Для приема звонков УАТС используют аналоговые линии, цифровые транки (с сигнализацией ISDN или ОКС № 7) или IP-входы. В соответствии с номерным планом УАТС коммутирует входящие вызовы на IP-CTI (рис. 1).
Рис. 1. Схема прохождения звонка из ТфОП в IP-CTI-систему
У производителей CTI-платформ существует несколько способов поддержки VoIP в своих решениях. Если CTI-платформа спроектирована грамотно и бизнес-логика не зависит от используемых телефонных плат (рис. 2), то можно взять VoIP-протокол нового производителя телефонного оборудования и на его основе разработать уровень "реализации взаимодействия с оборудованием". Однако это слишком трудоемкий и длительный путь, так как телефонная часть CTI-платформ обычно рассчитана на телефонное оборудование конкретного производителя и на ее отладку и оптимизацию потрачено значительное время.
Более предпочтителен другой вариант, когда сам производитель телефонных плат предоставляет универсальный интерфейс для разработки CTI-платформы, которую можно использовать как в традиционных, так и IP-сетях. Но даже в этом случае принципиальные различия между технологиями не позволяют обойтись без существенной доработки.
При создании CTI-платформы для IP-сетей необходимо решить следующие вопросы:
· регистрация IP-терминалов на сервере для возможности установки соединения: в протоколе H.323 эта задача решается с помощью "привратника" (Gatekeeper); в протоколе SIP -- с помощью "сервера регистрации" (SIP Registrar);
· использование VoIP-шлюза для совершения исходящих вызовов через ТфОП: в протоколе H.323 -- Gateway, в протоколе SIP -- SIP Proxy;
· поддержка гарантированного качества обслуживания (QoS);
· получение информации о пришедшем звонке;
· согласование голосовых кодеков при установке соединения;
· передача факсимильных данных по IP-сетям с помощью протокола T.38: FoIP (Fax over IP);
· передача тонального набора (DTMF) по IP-сетям;
· поддержка передачи вызова (Transfer) с помощью протокола H.450.
Ниже подробно рассматриваются пути решения перечисленных проблем.
Рис. 2. Архитектура CTI-платформы с абстракцией телефонного оборудования
Для того чтобы IP-телефон или софтфон мог принимать вызовы, необходимо сообщить IP-УАТС или VoIP-шлюзу его телефонный номер и IP-адрес. Это может быть сделано двумя способами:
1) при подключении IP-терминала администратор вручную прописывает его номер и IP-адрес;
2) IP-терминал автоматически регистрируется при включении без вмешательства администратора.
Суть этих действий одна: после них IP-УАТС способна коммутировать звонок по определенному номеру на определенный IP-терминал. Автоматическая регистрация IP-терминалов происходит по протоколу H.225.0 (RAS, Registration Admission and Status), поэтому в IP-CTI-платформе необходимо реализовать его поддержку.
Для того чтобы CTI-приложения могли совершать исходящие вызовы и при этом набирать обычный телефонный номер, они должны знать IP-адрес шлюза. Этот адрес заносится в конфигурацию IP-CTI-системы на этапе установки. Возможна также реализация стандартного механизма автоматического получения адреса VoIP-шлюза.
Если IP-CTI-система находится внутри локальной сети предприятия и голосовой IP-трафик не выходит за пределы предприятия в глобальную сеть (WAN), то качество обслуживания гарантируется благодаря избыточной полосе пропускания. Даже обычная локальная сеть 100 Мбит/с теоретически позволяет осуществлять несколько сотен одновременных вызовов без применения специальных механизмов QoS, обеспечивающих резервирование полосы пропускания и/или приоритезацию голосового трафика.
Для эффективного использования технологии QoS в IP-CTI-системах, трафик которых выходит в глобальную сеть, необходимо, чтобы функции QoS поддерживались на протяжении всего маршрута голосового трафика.
В цифровых протоколах основная информация о вызове заключена в Setup-сообщении: набранный номер (DNIS, Dialed Number Identification Service), номер звонящего (ANI, Automatic Number Identification) и номер, с которого был переадресован звонок (Redirection).
B IP-протоколах, помимо перечисленных данных, в запросе на установку соединения может приходить гораздо больше информации, в том числе нестандартной. Для ее извлечения из сообщения следует использовать соответствующие стандартные протоколы, а при получении нестандартной информации от IP-УАТС (например, Redirection-номер в протоколе H.323) необходимо описание формата этих данных.
При переходе на IP необходимо решить проблему согласования кодеков, в отсутствие кодека, поддерживаемого с одной стороны IP-CTI-системой, а с другой -- VoIP-шлюзом, соединение не установится. Таким образом, чем большее количество кодеков IP-телефонии (см. таблицу) будет поддерживать IP-CTI-платформа, тем лучше.
/таблица/
Основные кодеки, используемые в IP-телефонии
Кодек |
Полоса пропускания, кбит/с |
G.711 |
64 |
G.729A |
8 |
GSM 6.10 |
13 |
G.723.1 |
6,3 |
G.723.1 |
5,3 |
Для передачи факсимильных данных по IP-сетям CTI-платформа может поддерживать протокол T.38. В этом случае необходим VoIP-шлюз, который распознает входящие факсимильные данные, преобразует их в IP-пакеты и передает на IP-CTI-систему по протоколу T.38.
Необходимо, чтобы IP-CTI-платформа поддерживала два типа соединения для обработки факсимильных данных: первый -- соединение, по которому передаются только факсимильные данные; второй -- когда переключение на обработку факсимильных данных осуществляется во время голосового соединения.
В кодеках, обеспечивающих сжатие звукового потока, по умолчанию предполагается, что сигнал состоит только из речи. В результате DTMF-сигналы, переданные этими кодеками, будут искажены так, что распознать их будет невозможно. Поэтому на VoIP-шлюз ложится задача распознавания и подавления DTMF-сигналов во входном звуковом потоке и последующей их передачи способами, адаптированными для IP-сетей. Существует два основных способа передачи DTMF-сигналов по IP-сетям:
· с помощью сообщений H.245 User Input Indication (UII). Этот способ имеет ограничение по протоколу (только H.323), и еще один его недостаток заключается в том, что UII-сообщения передаются отдельно от голосового потока, поэтому могут быть рассинхронизированы с ним во времени;
· в соответствии со стандартом RFC 2833. Информация о поступивших телефонных сигналах (DTMF или телефонных тонах) передается внутри голосового потока со специальным значением типа звуковых данных. В этом случае рассинхронизации не происходит.
Способ передачи DTMF-сигналов согласовывается на этапе установки соединения. Если не найдется способ, поддерживаемый обеими сторонами, то соединение не установится. Поэтому необходимо, чтобы IP-CTI-платформа поддерживала любой тип передачи DTMF-сигналов.
Передача вызова (Transfer) используется в системах, в которых необходимо перевести звонок с CTI-приложения на оператора, или при звонке абонента на автосекретаря, когда необходимо перевести звонок на сотрудника.
При передаче вызова по аналоговым линиям используется следующая технология. На первом этапе активное соединение переводится в режим удержания (on-hold). Это осуществляется кратковременным разрывом тока на линии (flash hook), после чего совершается набор нужного номера и производится разрыв соединения. В цифровых протоколах логика переадресации аналогична, но действия производятся сигнальными пакетами. Для передачи вызова по IP-сетям используется протокол H.450 со следующей логикой (рис. 3).
Поскольку логика передачи вызова по протоколу H.450 значительно отличается от традиционных способов, разработчикам придется реализовывать этот тип передачи вызова самостоятельно. Надо отметить, что далеко не все VoIP-шлюзы поддерживают перевод вызова. Поэтому, если такая функциональность необходима, то выбор IP-оборудования должен быть более тщательным.
Рис. 3. Схема перевода вызова по протоколу H.450
Хотя описанные выше проблемы реализации CTI-платформы для IP-сетей и представляют собой некоторую сложность для реализации, они не должны служить причиной для отказа от поддержки технологии VoIP в CTI-платформе. А выгода и удобство использования IP-CTI-решения для заказчика делает его более предпочтительным выбором по сравнению с традиционным CTI-решением.
Литература
1. ITU-T Recommendation H.323. Packet based multimedia communication systems // Geneva, 1998.
2. RFC 2543. Session Initiation Protocol. M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg. March 1999.
3. RFC 2833. RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals. H. Schulzrinne, S. Petrack. May 2000.
4. Global Call IP Technology Guide // Intel-Dialogic, January 2004.
5. Global Call IP for Host Media Processing Technology Guide // Intel-Dialogic, September 2003.
6. Гольдштейн Б.С., Пинчук А.В., Суховицкий А.Л. IP-Телефония // М.: Радио и связь, 2001.
7. Корпоративные решения для пакетной IP-телефонии // www.cisco.com
Рис. 1. Схема прохождения звонка из ТфОП в IP-CTI-систему