Каким образом голосовая связь увеличивает возможности OCS 2007

В первой части серии статей о Microsoft Office Communication Server (OCS) 2007 было показано, как OCS строился на сильных сторонах версии Live Communication Server (LCS) 2005: усовершенствованных возможностях мгновенного обмена сообщениями (IM) и возможностях отслеживания присутствия корпоративного уровня, а также улучшенных функциях телефона и передачи данных (см. выпуск журнала TechNet Magazine за февраль 2008 года на technet.microsoft.com/magazine/cc194409). В данной статье тема находит свое продолжение в виде углубленного изучения аспекта передачи голоса по IP (VoIP). Я объясню, как в системе OCS выполняются простые голосовые вызовы, и опишу технологию уровень за уровнем, так что каждый компонент будет добавляться вместе с соответствующими функциями.

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

Enterprise Voice Это законченное решение единой системы связи, использующее OCS вместе с сервером Microsoft® Mediation без необходимости в УАТС. Единая система обмена сообщениями Exchange (UM) предоставляет функции голосовой почты в этой системе. В оставшейся части статьи я буду именовать обладателей этой службы пользователями единой системы связи. Я также буду именовать клиентов в таком варианте оконечными точками этой системы.

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

Удаленное управление вызовами Эта функция использует телефон УАТС как основной телефон и позволяет управлять телефоном через клиент Office Communicator.

Базовые голосовые вызовы

Здесь я уделю основное внимание тому, как они работают для пользователей Enterprise Voice. Простые голосовые вызовы устанавливаются в системе OCS с использованием механизма сообщений INVITE («Приглашение») протокола SIP, как описано в RFC 3261. Сервер OCS играет роль прокси, подобно почтмейстеру, передающему сообщения между клиентами (или оконечными точками). Новые сообщения INVITE протокола SIP исходят от клиентов при каждом создании сеанса в реальном времени, такого как вызов или сеанс обмена мгновенными сообщениями. Если на сообщение INVITE следует положительный ответ (то есть удаленная оконечная точка посылает ответ 200 ОК), то устанавливается вызов (см. рис. 1).

Рис. 1 Формат сообщения INVITE и 200 OK

INVITE sip:bob@example.com SIP/2.0
To: 
From: ;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:alice@xyz.example.com
Content-Type: application/sdp
Content-Length: 156

**Note: Alice Audio SDP payload not shown**

SIP/2.0 200 OK
To: ;tag=f5c728454a;epid=e73443245
From: ;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:bob@xyz.example.com
Content-Type: application/sdp
Content-Length: 160

**Note: Bob Audio SDP payload not shown**

На рис. 2 Алиса звонит Бобу, выбирая звонок с помощью Communicator Call из Office Communicator (OC) 2007, после чего OC 2007 оправляет сообщение INVITE универсальному коду ресурса (Uniform Resource Identifier – URI) SIP Боба (sip:bob@example.com). Сообщение INVITE содержит дескриптор аудиосеанса (именуемый SDP – от протокола описания сеанса, Session Description Protocol) оконечных точек передачи данных, где Алиса может получить аудиопередачу. OCS рассылает сообщение INVITE по зарегистрированным оконечным точкам SIP Боба (например, Communicator Phone Edition и рабочий стол Communicator). Сообщение INVITE содержит заголовок From («От»), содержащий sip:alice@example.com; он используется конечными клиентскими точками Боба при обратном поиске по имени (RNL) для обнаружения имени (Алиса), которое следует показать в уведомлении о входящем вызове.

Рис 2 Маршрутизация вызова не несколько оконечных точек

Для каждой оконечной точки показан идентификатор URI глобально маршрутизируемого агента пользователя (Globally Routable User Agent URI – GRUU). GRUU дает уникальное определение каждой конечной точке SIP и получается от сервера OCS в процессе регистрации. Адрес GRUU помогает в маршрутизации сообщений SIP – скажем, после того, как на вызов отвечает конечная точка, последующая сигнализация SIP для операций, производимых в ходе вызова, может производиться между конечными точками, напрямую использующими адрес GRUU.

