Основы разработки систем компьютерной телефонии

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

 

Что такое компьютерная телефония?

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

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

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

Сетевой интерфейс

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

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

Тип сетевого интерфейса во многом зависит от типа разрабатываемой системы. Например, для систем с интерактивным голосовым ответом не принято работать непосредственно с местной телефонной сетью. Тем не менее, если такая система предоставляет хотя бы минимальное управление типа "нажмите 0 для соединения с оператором", оно должно быть интегрировано с внутренней телефонной сетью. В этом случае обычно приложение связано с телефонной сетью через внутреннюю АТС или key system

Более того, в зависимости от каждого конкретного случая, сетевой интерфейс уже может быть определен, как в случае со многими "центрами связи" (call center). Для разработчиков внутренних АТС принято предлагать такие решения вместе с коммутатором. Эти системы часто предоставляют телефонию архитектуры клиент-сервер, как, например, уведомления всплывающими окнами (screen pops) и настольные системы управления вызовами. В этом случае сетевой интерфейс почти всегда определяется разработчиком.

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

Непосредственное подключение к местной телефонной сети

Все приложения КТ включают в себя 2 технологии - обработка данных и управление звонками. Под обработкой данных подразумевается проигрывание и запись голосовых файлов, определение тонального набора, получение и отправление факсов и в целом обработка любых типов данных, которые могут передаваться по телефонной линии. Управление звонками относится к организации, ответу, переносу, задержке звонка и организации конференций.

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

Телефонные серверы на базе ПК, предоставляющие обработку данных и управление звонками, могут быть подключены прямо к МТС. Такие системы становятся все более популярными для малых компаний как полная замена закрытым внутренним АТС. В организациях большего размера такие системы могут работать как серверы отделов, работающих вместе с внутренней АТС.

Аппаратная модель.

Система подключается непосредственно к МТС при помощи плат для телефонии на базе ПК. Это платы в диапазоне от голосовых модемов до специализированных систем на базе DSP от таких фирм как Dialogic или Rhetorex. Голосовые модемы являются недорогой альтернативой и подходят для небольших офисов, но при этом они имеют ряд ограничений, сужающих их возможности для профессиональных систем. Например, модемы позволяют иметь строго ограниченное количество линий в расчете на один ПК, чаще всего вообще одну. Кроме того, они не могут нормально работать с распознаванием диапазона тонов, которые могут потребоваться системой.

Профессиональные системы требуют аппаратной архитектуры, состоящей из одной или более специализированных плат, соединенных стандартной шиной (в настоящее время есть 2 стандарта - SCSA and MVIP, третий же - H.100 объединяет эти два). Это позволяет смешивать устройства разных производителей в одной системе (например, адаптер ISDN, E1 или T1 от одной компании, а обработка сигналов на базе DSP и работа с факсами от другой и т.д.)

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

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

Цифровой или аналоговый интерфейс.

Если ваше приложение будет соединяться непосредственно с МТС, вам нужно будет решить, какие телефонные сети вы будете использовать - аналоговые или цифровые (если, конечно, такой выбор есть). Но для этого надо знать, что может предоставить вам телефонная компания. Обычно сервис с малой плотностью строится на аналоговых сетях (наиболее распространенный тип во всех странах). Но можно также получить ISDN, с так называемым базовым сервисом (BRI - basic rate interface).

Большие системы почти всегда подключаются через цифровые сети. Кроме T-1 или E-1 ваша компания может предоставлять ISDN PRI (primary rate interface). Одна линия E-1 или PRI ISDN может предоставить 30 соединений, а T-1 соответственно 24.

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

Если вы уж и в самом деле задались целью поставить цифровую линию, вас ждет долгая работа по настройке (будьте уверены, на АТС привыкли ставить в основном аналоговые линии), так что учтите время и потраченные нервы при установке цифровых линий.

Сертификация.

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

Соединение с внутренней АТС или Key System.

Системы КТ, включающие управление звонками, часто разрабатываются для работы как придатки к внутренней АТС. Они разработаны для управления внутренним телефонным коммутатором и могут включать такие возможности как автоответчик, голосовая почта, автоматическое распределение вызовов (ACD), фильтрация вызовов, в том числе блокирование нежелательных звонков (call screening), а также такие возможности телефонии на базе архитектуры клиент-сервер, как вышеупомянутые screen pops. Так как эти системы разработаны для работы с внутренними АТС, то они часто поставляются разработчиками коммутаторов как законченный продукт.

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

Классический подход.

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

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

