В свое время разработчики Microsoft Exchange Server 2070 решительно отказались от традиций корпорации в нескольких областях: они отправили архитектуру x86 на свалку, внесли принципиальные изменения в механизм функционирования средств обеспечения высокой доступности и интегрировали в систему функции обработки голосовой почты, а также факсимильных сообщений. Последнее из названных усовершенствований, получившее в Microsoft наименование единой системы объединенных коммуникаций Exchange Unified Messaging (UM), считалось наименее революционным из всех внесенных в Exchange 2007 изменений, ибо оно во многом воспроизводило возможности, уже реализованные тем или иным способом сторонними производителями.

Однако надо сказать, что система объединенных коммуникаций была интегрирована с Exchange 2007 лучше, чем продукты конкурентов, и превосходила их по быстродействию, а также надежности. Поскольку эта система была интегрирована непосредственно в транспортную архитектуру и в архитектуру хранения информации, она позволяла доставлять сообщения прямо в почтовые ящики пользователей (без проведения опросов на базе протокола IMAP). Кроме того, система была связана со службой Active Directory (AD), что позволяло выполнять звонки по имени на основе содержимого глобального списка адресов Global Address List (GAL). В системе недоставало ряда функций, таких как средства запуска индикатора получения сообщений message waiting indicator (MWI) на телефонах, подключенных к офисным АТС, но в целом это было значительное обновление платформы UM для Exchange. Надо сказать, что от внимания большинства скептиков ускользнуло то обстоятельство, что архитектура UM Exchange закладывала основы для ряда замечательных функций, которые просто не могли реализовать сторонние производители. Теперь, после выхода версии Exchange 2010, мы получили явное тому подтверждение.

Когда звонит телефон

Система Exchange 2010 отвечает на входящие вызовы примерно так же, как Exchange 2007. С помощью офисной АТС, системы Microsoft Office Communications Server (OCS) или шлюза VoIP входящий звонок направляется на сервер Exchange UM. Устройство, управляющее телефонной системой, я буду в дальнейшем именовать офисной АТС, даже если речь идет об OCS. В АТС закладывается набор инструкций, определяющих, что должно произойти в случае, если звонок на данный внутренний номер остается без ответа. Эти инструкции могут предусматривать различные действия для звонков на занятые внутренние номера, а также для звонков, остающихся без ответа в течение определенного времени. Давайте предположим, что вызываемый номер не отвечает. В соответствии с инструкциями АТС переводит вызов на сервер UM, который принимает запрос на вызов — в случае, если этот запрос поступает от известного IP-шлюза UM, — воспроизводит надлежащее приветствие и записывает ответ абонента.

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

Факс: выведен из эксплуатации, но не забыт

Начнем с изменения, которое описать проще всего: система объединенных коммуникаций версии Exchange 2010 уже не обеспечивает возможностей приема факсов через офисные АТС. Представленный в версии Exchange 2007 набор функций для работы с факсами по идее был замечательным компонентом, который был реализован чуть раньше своего времени: идея интеграции средств обработки факсов в систему Exchange была неплохой, но она созрела в то время, когда факсимильными аппаратами стали пользоваться реже и когда компании, такие как OpenText, уже осуществляли поставки полнофункциональных решений для интеграции средств факсимильной связи. Чтобы запустить реализованные в Exchange средства, нужно было должным образом настроить офисную АТС; к тому же эти средства не были наделены функциями, реализованными в продуктах сторонних производителей. И что еще более важно, система Exchange 2007 была приспособлена только для получения факсов, поэтому клиентам, которым требовались полнофункциональные средства, приходилось развертывать еще одно решение, чтобы иметь возможность отправлять факсы с рабочего стола. К тому времени когда администраторы стали учитывать затраты и трудности, связанные с организацией двусторонней факсимильной связи, стало ясно, что с экономической точки зрения чаще всего целесообразно развернуть систему факсимильной связи от стороннего производителя и не связываться с системой объединенных коммуникаций Exchange, если все, что от нее требуется, — это организация обмена факсами.