На рис. 3 показано продолжение процесса, в котором Боб отвечает с рабочего стола Communicator. OC Боба посылает сообщение 200 OK, говорящее, где он может принять голосовой вызов. Как только прокси OCS обнаруживает, что одна оконечная точка дала ответ, он отменяет вызов на все остальные оконечные точки Communicator Phone Edition. После того, как сообщение 200 OK достигнет оконечной точки Communicator Алисы, обе оконечные точки Communicator будут иметь достаточную информацию (порты IP, параметры шифрования и так далее) для начала передачи данных.

Рис 3: Ответ из одной оконечной точки (щелкните изображение, чтобы увеличить его)
 

Использование телефонных номеров

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

• сперва клиент нормализует телефонный номер и представляет его в виде идентификатора URI TEL, который описывает ресурсы, определенные телефонными номерами, как указано в RFC 3966.
• Поскольку OCS распознает лишь идентификаторы URI SIP, клиенты преобразуют идентификатор URI TEL в соответствующий идентификатор URI SIP путем добавления суффикса домена и тега user=phone.
• Если номер соответствует внутреннему пользователю, OCS маршрутизирует приглашение напрямую. Если номер внешний, то приглашение маршрутизируется к ближайшему шлюзу из SIP в коммутируемую телефонную сеть общего пользования.

Некоторые вызовы на номер коммутируемой телефонной сети общего пользования (public switched telephone network – PSTN) требуют установки среды передачи перед ответом на вызов, чтобы можно было воспроизводить удаленные заявления или собирать дополнительные цифры для выполнения звонка. В таких случаях шлюз коммутируемой телефонной сети общего пользования оправляет индикатор 183 Session Progress («183 ход сеанса») с аудио SDP. Communicator использует эту информацию для установки дуплексной среды передачи с одной оконечной точкой назначения, прежде чем удаленный пользователь ответит на звонок.

После того, как начальная среда передачи установлена, Communicator включает блок клавиш цифрового двухтонального многочастотного набора (DTMF) (сигналов тонального набора), позволяя пользователю вводить любые дополнительные цифры, требуемые удаленной системой. Любые введенные цифры тонального набора отправляются через среду передачи как пакеты RFC 2833. Шлюз коммутируемой телефонной сети общего пользования берет на себя создание соответствующих тональных сигналов DTMF на стороне коммутируемой телефонной сети общего пользования.

Отметьте, что если бы Боб включил одновременный звонок на свой сотовый телефон, прокси OCS одновременно маршрутизировал бы вызов к шлюзу и дал бы этот звонок на другие оконечные точки Communicator Боба. В подобных случаях прокси OCS указывает в ответе 183 Session Progress, что дублирование активно, и это заставляет Communicator установить канал получения с помощью шлюза коммутируемой телефонной сети общего пользования.

Безопасные вызовы

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

По умолчанию, шифрование в OC имеет параметр «дополнительно», что позволяет двум оконечным точкам OC установить зашифрованный канал передачи. Этот параметр может быть скорректирован администратором в соответствии с нормативными требованиями организации. Например, его можно сделать более жестким, заставляя шифровать все вызовы, или отключить полностью.

Прохождение через преобразование сетевых адресов (NAT) и брандмауэры

Клиенты в системе OCS используют технологию интерактивной установки связи (Interactive Connectivity Establishment – ICE) для установки каналов передачи данных к пользователям, защищенным устройствами преобразования сетевых адресов (Network Address Translation – NAT) и брандмауэрами, не требуя никаких изменений в существующих компонентах NAT. Рабочая группа проектирования Интернета (Internet Engineering Task Force – IETF) в настоящий момент работает над технологией стандартизации ICE. Каждый клиент учитывает наличие пограничного аудио/видео сервера, который работает через механизм предоставления входящей пропускной способности и поддерживает канал с проверенной подлинностью к этому серверу в ходе входа в систему.

