Удаленное управление звонками в Office Communications Server (OCS) 2007 R2

Данная статья продолжает серию статей, посвященных таким функциям Office Communications Server (OCS) 2007, как предоставление единой среды связи, передача голоса по протоколу VoIP и проведение конференций. В ней я расскажу о функции удаленного управления звонками (RCC) для старых УАТС сервера Office Communications Server и о том, как RCC позволяет поддерживать различные варианты управления телефонными переговорами. Я также кратко коснусь двойной конфигурации и использовании в ней RCC для гибкого выполнения и приема звонков как на Office Communicator, так и на телефон УАТС.

В своей статье «Каким образом присутствие увеличивает возможности OCS 2007», приводится обзор того, как работают вместе различные части решения OCS 2007. В ней также была разъяснена ключевая роль присутствия в единой среде связи и его использование для эффективной маршрутизации голосовых звонков. В статье «Каким образом голосовая связь увеличивает возможности OCS 2007» я рассказал о том, как сервером OCS предоставляются возможности VoIP. Кроме того, я кратко рассмотрел различные варианты конфигураций для пользователя, уделяя основное внимание конфигурации Enterprise Voice.

В статье приводилось краткое описание еще одной конфигурации – RCC. Она поставлялась в составе Live Communication Server 2005 и позволяла Office Communicator 2005 управлять звонками с телефона УАТС. В OCS 2007 эта возможность по-прежнему доступна как альтернативная конфигурация и используется в случаях, когда сервер OCS 2007 устанавливается на существующее оборудование УАТС. Существует также вариант применения RCC с Enterprise Voice, где для управления своими звонками пользователи могут использовать как телефон УАТС, так и Office Communicator.

RCC — это возможность звонить или отвечать на звонки не с компьютера, а с другого устройства. Для OCS это означает следующее.

• Когда на телефон УАТС поступает звонок, то в программе Communicator появляется предупреждение, которое позволяет ответить на него.
• Если в программе Communicator щелкнуть чей-либо телефонный номер, то телефон УАТС подключается к линии в режиме устройства громкой связи и набирает этот номер.
• На телефоне УАТС можно установить переадресацию звонков.
• Входящие на определенный номер звонки можно переназначить на другие номера телефонов.
• Во время звонка телефона УАТС могут выполняться управляющие события, такие как однократная переадресация звонка и переадресация звонка с предварительным согласованием. С помощью пользовательского интерфейса Communicator с телефона УАТС можно отправлять сигналы DTMF.

Рис. 1. Конфигурация RCC

Большим отличием конфигурации RCC от Enterprise Voice является том, что в конфигурации RCC клиентам Office Communicator предоставлены только элементы управления, передающие сигналы на УАТС — звонки по протоколу VoIP им не отправляются. Другими словами, в этих конфигурациях Office Communicator не используется как IP-телефон.

В простейшей конфигурации RCC может быть развернуто путем установки шлюза SIP/CSTA между УАТС и OCS. Шлюз SIP/CSTA предоставляет интерфейс протокола SIP к OCS. Для связи с клиентами Office Communicator используются сигнальные сообщения, соответствующие международному стандарту обработки телефонных вызовов CSTA, упакованные в сообщения SIP.

На стороне УАТС шлюз SIP/CSTA использует частные интерфейсы передачи сигналов, предоставленные поставщиком конкретной УАТС. Как можно увидеть на рис. 1, для выполнения звонков в коммутируемую телефонную сеть общего пользования (PSTN) RCC использует подключение к PSTN, которое предоставляет УАТС. Кроме того, RCC использует систему голосовой почты, присоединенную к УАТС.

На рис. 2 представлена логическая схема, на которой показано, какое место в системе RCC занимают голосовые звонки. Как видите, клиент Office Communicator создает сеанс передачи сигналов, в котором клиент Office Communicator и шлюз SIP/CSTA обмениваются основанными на протоколе CSTA сообщениями управления звонками. Собственно звонок выполняется между настольным телефоном УАТС и удаленной конечной точкой, которой может быть еще один настольный телефон УАТС или конечная точка PSTN – или даже еще один пользователь с поддержкой Enterprise Voice, пользующийся телефоном OCS.

Рис. 2. Звонки в конфигурации RCC

Стандарт CSTA