Однако Exchange 2010 все еще с грехом пополам принимает факсимильные сообщения. Exchange 2007 прослушивает генерируемый вызывающим номером звуковой сигнал T.38 CNG на частоте 1100 Гц (такими сигналами факсимильные аппараты обмениваются при взаимодействии друг с другом). Получив сигнал CNG, Exchange 2007 идентифицирует вызов как попытку передать факс и пытается принять его как поток T.38. Система Exchange 2010 функционирует несколько иначе; входящий факс может запустить ответ тремя способами. Но, перед тем как мы приступим к их рассмотрению, я должен пояснить, что процесс ответа на вызов в системе UM обычно состоит из двух этапов. АТС или IP-шлюз направляет сообщение SIP INVITE системе Exchange, которая отвечает на него и принимает вызов. Две стороны согласовывают набор параметров для предстоящего «диалога» и затем обмениваются данными с помощью протокола Real-time Transport Protocol (RTP).

Первый, наиболее простой метод, с помощью которого Exchange 2010 может обнаруживать вызовы факс-модема, базируется на способности самой системы Exchange распознавать звуковые сигналы CNG. Но сделать это она может лишь после того, как ответит на соответствующий вызов. Второй метод сводится к следующему. IP-шлюз или офисная АТС может обнаружить во входящем аудиопотоке звуковые сигналы CNG; в этот момент шлюз направляет системе Exchange извещение во входящем аудиопотоке RTP, содержание которого, в сущности, сводится к сообщению: «Внимание, это звонок факс-модема». Затем Exchange направляет шлюзу или АТС сообщение SIP REFER, которое перенаправляет вызов провайдеру передачи факсов через IP-сети Fax over IP (FoIP). Сложнее всего процесс протекает только при использовании шлюзов, которые не поддерживают динамического уведомления протокола T.38 в RTP. В этих случаях шлюз направляет системе Exchange новое сообщение SIP INVITE с другим профилем RTP — таким, который указан для обработки факсов. Exchange блокирует шлюз и затем отправляет сообщение SIP REFER, с тем чтобы вызов был переадресован.

А как Exchange получает данные о том, куда именно нужно направлять факс? Следует указать URL службы факсов, которую вы хотите использовать как часть абонентской группы системы объединенных коммуникаций. Выполнив эту операцию, вы получите возможность определять, смогут ли пользователи получать факсы, задав настройку Allow inbound faxes для работы через абонентскую группу или в соответствии с политикой UM, определяющей функционирование почтовых ящиков. Exchange перенаправляет вызов провайдеру FoIP; при этом целостность исходных данных вызывающего абонента и абонента-адресата сохраняется. Поставщик службы факсов принимает факс, возвращает его системе Exchange в виде сообщения электронной почты — обычно с присоединенным файлом TIFF (.tif). Может показаться, что этот формат не годится для вложения, но дело в том, что стандарт TIFF предусматривает возможность создания многостраничных вложений в одном файле, а это вполне подходит для передачи факсимильных сообщений.