Большинство АТС могут управляться и контролироваться при помощи тональных посылок, генерируемых аналоговыми расширениями. Например, переадресация может быть сделать посылкой специального DTMF сигнала (#) с последующим идентификатором назначения и, если там занято, второй такой сигнал может вернуть связь со звонящим. Можно также просто "слепо" переносить звонок, отсоединяясь после его передачи. Многие большие системы используют именно этот механизм.

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

Цифровое управление (CTI Link).

Другой вариант - использование цифровой связи (чаще всего последовательный интерфейс управления), известного как CTI Link. Он позволяет использовать двустороннюю связь, контроль статуса и посылку команд АТС. Для этого надо использовать либо специфический API внутренней АТС либо стандартные API - как Microsoft TAPI или Novell TSAPI.

Этот подход позволяет строить более гибкие системы, которые не ограничены только генерацией и распознаванием тонов, позволяя использовать все возможности АТС, хотя и требует более глубокого понимания конкретных протоколов АТС. Но в связи с расширением поддержки стандартов TAPI и TSAPI это подход становится все более распространенным.

Разработка и воплощение решений компьютерной телефонии.

Рассмотрим вопрос с точки зрения разработки ПО.

Начало разработки.

Для начала работы с КТ проще всего разработать автоматический доступ к информации с телефона или факса. Audiotext, интерактивные голосовые ответы (IVR), факс по требованию и прочие подобные системы относятся к этой категории.

Причины, по которым это рекомендуется:

Это не столь критичные к сбоям приложения, в отличие от систем управляющих всем телефонным траффиком компании

Их можно сделать без тесной связи с внутренней АТС, поэтому уменьшается сложность интеграции.

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

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

Есть множество средств разработки, чтобы создавать такие системы просто и быстро.

Простейшее приложение.

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

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

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

Основные положения.

Хотя можно утверждать, что UNIX и OS/2 имеют возможность нормально работать как ОС для телефонии, промышленность ориентируется на Windows NT. Это, конечно, не единственная платформа, но она считается производителями КТ стратегической и, соответственно, полнее поддерживается.

В целом, ОС для компьютерной телефонии должна отвечать следующим требованиям:

Многозадачность.

Масштабируемость.

Хорошая работа с базами данных.

Хорошая работа с сетью.

Широкий выбор инструментальных средств, ПО и периферийных устройств.

Одним из наиболее важных факторов при выборе операционной системы является доступность средств разработчика для создания приложений компьютерной телефонии. В этом вопросе Windows NT имеет несомненные преимущества перед другими платформами. Например, возьмите такие средства как Microsoft Visual C++, Borland Delphi или Microsoft Visual Basic - весьма удобные средства для разработки такого ПО. Как? Благодаря архитектуре custom control. Например, Artisoft выпустила Visual Voice - ActiveX компонент, предоставляющий интерфейс высокого уровня для управления телефонией.

Использование стандартных средств разработки имеет много преимуществ. Во-первых, не надо изучать какой-либо специализированный язык (типа полусамодельного скрипта) для разработки приложения. Кроме того средства разработки под Windows имеют средства RAD, встроенную поддержку работы с базами данных и сетью.

Чаще всего в таких случаях используют Visual Basic под Windows NT . Это комбинация предоставляет набор из относительно хорошей многозадачной системы, очень простого средства для разработки и хорошей связи с базой данных.

Листинг простейшей программы для телефонии:

Private Sub Voice1_RingDetected()

 Dim OrderNum

 On Error GoTo MainErr

 'отвечаем на звонок

 Voice1.PickUp

 'проигрываем 'Hello. Welcome to the Order Status System.'

 Voice1.PlayFile "greeting.vox", , ""

 'отвечаем на ввод пользователя

 Voice1.PlayFile "getorde1.vox"

 OrderNum = Voice1.GetDigits(5)

 'поиск в базе данных

 Data1.Recordset.FindFirst "OrderNum='" & OrderNum & "'"

 If Data1.Recordset.NoMatch Then

    Voice1.PlayFile "notvalid.vox", , ""

 Else

    Voice1.PlayString "OrderNum.vox|FILE, " & OrderNum &

    "|CHARACTER,wasship1.vox|FILE, " &

    Data1.Recordset("Shipped") & "|DATE|ddd mmm d,

    andtotal.vox|FILE, " &

    Data1.Recordset("Total") & "|MONEY", ""

 End If

 'проигрываем 'Thank you for calling. Goodbye.'

 Voice1.PlayFile "goodbye.vox"

 'вешаем трубку

 Voice1.HangUp

 Exit Sub

 MainErr:

    If Err <> vvpLineDropped Then MsgBox Error$

    Voice1.HangUp

 End Sub

Пример управления звонками.

Вторая популярная сфера использования КТ - управление звонками, предоставляющее уведомление оператору в виде всплывающего окна при появлении входящего звонка. Итак, общее описание такой системы:

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

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

Переадресация звонка производится имитацией аналоговой станции, другими словами, сервер генерирует такую же последовательность тональных посылок, как и телефон при переносе звонка. Эта последовательность включает DTMF сигнал (#) с последующим идентификатором назначения. Переадресация может производиться под контролем либо вслепую. При управляемой переадресации приложение прослушает линию, чтобы определить голос или сигнал "занято". Если получен сигнал "занято", можно вернуться к звонящему и предложить дополнительные варианты, например, подождать или оставить сообщение.

Сетевое уведомление оператору может быть произведено при помощи встроенной сетевой поддержки Visual Basic или другого средства разработки.

Дополнения.

В зависимости от конкретного случая, еще одним важным вопросом будет механизм для определения отклика пользователя. Хотя это и кажется идеальным, но не всегда удобно предположить, что у пользователя есть DTMF набор, поэтому придется разрабатывать дополнительные средства для определения ввода пользователя: например импульсный набор и распознавание голоса.

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

Если же вы решили добавить распознавание голоса, то тут у вас много требований. Во-первых, нужен конкретный движок для распознавания того языка, который вам нужен, потом надо узнать, поддерживает ли ваш набор разработчика такой движок. Многие разработчики предлагают поддержку Microsoft's Speech API (SAPI), что позволяет не зависеть от конкретного движка производителя. То есть, если есть SAPI-совместимый движок для вашего языка, вы можете встроить его в приложение с помощью SAPI-совместимого средства разработки.

Также вам надо будет проанализировать частоту, на которой данные для распознавания будут передаваться вашему приложению. Если у вас приложение с высокой плотностью (24+ линий на ПК), может потребоваться аппаратная поддержка, так как эта задача требует высоких вычислительных ресурсов, что критично для систем с высокой плотностью. Можно напомнить также, что есть 2 типа систем распознавания - слитная и дискретная. Дискретная распознает отдельно произносимые слова, слитная - нормальную речь.

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

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

Dave Krupinski, авторизованный перевод -- Роман Гриц aka HellMaster



Сетевые решения. Статья была опубликована в номере 01 за 2000 год в рубрике технологии