Реализация RCC в Office Communicator основана на техническом отчете 87 (TR-87) ECMA. Это реализация модели CSTA, также предлагаемой ECMA, на основе SIP. Другой стандарт, ECMA 323, предоставляет подробную схему XML-сообщений, передаваемых по каналу SIP для реализации CSTA. Office Communicator использует подмножество возможностей и методов TR-87. Более подробная документация по поддержке стандарта CSTA в Communicator доступна через программу Microsoft Connect. Обратите внимание на то, что в оставшейся части данной статьи под CSTA понимается универсальный протокол, используемый между клиентами Office Communicator и УАТС.

Начальная загрузка канала удаленного управления звонками

В статье «Каким образом присутствие увеличивает возможности OCS 2007» я объяснил, почему универсальный код ресурса (URI) SIP является важной частью системы OCS и как каждому из пользователей присваивается URI SIP, позволяющий маршрутизировать звонки к пользователю. Когда клиенты Office Communicator обмениваются данными со шлюзом SIP/CSTA, им необходимо указать, каким телефоном требуется управлять с помощью Office Communicator. Телефонный номер указывается как URI линии, что по сути является телефонным номером в формате RFC 3966. Свойство URI сохраняется в записи пользователя Active Directory и становится доступным Office Communicator в рамках внутриполосной подготовки.

В ходе запуска клиенты Office Communicator должны подключиться к шлюзу SIP/CSTA (обращение к которому производится по адресу, определенному URI сервера в конфигурации пользователя OCS) для установки постоянного канала INVITE. Коммуникатор получает информацию о возможности использования RCC и URI сервера, используя механизм внутриполосной подготовки (это также разъяснено в статье «Каким образом присутствие увеличивает возможности OCS»).

Система RCC следует модели команда/ответ. Каждое сообщение, которое Office Communicator отправляет шлюзу SIP/CSTA, содержит команду, закодированную как полезные данные XML (ECMA 323). Каждый ответ или уведомление от шлюза SIP/CSTA также содержит полезные данные XML (ECMA 323). Первая команда SIP — INVITE — создает сеанс и содержит сообщение CSTA RequestSystemStatus. Шлюз SIP/CSTA принимает запрос и отвечает с данными RequestSystemStatusResponse в сообщении 200 OK (см. рис. 3).

Рис. 3. Модель приглашения со шлюзом SIP/CSTA

Обратите внимание на то, что BYE, который соответствовал бы INVITE, отсутствует. Причина в том, что INVITE устанавливает долгосрочный сеанс, в течение которого от Office Communicator могут быть отправлены дальнейшие команды, а от шлюза SIP/CSTA получены дальнейшие уведомления.

Когда последовательность INVITE/200 OK завершается, Office Communicator запрашивает возможности шлюза SIP/CSTA (который ссылается на возможности УАТС), чтобы получить набор поддерживаемых функций. После этого инициируется наблюдение за телефонной линией.

Запрос возможностей УАТС является важным этапом начальной загрузки – в зависимости от того, какие функции поддерживаются шлюзом SPI/CSTA, различные элементы пользовательского интерфейса в Office Communicator могут быть отключены или недоступны. Например, если шлюз SIP/CSTA не поддерживает однократную переадресацию звонка, то Office Communicator не покажет кнопку переадресации вызова в элементах управления звонком.

Таким образом, настройка RCC требует двух параметров, передаваемых клиентам Office Communicator. Первый – это URI сервера, то есть URI SIP, содержащий адрес шлюза SIP/CSTA и позволяющий клиентам Office Communicator подключаться к серверу, выдавая INVITE SIP по этому URI. (Этот URI обычно имеет форму gateway@contoso.com.)

Второй – это URI линии, то есть URI TEL, дающий уникальное обозначение телефонного номера в системе УАТС. Этот URI следует формату RFC 3966 (например, TEL:+14255551212 или TEL:4255551212;ext=1212).

После завершения начальной загрузки Office Communicator получает события от УАТС всякий раз, когда происходит изменение состояния наблюдаемой телефонной линии, которая определяется номером телефона. Когда программе Office Communicator необходимо позвонить или ответить на звонок, она отправляет сообщение INFO, содержащее XML-сообщения CSTA шлюзу SIP/CSTA. События, полученные от шлюза SIP/CSTA, также содержат XML-сообщения CSTA, внедренные в сообщения INFO SIP (пример см. на рис. 4).

 Рис. 4. Сообщение INFO и ответ 200 OK