Данный процесс позволяет с большей эффективностью распределять входящие факсы по адресатам; реализованный в Exchange 2007 метод доставки всех факсов в одно место доставлял получателям лишние хлопоты. Имеется несколько служб факсов, обеспечивающих получение факсимильных сообщений средствами Exchange 2010, так что пользователь может выбирать, руководствуясь такими критериями, как условия обслуживания и цены. Microsoft разместила список своих FoIP-партнеров на веб-странице Exchange Independent Software Vendors (www.microsoft.com/exchange/2010/en/us/independent-software-vendors.aspx#unified). У клиентов, которые уже развернули средства приема факсов Exchange 2007 и сейчас переходят на версию Exchange 2010, не остается вариантов, кроме обращения к той или иной службе факсов. Хочу высказать еще одно соображение: подобная интеграция невозможна, а значит, невозможен и прием факсимильных сообщений, если в качестве офисной АТС используется сервер OCS 2007 R2.

Языковая поддержка

Система Exchange 2007 оснащена двумя типами средств для работы с речью: автоматическое распознавание речи automatic speech recognition (ASR) и преобразование текста в речь Text-to-Speech (TTS). Кроме того, в единой системе обмена сообщениями Exchange используются заранее записанные аудиоподсказки, которые предоставляют вызывающим абонентам информацию и инструкции. Каждая из этих трех функций «привязана» к конкретному языку, и они объединяются в языковые пакеты. Так, если вы установите на UM-сервере пакет для французского языка, сервер будет выполнять функции ASR, TTS и предлагать аудиоподсказки на французском языке.

Но не все языковые пакеты Exchange 2007 включают в себя средства ASR. К примеру, пакет для мандаринского диалекта китайского языка оснащен средствами TTS, но не имеет средств ASR. Скажу больше: полным комплектом средств ASR оснащаются только английские языковые пакеты (для британского, австралийского и американского диалектов). Это обстоятельство стало серьезным препятствием на пути развертывания системы объединенных коммуникаций в крупных транснациональных компаниях. Впрочем, решение зависело не только от команды разработчиков Exchange.

Функции ASR и TTS обеспечиваются ядром платформы Speech Server. Примерно до 2005 года эта платформа выпускалась в качестве отдельного продукта, но позднее она была удалена из каталога продуктов Microsoft и включена в Office Communications Server. Ядро Speech Server было встроено в системы OCS 2007 и Exchange 2007. Более того, UM-роль системы Exchange 2007 в значительной степени представляет собой настраиваемое приложение Speech Server. В Exchange 2010 используется гораздо более современная версия Speech Server (она включена и в состав OCS 2007 R2). По состоянию на сегодня Exchange 2010 поддерживает средства ASR, TTS и подсказки для упрощенной и традиционной версий китайского языка; для голландского языка; для британского, австралийского и американского диалектов английского языка; для традиционного французского языка и его канадского диалекта; для немецкого, итальянского, японского, корейского языков, для бразильского диалекта португальского языка, для испанского языка (включая его каталанский и латиноамериканский диалекты), а также для шведского языка. Разработчики обещали создать пакеты для ряда дополнительных языков и диалектов, включая индийский диалект английского, русский и гонконгский диалект китайского языка. Благодаря этим добавлениям система Exchange 2010 стала куда более пригодной для развертывания в компаниях глобального масштаба, а также в организациях, которым приходится принимать звонки от абонентов, не говорящих на английском языке.

Изменения в процедуре определения идентификаторов вызывающих абонентов

Одна из самых полезных функций Exchange UM — ее способность определять телефонные номера вызывающих абонентов, что позволяет предоставлять вызываемым абонентам сведения о том, от кого поступил вызов, а также набор ссылок для осуществления ответного звонка. Каждый вызов, поступающий на сервер UM, должен включать в себя данные по идентификатору вызывающей линии calling line ID (CLID), который указывает на источник вызова. Учтите, что офисная АТС или шлюз могут искажать или даже вообще не приводить данные CLID; в этом случае Exchange не сможет разрешить соответствующий номер. В некоторых регионах существует вероятность того, что данные по CLID не поступают на АТС или на шлюз по каналам телефонной системы, хотя такие ситуации возникают все реже.

Проще всего телефонные номера определяются в тех случаях, когда известно имя вызывающего абонента, поскольку он (или она) размещает вызов с помощью функции голосового доступа к Outlook, или когда пользователь совершает звонок с Communicator либо Communicator Phone Edition. В подобных ситуациях пользователю следует пройти процедуру аутентификации, так чтобы Exchange мог идентифицировать абонента.

Если такой возможности нет, Exchange использует особый тип прокси-адреса, известный как прокси-адрес Exchange UM (EUM). Прокси-адрес EUM для данного пользователя, в сущности, представляет собой номер внутреннего телефона пользователя в сочетании с полным доменным именем Fully Qualified Domain Name (FQDN) абонентской группы, в которую он входит. Так, 1006@pa-hq.corp.contoso.local является прокси-адресом EUM для пользователя, который имеет номер внутреннего телефона 1006 в абонентской группе pa-hq.corp.contoso.local.

Система Exchange стремится сверять данные CLID по ряду источников. Первым делом она создает адрес EUM с информацией CLID и далее сопоставляет его с данными абонентской группы вызываемой стороны. Эта операция проводится на случай, если пользователь из одной абонентской группы звонит другому пользователю из той же абонентской группы. Если окажется, что это не так, созданный прокси-адрес сопоставляется с другими абонентскими группами организации; таким образом отрабатывается ситуация, когда пользователь, входящий в одну абонентскую группу, выполняет внутренний звонок пользователю из другой абонентской группы.

Если и этот метод не дает результата, выполняется проверка прокси-адреса EUM вызывающего абонента, чтобы определить, не похож ли этот адрес на идентификатор Uniform Resource Identifier (URI) действующего протокола Session Initiation Protocol (SIP), как, например, sip: paul@robichaux.net. Если адрес содержит символ @, выполняется проверка по списку известных прокси-адресов SIP с целью выяснения, не содержится ли данный адрес в этом списке. Если его там нет или если EUM-прокси содержит символ +, он нормализуется в формат E.164, после чего проверка повторяется, на этот раз с использованием атрибута AD msExchUMCallingLineIDs. Указанный атрибут приходится заполнять данными вручную с использованием команды Set-User, которая получает параметр -UMCallingLineIds. Упомянутый атрибут обеспечивает удобную возможность хранения телефонного номера, который можно сопоставлять с номерами вызывающих абонентов, но так, чтобы он не был виден пользователям. Если соответствующий номер не обнаружен, выполняется проверка атрибута msRTCSIP-Line; этот атрибут используется лишь в случае установки OCS 2007 (или более новой версии) и если добавочный номер вызывающего абонента зарегистрирован в OCS.

Если подходящий номер все еще не обнаружен, на следующем этапе нужно поискать его в AD. Каждый объект «пользователь» в AD имеет несколько потенциальных телефонных номеров: существуют атрибуты telephoneNumber, otherTelephone, homePhone, mobile и др., но эти атрибуты не индексированы, иначе говоря, процедура их поиска неэффективна. Поэтому пользователь может обеспечить возможность поиска в каталоге AD с помощью атрибута AllowHeuristicADCallingLineIdResolution в абонентской группе. В системе Exchange 2010 SP1 этот атрибут по умолчанию включен.

По первому впечатлению поиск в каталоге AD — замечательное решение, но оно сопряжено с одной проблемой: если при вводе номеров вы не пользовались релевантным и корректным форматом, то не сможете получить прогнозируемые или даже гарантированно корректные результаты. Специалисты Microsoft рекомендуют при введении этих номеров применять формат E.164, даже если вы не пользуетесь системой OCS или иной SIP-системой, которая предполагает его применение. Чтобы указать маску, с использованием которой Exchange будет конвертировать выбранный вами формат в некий другой формат, можете использовать атрибут -Numbering PlanFormats в абонентской группе.

И наконец, прокси-адрес EUM вызывающего абонента сопоставляется с содержимым папки пользователя personal Contacts, если функция Contacts для данной абонентской группы включена. Но Exchange 2010, к сожалению, не обеспечивает возможности сопоставлять идентификатор вызывающего абонента с данными о контактах, содержащимися в общедоступных папках.

На данном этапе возможны два варианта реакции системы Exchange. Если она обнаружила пользователя, соответствующего критериям поиска, имя этого пользователя будет отображено на экране, и в сообщение о поступившей голосовой почте или о пропущенном звонке будут включены все ассоциированные с ним номера телефонов. Если один из номеров соответствует критерию поиска, будут отображены все телефонные номера данного пользователя; так, если обнаружен рабочий телефон пользователя, результирующее сообщение (с соответствующими ссылками для звонка щелчком) будет включать в себя все номера, определенные для этого пользователя. Если же номер не найден, будет отображен только этот номер.

Средство просмотра голосовой почты в виде текста

Предварительный просмотр голосовых сообщений — превосходная новая функция Exchange 2010, которая пытается приоткрыть завесу таинственности, покрывающую голосовую почту. Вдумайтесь: когда мы получаем сообщение голосовой почты, мы можем знать, от кого оно поступило (а можем и не знать — это зависит от результатов процедуры сопоставления идентификатора вызывающего абонента), но, не прослушав сообщение, мы никак не можем узнать, важное оно или нет. Многое зависит от того, где мы находимся в данный момент. Иногда прослушивание сообщения может быть сопряжено с трудностями, а то и вовсе невозможно. Во многих ситуациях просмотреть содержимое почтового сообщения проще, чем прослушать сообщение голосовой почты. Вот тут-то и приходит на помощь функция предварительного просмотра голосовых сообщений, выполняющая преобразование речи в текст.

Первый вопрос, который люди чаще всего задают в этой связи, — а дает ли такое преобразование точные результаты? Ответ: иногда дает, а иногда — нет. Точность транскрибирования определяется множеством факторов, включая качество звука, скорость, с которой абонент произносит голосовое сообщение, а также наличие у абонента сильного акцента.

Одна из претензий, часто звучащих в адрес Exchange 2007 UM, состоит в том, что эта система по большей части ориентирована только на англоговорящих абонентов. Соответственно, задается и второй вопрос: ограничена ли функция предварительного просмотра голосовых сообщений американской версией английского языка? Конечно, нет: средства поддержки функции предварительного просмотра голосовой почты включаются в каждый языковой пакет. Однако язык, используемый для транскрибирования, определяется набором языков, заданным для абонентской группы номера вызываемой стороны. Поэтому, если франкоговорящий пользователь обратится к пользователю системы UM, чей номер внутреннего телефона входит в абонентскую группу, пользующуюся латиноамериканским диалектом испанского языка, Exchange попытается транскрибировать поступившее на французском сообщение на испанский манер — и выдаст нелепые и неточные результаты. Если оставить за скобками упомянутое ограничение, следует признать, что оснащение рассматриваемой функции многоязычными средствами — удачное дополнение.

Защищенная голосовая почта

Традиционные системы для работы с голосовой почтой уже давно позволяют маркировать сообщения как конфиденциальные. Такие сообщения нельзя пересылать другим пользователям. Эту возможность предоставляет и система Exchange 2010. Отправляя то или иное сообщение, пользователь может квалифицировать его как конфиденциальное, и Exchange применяет к нему шаблон службы управления правами Windows Active Directory Rights Management Service (AD RMS), с тем чтобы клиенты не могли перенаправлять его на другие адреса. Разумеется, для использования данной функции нужно прежде всего установить и привести в рабочее состояние AD RMS, а это задача непростая.

Пользователь может включить функцию защищенной голосовой почты отдельно для абонентов, прошедших процедуру аутентификации, и для лиц, не прошедших ее. Можно даже вменить в обязанность применять средства защиты для всех голосовых сообщений. Но возможность выбирать применяемый шаблон AD RMS не предусматривается; во всех случаях вам придется иметь дело с шаблоном Do Not Forward.

Защищенные голосовые сообщения могут воспроизводиться только на совместимых клиентах. По умолчанию их могут воспроизводить приложение Outlook Web App (OWA) 2010 и система Outlook 2010 с помощью встроенного потокового компонента «проигрыватель для различных носителей записи». Но, если это вас не устраивает, можете настроить систему так, чтобы пользователи могли прослушивать защищенные сообщения только с помощью Outlook Voice Access или Play on Phone; этот вариант, с одной стороны, самый безопасный, а с другой — самый полезный, поскольку клиенты OS X и Linux, а также мобильные устройства не смогут воспроизводить эти сообщения в неизмененной форме.

Индикатор получения сообщения

Системы голосовой почты прежних версий имеют еще одну функцию, не реализованную в Exchange 2007, — функцию извещения пользователей о том, что их ждет новое сообщение. Функция MWI имеет те или иные особенности в зависимости от используемой офисной АТС. В одних системах загорается лампочка в телефонном аппарате, в других — включается прерывистый сигнал готовности к набору.

Exchange 2010 поддерживает средства уведомления MWI; при включении этих средств сервер Exchange UM направляет офисной АТС извещение всякий раз, когда на один из управляемых почтовых ящиков поступает новое голосовое сообщение. Собственно извещение генерируется в ситуации, когда содержимое папки поиска голосовой почты (такая папка автоматически создается в почтовых ящиках пользователей при включении средств UM) изменяется. На эту папку подписывается сервер UM, так что каждый раз при получении или удалении голосового сообщения сервер UM получает уведомление и может направлять соответствующие извещения офисной АТС.

Его дальнейшая судьба зависит от АТС или от подключенных к ней устройств. Хранить голосовые сообщения в той же папке «Входящие», где хранятся все прочие сообщения, удобно, так что необходимость в использовании этой функции, по-видимому, отпадает, но для некоторых пользователей она имеет жизненно важное значение; мне не раз доводилось быть свидетелем того, как развертывание систем Exchange 2007 UM приостанавливалось до тех пор, пока не будет интегрировано решение MWI от сторонних производителей.

Надежный фундамент

.

Поль Робишо (getting-started@robichaux.net) — старший системный архитектор компании EntireNet, имеет сертификаты MCSE и MCT