Перед совершением вызова клиент распределяет ресурсы по возможным точкам подключения (адресам и портам, также известным как кандидаты) пограничного аудио/видео сервера (для передачи канала) на NAT или на размещающем клиенте. При отправке сообщения INVITE протокола SIP вся эта информация о подключении переносится как часть сообщения INVITE. Ответ 200 OK несет аналогичную информацию о кандидатах отвечающего узла. После того, как у каждой из оконечных точек имеется список этих кандидатов, сложный механизм ранжирования и проверки выбирает оптимальный путь между двумя узлами сети, на котором передача данных гарантированно будет удачной.

Маршрутизация по телефонным номерам

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

• Организации могут иметь различные абонентские группы, развертываемые внутренне, для краткого набора номера.
• Номера могут храниться в нестандартных форматах (например, пользователи могли сохранить строки из семи цифр в Microsoft Office Outlook®).
• Различным исходящим номерам могут соответствовать различные политики. Например, для определенных пользователей может быть заблокирован набор международных номеров.

Система OCS требует, чтобы телефонные номера были записаны в формате идентификаторов URI стандарта RFC 3966 TEL для их правильной маршрутизации. Если номера не в этом формате, они преобразуются перед выдачей клиентом сообщения INVITE. На чертеже на рис. 4 показано, как это происходит внутри системы OCS.

Рис 4. Маршрутизация телефонных номеров

Доступные клиенту номера могут происходить из различных источников. Предварительно нормализованные номера берутся из службы адресной книги (ABS), в которой содержатся определенные администратором правила нормализации для преобразования номеров в формат E.164. После того, как клиент выдает сообщение INVITE протокола SIP нормализованному номеру, OCS применяет процесс преобразования, чтобы сопоставить номер с любым внутренним пользователем

• Этап 1 показывает, что входящие в систему номера либо уникальны (нормализованы в соответствии с планом нумерации E.164), либо находятся в контексте телефона, определяющем местонахождение. Эти номера отсылаются серверу как часть сообщения INVITE протокола SIP. OCS маршрутизирует сообщение INVITE к процессу преобразования.
• Процесс преобразования (этап 2) пытается сопоставить телефонный номер с оконечной точкой единой системы связи, используя RNL на стороне сервера. Преобразование может определить маршрут номера к маршрутизации исходящих или к пользователю единой системы связи либо выдать сбой вызова с кодом 4xx, если номер не может быть правильно преобразован.
• Если номер преобразован во внешний номер или номер, не относящийся к единой системе связи, он может быть отправлен к компоненту исходящей маршрутизации, который перенаправляет сообщение INVITE к соответствующему шлюзу из SIP в коммутируемую телефонную сеть общего пользования для дальнейшей обработки после применения политик для номера, относящихся к вызывающему (этап 3A). Маршрутизация исходящих берет на себя балансировку нагрузки между шлюзами или переход на альтернативные шлюзы, если это необходимо. Процесс маршрутизации исходящих вызовов может закончиться сбоем или отвергнуть вызов, возвратив код ответа SIP 40, если для определенного номера доступ запрещен. Отметьте, что маршрутизация исходящих звонков применима только если вызывающий является пользователем UC. Когда это не так, OCS пытается использовать статические маршруты к шлюзам, установленные для данного идентификатора URI.
• Если номер преобразован в номер пользователя единой системы связи, то сообщение INVITE маршрутизируется к идентификатору URI SIP для данного пользователя (этап 3B). Маршрутизация входящих является функцией OCS, применяющейся только к пользователям единой системы связи и ко всем вызовам, направленным к идентификатору URI SIP. Как можно будет увидеть, маршрутизация входящих применяет правила по максимальному времени звонков, перенаправлению вызовов и перенаправлению голосовой почты для пользователя единой системы связи.

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

Маршрутизация входящих вызовов