INFO sip:gateway@contoso.com SIP/2.0
From: <sip:alice@ocs.contoso.com>;tag=31424bf782;epid=77e47b4782
To: <sip:gateway@ocs.contoso.com>;tag=1fbe74b0
Call-ID: 52c4a528322d4457a486283ccf78b696
User-Agent: UCCP/2.0.6362.0 OC/2.0.6362.0 (Microsoft Office Communicator)
Content-Disposition: signal;handling=required
Content-Type: application/csta+xml
Content-Length: 277
<?xml version="1.0"?>
<MakeCall xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
  <callingDevice>tel:+14255551212;ext=1212</callingDevice>
  <calledDirectoryNumber>tel:+14258828080;ext=5555</calledDirectoryNumber>
  <autoOriginate>doNotPrompt</autoOriginate>
</MakeCall>

SIP/2.0 200 OK
From: <sip:alice@ocs.contoso.com>;tag=31424bf782;epid=77e47b4782
To: <sip:gateway@ocs.contoso.com>;tag=1fbe74b0
Call-ID: 52c4a528322d4457a486283ccf78b696
Content-Disposition: signal;handling=required
Supported: 100rel,replaces,timer
User-Agent: Example Gateway Release 1.0 version 4.2.3
Contact: <sip:gateway@ocs.contoso.com>
Content-Type: application/csta+xml
Content-Length: 247
<?xml version="1.0" encoding="UTF-8"?>
<MakeCallResponse xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
  <callingDevice>
    <callID>17772</callID>
    <deviceID> tel:+14255551212;ext=1212</deviceID>
  </callingDevice>
</MakeCallResponse>

Отметьте, что в данном сценарии OCS играет роль прокси SIP. Любые сигнальные сообщения между клиентами Office Communicator и шлюзами SIP/CSTA передаются сервером OCS без искажений. Чтобы удостовериться в том, что шлюз SIP/CSTA работает, а канал передачи сигналов доступен, Office Communicator обновляет диалог INVITE каждые 10 минут, отправляя Re-INVITE с командой RequestSystemStatus.

Основная последовательность выполнения звонка MakeCall

Последовательность выполнения звонка выделена на рис. 5. Пользователь может позвонить на тот или иной номер, введя номер в окне поиска Office Communicator или выбрав номер телефона контакта в списке для звонка по щелчку. Когда пользователь решает позвонить на какой-то номер, Office Communicator выдает команду MakeCall шлюзу SIP/CSTA Gateway, содержащему номер телефона, выбранный для звонка. Интерфейс RCC позволяет пользователям выполнять звонки только на номера телефонов. Когда пользователь выбирает параметр Communicator Call для звонка кому-нибудь, Office Communicator выполняет звонок по протоколу VoIP, обращенный к URI SIP удаленного пользователя.

Увеличить

Рис. 5 Выполнение звонка

Последовательность сообщений, приведенная на рис. 5, показывает, как шлюз SIP/CSTA преобразует команду MakeCall в собственные сообщения УАТС, как телефон УАТС снимает трубку и направляет звонок на конкретный телефонный номер.

Обратите внимание на то, что интерфейс к шлюзу SIP/CSTA предоставляет сложные механизмы для указания различных состояний телефона. На этом примере можно увидеть, что Office Communicator получает множественные события, которые сообщают о том, что происходит на телефоне УАТС. Обмен начинается с события OriginatedEvent (указывающего на то, что телефон УАТС создает исходящий звонок) и заканчивается событием DeliveredEvent (указывающего на то, что телефон получил входящий звонок). Вполне возможно, что к моменту получения DeliveredEvent между телефоном и удаленным пользователем уже установлена среда передачи звуков звонка.

Когда происходит ответ на звонок, то УАТС отправляет соответствующие сигналы шлюзу SIP/CSTA, а программе Office Communicator передается событие EstablishedEvent, которое показывает, что на телефонный звонок кто-то ответил (см. рис. 6).

Увеличить

Рис. 6. Ответ на телефонный звонок

Основная последовательность ответа на телефонный звонок

При приеме телефонного звонка системой УАТС она оповещает шлюз SIP/CSTA. В свою очередь, шлюз SIP/CSTA создает уведомление CSTA DeliveredEvent, которое отправляется программе Office Communicator (см. рис. 7). Как только Office Communicator получает уведомление DeliveredEvent, информация о входящем звонке показывается пользователю.

Увеличить

Рис. 7. Ответ на звонок

Чтобы показать отображаемое имя звонящего, Office Communicator выполняет обратный поиск по имени (RNL) в контактах пользователя в Microsoft Office Outlook и в службе адресной книги. Теперь пользователь может ответить на звонок, о котором пришло уведомление, что ведет к отправке команды CSTA AnswerCall шлюзу SIP/CSTA. На этом этапе шлюз SIP/CSTA преобразует AnswerCall в соответствующее сообщение ответа конкретной УАТС, после чего между звонящим и телефоном УАТС устанавливается канал передачи.