Правила маршрутизации входящих вызовов указывают, как именно следует маршрутизировать пользователя в присутствии или отсутствии зарегистрированных клиентов в системе. Компонент маршрутизации входящих вызовов также занимается применением основанных на присутствии правил к входящему вызову; например, он может отправлять входящие вызовы на голосовую почту, если пользователь установил состояние присутствия Do Not Disturb («Не беспокоить»). Маршрутизация входящих учитывает уровни контейнеров присутствия и автоматически отвергает вызовы от пользователей в заблокированных контейнерах. На рис. 5 показана сводка вариантов, поддерживаемых компонентом маршрутизации входящих OCS.

 Рис. 5. Возможности по маршрутизации входящих

Правила маршрутизации входящих загружаются на сервер как схема XML в качестве части самопредоставляющейся информации пользователя. На рис. 6 показано, как действует маршрутизация входящих. Входящий вызов пользователю в системе OCS по умолчанию создает звонок у пользователя (показанного как "Me" («Я»)). Если по истечении продолжительности звонка ответа все еще нет, оставшийся без ответа вызов по умолчанию отсылается голосовой почте. Пользователь может изменить настройку по умолчанию, выбрав немедленное перенаправление на номер, на другого субъекта или напрямую на голосовую почту.

Рис 6. Маршрутизация вызовов (в рабочее время)

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

Если пользователь выберет параметр «Apply only during my Outlook Working Hours» («Применять только в мое рабочее время Outlook»), то правила, показанные на рис. 6, будут применяться в рабочее время, а поведение по умолчанию (звонки на зарегистрированных конечных точках) будет применяться в остальное время. Обратите внимание, что это поведение требует от организации развертывания клиентов Microsoft Exchange Server 2007 и Outlook 2007, поскольку Communicator использует информацию о рабочем времени из веб-службы доступности Exchange 2007, а также пользуется поддержкой автоматического обнаружения в Outlook 2007 для получения местонахождении сервера.

Отчеты о качестве связи и устранение неполадок

Хотя клиенты в системе OCS 2007 используют RTAudio, аудиокодек нового поколения, который может вытерпеть неидеальную работу сети, скажем нарушение синхронизации, потерю пакетов и так далее, наблюдение остается крайне важным для обнаружения и исправления потенциальных больных мест администраторами. Клиенты в системе OCS 2007 сообщают о качестве каждого вызова и предоставляют подробную статистику о нем, включающую потерю пропускной способности сети, нарушение синхронизации, среднюю оценку пользователей (меру их восприятия), используемые устройства и прочее центральному серверу контроля качества взаимодействия (QoE). Это проделывается путем отправки полезных данных в запросе SERVICE SIP к серверу QoE, адрес которого программируется с использованием механизма предоставления входящей пропускной способности.

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

Резюме

Теперь, перебрав несколько аспектов создания вызова, в том числе ввод номеров, маршрутизацию входящих и исходящих и проверки подключения, давайте взглянем на процесс в целом. На Рис. 7 дана сводка происходящего с момента совершения вызова пользователем. Клиенты в системе OCS играют ключевую роль в создании вызова и управляют всем его процессом. OCS задействована в первоначальной маршрутизации вызова, а пограничные серверы помогают клиентам найти оптимальный путь передачи. Давайте взглянем на то, что происходит дальше – разговор.

Рис 7. Процесс вызова от начала до конца (щелкните изображение, чтобы увеличить его)

Многорежимное поведение и беседы

Концепция бесед является центральной в системе OCS. Беседа – это многорежимный сеанс между двумя или более пользователями, который может одновременно включать аудио, видео и мгновенные сообщения, а также такие компоненты, как передачу файлов во время сеанса, электронную почту в Outlook или заметки, сохраненные в Microsoft Office OneNote®.

Существуют несколько аспектов бесед, которые могут повлиять на проект клиентских систем OCS:

• Все задействованные в беседе методы используют одно окно. Если к аудиобеседе добавлено мгновенное сообщение, оно связывается с тем же окном.
• Беседы могут охватывать несколько устройств. Пользователи могут выбрать ведение аудиочасти беседы на Communicator Phone Edition с получением мгновенных сообщений на рабочем столе Communicator.
• Все режимы расширяются до уровня конференции вместе: если расширение происходит, все методы беседы должны расширяться вместе независимо от того, на каком устройстве находится определенный метод. Например, если аудиорежим доступен на Communicator Phone Edition, а режим мгновенных сообщений для той же беседы на рабочем столе Communicator, то расширение до конференции гарантирует, что и аудиорежим, и мгновенные сообщения будут иметь одинаковый набор участников.
• В журнал записываются беседы, а не отдельные сеансы. Журналы вызовов содержат полную информацию о беседе, включая подробности о заметках, сделанных по ходу нее, обменах мгновенными сообщениями, продолжительности аудиосеанса и т.д. Это дает удобное сводное представление о всей беседе, когда пользователь открывает журнал звонков в Outlook.
• Беседы могут продолжаться из журналов бесед. Клиенты OCS связывают беседы вместе, используя идентификатор беседы (номер, уникальный для беседы и используемый для ее опознания на различных устройствах и приложениях). Существует замысловатый механизм вычисления разностности бесед, когда новые беседы запускаются из журнала старой беседы. Тот же идентификатор беседы сохраняется как идентификатор электронной почты в Outlook.

Идентификатор беседы перемещается как часть сообщения INVITE протокола SIP в виде специального свойства Ms-Conversation-Id. На Рис. 8 показана такая транзакция, где сперва добавляется голос, а затем мгновенное сообщение. Обратите внимание, что в конце многорежимной беседы журнал, сохраненный в Outlook, имеет тот же идентификатор беседы.

Рис 8. Многорежимные беседы и идентификатор беседы
 

Системой голосовой почты для OCS 2007 является единая система обмена сообщениями Exchange (UM). OCS может маршрутизировать звонки лишь для пользователей, у которых в единую систему связи включена поддержка UM Exchange. OCS предоставляет несколько функций для интеграции с UM Exchange:

• Параметр Call Voice Mail («Вызов голосовой почты») из интерфейса пользователя телефона Communicator (см. рис. 9) позволяет пользователю управлять почтовым ящиком системы обмена сообщениями, изменять приветствия и так далее, не вводя ПИН, поскольку его подлинность уже проверена.
• Индикатор ожидающего сообщения в интерфейсе пользователя Communicator (см. рис. 10) позволяет пользователю открыть папку голосовой почты Outlook, а в Communicator Phone Edition позволяет пользователю воспроизводить голосовые сообщения напрямую с телефона.
• Вызовы могут перенаправляться на голосовую почту из интерфейса пользователя Communicator.
• Отвергнутые звонки автоматически маршрутизируются на голосовую почту.
• Play on Phone («Воспроизвести на телефоне») из элемента голосовой почты в Outlook звонит прямо клиентам Office Communicator.

Рис. 9. Пункт меню Call Voice Mail («Вызов голосовой почты») в Communicator

Рис. 10. Индикатор ожидающего сообщения в Communicator

Механизм, с помощью которого OC получает уведомление о голосовой почте, отличается от Communicator Phone Edition. OC подписывается на новые уведомления о почте в папке поиска голосовой почты в Outlook и сообщает о новых сообщениях в этой папке. Communicator также использует пропущенные беседы и журналы вызовов.

Заключение

Я показал здесь работу голосовых вызовов в OCS 2007 – систему на основе SIP, пользующуюся несколькими RFC. Оконечные точки клиентов играют центральную роль в управлении вызовами в OCS. По умолчанию, все голосовые звонки надежно шифруются. OCS предоставляет гибкие компоненты, чтобы сделать возможным манипуляции с номерами и управление их потоком во всей системе.

Центральной концепцией OCS являются беседы, включающие голосовую связь, мгновенные сообщения и видео. OCS интегрируется с UM Exchange и позволяет уведомлять оконечные точки Communicator о голосовой почте, а также получать доступ к голосовой почте через Outlook или напрямую с сервера.