Удаленное управление звонками и интеграция присутствия

Удаленное управления звонками (RCC) позволяет интегрировать состояние телефона пользователя с присутствием. Например, всякий раз, как пользователь звонит через УАТС, Office Communicator изменяет состояние этого пользователя на In a Call («Звонит»). Это состояние отображают клиенты Office Communicator других пользователей. Кроме того, пользователи могут публиковать свои личные номера телефонов через систему присутствия, позволяя звонить им на домашние или мобильные телефоны с помощью Office Communicator.

Тем не менее, когда присутствие Office Communicator 2007 установлено в состояние Do Not Disturb («Не беспокоить»), то возможность установить состояние «Не беспокоить» системы УАТС не используется. Пользователь должен вручную управлять этим состоянием системы УАТС.

Удаленное управление звонками и конференции

При выполнении звонка RCC Office Communicator 2007 не позволяет пользователю добавлять к звонку других пользователей с помощью Office Communicator. Тем не менее, пользователи все же могут создавать конференции, но для этого нужно использовать возможности самого телефона УАТС. При этом Office Communicator продолжает показывать звонок как звонок от одного пользователя второму, а не как конференц-связь.

Как и в случае с трехсторонним сценарием, входящие звонки конференц-связи на телефоне УАТС отображаются в Office Communicator звонками от одного пользователя другому, и на них можно отвечать как на такие звонки.

Удаленное управление звонками в Enterprise Voice с УАТС

В Enterprise Voice существует вариант совместного использования RCC и УАТС (который также известен как «двойное разветвление»). В варианте совместного использования Enterprise Voice и системы УАТС телефонные звонки разветвляются обеими системами, которые принимают звонки одновременно. Таким образом, пользователь может по своему выбору использовать для ответа как телефон УАТС, так и IP-телефон Office Communicator. Благодаря этому варианту пользователям доступны все преимущества Enterprise Voice.

Совместное использование в Enterprise Voice RCC и УАТС предоставляет уникальное взаимодействие: при единственном уведомлении о входящем звонке в Office Communicator пользователи могут отвечать на входящий звонок из Office Communicator или с обычного телефона (см. рис. 8).

Рис. 8. Выбор конечной точки для ответа на входящий звонок

Помимо этого, пользователи с переносными компьютерами могут использовать Office Communicator в качестве IP-телефона, чтобы совершать звонки, находясь вне здания своей компании. У пользователей даже есть возможность создавать звонки конференц-связи из Office Communicator, пользуясь возможностями конференций, предоставляемыми аудиовизуальными многоточечными управляющими узлами (MCU) сервера Office Communication Server.

Ограничения удаленного управления звонками

Удаленное управление звонками (RCC) предоставляет простой способ интеграции с существующим установленным УАТС. Тем не менее, возможности пользователя, использующего RCC, ограничены тем, на что способен проводной телефон УАТС. Например, пользователь Enterprise Voice может воспользоваться встроенной поддержкой OCS внешних голосовых возможностей, чтобы звонить и принимать звонки по протоколу VoIP как внутри организации, так и за ее пределами.

Enterprise Voice также позволяет применять несколько функций присутствия, предоставляемых OCS (например, уровни доступа к рабочей группе, обеспечиваемые присутствием, в результате чего появляется возможность разрешать срочные звонки даже в состоянии «Не беспокоить»). Пользователь с одним лишь RCC не будет иметь доступа к этим функциям. Помимо этого, только для пользователей Enterprise Voice поддерживаются другие функции, такие как расширение двусторонней конференции в многостороннюю конференцию.

В системе RCC правилами обработки звонков заведует УАТС. В силу этого любые параметры или правила, которые переадресуют звонки автоматически или направляют их в общую линию, на деле контролируются УАТС. Новые функции, доступные пользователю Enterprise Voice, в частности одновременные звонки и функция делегирования, представленные в OCS 2007 R2, недоступны тем, кто использует одно лишь RCC.

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

Тем не менее, в определенных случаях RCC предоставляет удобный способ использования возможностей телефонии с помощью OCS. Хотя оно и предлагает ограниченный по сравнению с Enterprise Voice набор возможностей, при использовании его внутри конфигурации Enterprise Voice (для двойного разветвления) RCC может предоставить пользователям богатый набор функций OCS вместе с гибкостью в выполнении и приеме звонков как с настольного телефона, так и из Office Communicator.