Все права принадлежат WindowsNetworking.com! Это вторая из трех частей серии, которая представляет собой целую главу о пакете ресурсов для сервера Microsoft Office Communications Server, выпуск которого ожидается в ближайшее время. Пакет ресурсов (Resource Kit) будет руководством для развертывания, настройки и поддержки Office Communications Server 2007 и будет включать множество экспертных мнений и советов непосредственно от команды разработчиков Microsoft Office Communications Server Team. Пакет ресурсов дает глубокое техническое описание архитектуры, развертывания, безопасности, администрирования, настройки производительности и диагностики Office Communications Server 2007.
Множество компонентов участвует в Office Communications Server местной конференции. Они управляют такими функциями, как аутентификация, авторизация, передача сигналов, контроль конференции, хранение и смешивание и обработка медиафайлов. Рисунок 5-1 показывает логические компоненты архитектуры конференций.
Рисунок 5-1: Архитектура компонентов конференций
Понимание клиентов конференций (Conferencing Clients)
Существует два типа клиентских приложений конференции, клиенты-планировщики и клиенты проведения конференции.
Клиенты-планировщики (Scheduling Client)
Клиент проведения конференции (Conferencing Client)
Разница между этими двумя типами клиентов только логическая, основанная на наборе функций, связанных с конференцией, которые каждый тип выполняет. На самом деле клиентские приложения могут иметь как возможности планирования, так и проведения конференции. Есть три основных типа клиентских приложений, используемый для конференций, расположенных на сервере Office Communications Server:
Консоль Microsoft Office Live Meeting Console 2007
Консоль Microsoft Live Meeting Console 2007 в первую очередь является клиентом проведения для запланированных веб конференций. Она поддерживает весь спектр модальностей, позволяющих участникам проводить эффективное собрание по сотрудничеству. К этим модальностям относятся следующие:
Консоль Microsoft Office Live Meeting Console 2007 также является и клиентом-планировщиком. Она имеет функцию Meet Now (встретиться сейчас), которая позволяет пользователям создавать немедленные конференции и приглашать других участников в рамках одной конференции. На следующем рисунке показан клиент:
Microsoft Office Communicator 2007
Microsoft Office Communicator 2007 в первую очередь является клиентским приложением для мгновенного общения и спонтанного сотрудничества. Оно имеет следующие возможности:
На рисунке показан групповой IM сеанс в клиенте Microsoft Office Communicator 2007:
Microsoft Conferencing Add-in для Microsoft Office Outlook
Microsoft Conferencing Add-in для Microsoft Office Outlook в первую очередь является клиентом-планировщиком. Добавления (add-in) позволяют пользователям использовать знакомый интерфейс Microsoft Office Outlook для планирования Communications Server конференции. Вдобавок к обычной информации конференции, за которую отвечает Outlook (время начала и окончания собрания, цикличность), добавления позволяют пользователям применить параметры собрания, которые будут специфичными для конференций Office Communications Server, например, тип доступа к собранию, список ведущих и аудио информация. Это приложение также создает приглашения с заданными параметрами, содержащие всю необходимую для регистрации информацию. Приглашение отправляется всем необходимым участникам по электронной почте.
Пользователи могут планировать два типа конференций:
Планирование собрания Live Meeting
Планирование конференции Conference Call
Следующий рисунок иллюстрирует Microsoft Conferencing Add-in для клиента Microsoft Office Outlook в действии:
Понимание базы данных конференции (Conferencing Database)
В архитектуре конференций Office Communications Server, две базы данных (RTC и RTCDyn) обеспечивают хранение свойств и состояния конференции соответственно. Эти базы данных располагаются на внутреннем SQL сервере.
База данных RTC хранит постоянную информацию пользователя, включая список контактов, информацию контроля доступа и статичную информацию конференции. Статичные свойства конференции хранятся в этой базе данных с момента ее создания и до момента ее удаления с сервера. Ниже приведен список свойств конференции:
База данных RTCDyn хранит изменяющуюся информацию состояния конференции, например обновленный список участников и их ролей, информацию подписки, замок конференции и т.д. Эта информация является специфичной для каждого случая конференции, и удаляется по окончании конференции. Однако очень важно сохранять эту информацию в базе данных во время конференции. Это обеспечивает высокую надежность и готовность конференции. Если один компонент сервера дает сбой или перестает отвечать, другой сервер с той же ролью может занять место предыдущего и служить для той же конференции, используя информацию этой базы данных.
| Непосредственно из первоисточника: Где хранится информация планирования конференции База данных RTC не содержит информацию планирования конференции. Поддержка времени начала и окончания, графика цикличности и исключений в цикле важна для предзапланированной конференции. Однако информация хранится не в базе данных конференции и не в Office Communications Server. Вместо этого информация календаря конференций сохраняется при помощи клиента-планировщика, как соответствующего. Например, Microsoft Conferencing Add-in для клиента Microsoft Outlook сохраняет информацию о времени как часть записи календаря Microsoft Exchange Server. ‘Hao Yan, Старший программный менеджер, OCS Server |
|---|
Понимание компонента Focus
Focus – это сервер состояния конференции, служащий в качестве координатора всех аспектов конференции. Он используется в качестве агента пользователя SIP, к которому можно адресовать, используя URI конференции. Focus работает на модуле User Services всех внешний серверов. Отдельный объект Focus существует для каждой активной конференции.
Focus отвечает за следующие задачи:
Когда новый тип медиасредства должен быть активирован для конференции, Focus отсылает конференцию на соответствующий конференцсервер, связывается с конференцсервером по поводу добавления нового пользователя, предоставляет мандаты авторизации, чтобы клиент мог подключиться к этой конференции, а затем направляет медиаинформацию клиенту. Та же последовательность выполняется для всех клиентов, желающих добавить эту медиаинформацию. Когда новый тип медиасредства добавлен к конференции, эта последовательность действий выполняется с новым конференцсервером для этого типа медиасредства. Централизуя обеспечение безопасности и управление реестром, Focus предоставляет эту обязанность всем конференцсерверам.
Понимание компонента Focus Factory
Focus Factory – это объект, создающий, удаляющий и модифицирующий собрания в базе данных конференции. Он также устанавливается в качестве агента пользователя SIP, к которому можно адресовать, используя Focus Factory URI. Когда клиентское приложение создает новую конференцию, клиент отправляет SIP SERVICE сообщение (которое несет команду C3P в своей нагрузке) объекту Focus Factory. Для более подробной информации о командах C3P смотрите раздел ‘Понимание протоколов конференции’. Focus Factory создает новую запись собрания в базе данных конференции и возвращает информацию, включая URI конференции, о создании новой конференции клиенту.
Заметка: Focus Factory запущен в том же процессе, что и Focus.
Понимание конференцсерверов (Conferencing Servers) и компонента Conferencing Server Factory
Поддержка конференций с несколькими участниками требует использования роли конференцсервера (также известной как MCU или компонент многоточечного контроля). Каждый тип конференцсервера ответственен за управление одним и более медиатипами. Office Communications Server 2007 включает четыре конференцсервера:
Веб конференцсервер (Web Conferencing Server)
Сервер A/V Conferencing Server
Сервер IM Conferencing Server
Сервер Telephony Conferencing Server
Конференцсервер состоит из двух логических частей: медиаконтроллер (MC) и медиапроцессор (MP). MC на конференцсервере отвечает за управление командами контроля между компонентом Focus и конференцсервером. В архитектуре Office Communications Server все команды контроля конференции отправляются клиентом на Focus, который направляет эти команды на соответствующий конференцсервер или серверы после проверки того, что клиент, отправивший этот запрос, имеет право выполнять такую операцию.
Данные обмениваются непосредственно между клиентами и конференцсервером или серверами. Медиапроцессор отвечает за управление данными, например, смешивание, распределение и транскодирование (прямой цифровой перевод кода сигнала из одного формата в другой). На сервере Web Conferencing Server медиапроцессор является компонентом ПО, отвечающим за управление процессом обмена данными. На сервере A/V Conferencing Server медиапроцессор смешивает аудио потоки, переключает видео потоки и конвертирует данные для клиентов с низкой скоростью соединения. Из всех компонентов конференции MP может быть потреблять максимальное количество ресурсов ЦП и сети. В архитектуре конференций Office Communications Server MC и MP совместно расположены на одной машине для упрощения процесса установки.
В конференции, когда требуется добавить новый тип данных, Focus посылает запрос на этот тип данных на конференцсервер через Conferencing Server Factory. Conferencing Server Factory является легковесным локальным компонентом, отвечающим за предоставление определенных типов данных конференции конференцсерверу. MCU Factory принимает в расчет текущую загрузку конференцсерверов, прежде чем подписать их на конференцию. На каждом внешнем сервер есть только один объект MCU Factory, управляющий всеми типами данных.
| Непосредственно из первоисточника: Шкала конференций Office Communications Server 2007 В начале на этапе планирования Office Communications Server 2007 мы знали, что критической точкой решения будет размер собраний, который поддерживается наш сервер. После изучения подобной продукции других производителей, разговоров с потребителями и изучения собственного опыта службы Live Meeting, стало очевидно, что подавляющее большинство собраний было слишком мало (от 4 до 6 участников). Копая глубже, мы обнаружили, что 80 процентов собраний поддерживали менее 20 участников и 99.98 процентов – поддерживали менее 100 участников. Затем мы опросили потребителей, чтобы выяснить, будет ли цифра в 200 — 250 участников отвечать их требованиям. Мы выяснили, что эта цифра будет отвечать их требованиям, с оговоркой на то, что иногда проводятся и более масштабные собрания, например, собрания всего рабочего коллектива, которые превысят этот лимит. Мы рассматривали вариант поддержки более масштабных собраний, но все же решили сконцентрировать свое внимание на типичных информационных рабочих собраниях (4 — 6 пользователей), оставляя запас для увеличения до 200 — 250 участников. Более масштабные собрания можно проводить с помощью службы Live Meeting, которая может насчитывать более 1000 участников. Помимо сырых характеристик таких собраний из нашего опыта было ясно, что потребуется преданный персонал и упорный труд, чтобы сделать такие большие собрания эффективными. По сути, это абсолютно иное решение, если его правильно выполнить. Как мы тестировали эту цель Наша пользовательская модель для тестирования производительности конференций учитывала несколько факторов: Сколько пользователей расположено на пуле Эффективный уровень взаимосовместимости для собраний Типы данных, доступные для каждого собрания Откуда подключаются пользователи: внутри предприятия, вне предприятия, смежные или анонимные Чтобы определить количество тестируемых собраний, мы взяли общее количество пользователей (к примеру, 50,000) и умножили эту цифру на уровень взаимосовместимости (к примеру, 5%). Это дает количество пользователей, которые предположительно будут участвовать в собрания постоянно (в данном примере, 2500 пользователей). Затем мы можем разделить эту цифру на количество используемых конференцсерверов (скажем, 2), и это дает нам количество участников на каждый сервер (в этом случае, 1250). Затем мы можем разделить эту цифру на средний размер собрания (к примеру, 6), и это дает нам среднее количество собраний на конференцсервер (в данном примере, ~ 210). Мы тестировали несколько собраний различных размеров, чтобы убедиться, что сервер соответствует требованиям. Этот расчет представляет среднюю нагрузку, которую мы тестировали. Один специфический тест, который мы выполняем, это подтверждение того, что мы действительно сможем поддерживать собрания с 250 участниками. Сюда входит аудио, видео и данные. В этом тесте мы запустили такое большое собрание на определенном конференцсервере (MCU). Мы не пытаемся запустить насколько таких собраний на одном сервере. Причина, по которой мы не хотим этого делать, кроется в полученных нами данных, которые показывают, что такой тип конференций очень редок. Никаких магических чисел Когда видишь такие числа как 250 (самый большой размер собрания), 1250 (количество пользователей на одном конференцсервере) и т.д., можно подумать, что это жестко закодированные значения. Но в нашем ПО на самом деле нет таких магических чисел. Скорее, эти числа представляют ту возможность, которую мы тестировали для конкретной пользовательской модели и конкретного сочетания физических устройств. Все это можно найти в руководстве по планированию для Office Communications Server 2007. Позвольте мне повторить: вы не найдете жестко закодированную цифру 250 в нашем сервере. У нас есть понятие максимального количества участников в собрании, которое контролируется администраторами с помощью политики собраний. Эта политика администратора может быть установлена в Microsoft Management Console (MMC) или в Windows Management Instrumentation (WMI). (Более подробную информацию можно найти на сайте http://technet.microsoft.com/en-us/library/bb676082.aspx.) Если вы взглянете на эти политики в консоли MMC, вы увидите, что значение по умолчанию гораздо меньше 250. И это не случайность. Предполагается, что пользователи, которым позволено создавать такие большие собрания, это привилегированные пользователи и потому имеют политику не по умолчанию. Политики собрания применяются к его организатору. Некоторым организаторам может быть разрешено создание собраний на 200 участников; другим — на 10. Это решение администратора, которое будет поддержано нашим ПО. Отодвижение границ Если 250 не жестко закодировано в ПО сервера, вы вполне справедливо можете поинтересоваться, что произойдет в случае превышения этого лимита. Прежде всего, позвольте мне пояснить, как сервер Conferencing Server управляет своей нагрузкой динамически. Когда первый пользователь присоединяется к собранию, для соответствующего типа данных назначается конференцсервер. (Прочтите раздел ‘Понимание Conferencing Servers и Conferencing Server Factory’ далее в этой главе, в котором поясняется работа конференцсерверов и список доступных типов в Office Communications Server 2007). Назначенный конференцсервер выбирается из набора серверов, ассоциируемых с пулом. В предыдущем примере было два веб конференцсервера в пуле для 50,000 пользователей. Каждый конференцсервер отвечает за управление своей нагрузкой и докладывает о возможности разместить дополнительные собрания. Если сервер превысил свои возможности, он докладывает об этом, и пул может назначить другой конференцсервер. Это все делается в режиме реального времени во время проведения собрания; мы не резервируем ресурсы заранее. Мы также не назначаем приоритеты одного собрания над другим при распределении ресурсов. Большое собрание на 250 участников, скорее всего, потребит все ресурсы одного конференцсервера, а другие собрания будут определены на другие конференцсерверы в этом пуле. Итак, скажем, вы проводите большую конференцию на 250 человек на одном конференцсервере, а 251-ый пользователь пытается присоединиться к вам. Если политика собрания позволяет это, а конференцсервер имеет дополнительное место, пользователю будет разрешено присоединиться. Такой тест выполняется для каждого пользователя, который присоединяется, и существует возможность того, что два больших собрания могут бороться за ресурсы на одном конференцсервере. Более мелкие собрания проще расположить на одном сервере, поскольку каждое из них требует меньше ресурсов. Емкость конференцсерверов в большей степени ограничивается ЦП и памятью. Мы протестировали и рекомендуем двухпроцессорные/двуядерные серверы с 4 GB памяти. Если вы используете более мощное оборудование, у вас будет больше емкости, и вы сможете проводить более масштабные собрания. Это не просто теория; мы используем более мощные серверы в службе Live Meeting, чтобы проводить более масштабные аудио/видео собрания. И вы тоже сможете. Наши рекомендации по оборудованию были основаны на разумном балансе типичного использования и цены (и снова, 99.98 процентов собраний включают менее 100 пользователей). Достижение числа 1000 пользователей в одном собрании возможно при наличии соответствующего оборудования; просто это не было самоцелью выпуска Office Communications Server 2007 и не то, что мы непосредственно поддерживаем на данный момент. Однако не стоит забывать, что речь здесь идет не только о возможностях сервера, есть ли у вас необходимая поддержка и процессы, позволяющие сделать собрание на 1000 пользователей успешным? Поддержка собрания таких размеров обычно подразумевает наличие преданного ИТ персонала для помощи во всех действиях ведущих, а также наличия инфраструктуры для рассылки всех приглашений, решения проблем, раздачи материала и т.д. Также необходимо убедиться в том, что у вас есть соответствующая сетевая инфраструктура с пропускной способностью, позволяющей размещать такие собрания. Правильный мониторинг и планирование возможностей позволит вам убедиться, что у вас есть соответствующее оборудование, отвечающее вашим нуждам. По мере роста ваших потребностей вы можете добавлять конференцсерверы (или внешние серверы в объединенной конфигурации) для их удовлетворения. Рекомендации для собраний больших размеров Вот несколько рекомендаций на тот случай, если вы хотите расширить границы размера собраний: Создайте выделенную политику для (ограниченных) организаторов, авторизированных на проведение таких больших собраний. В идеале, создайте выделенный пул для этих организаторов, чтобы можно было выделять оборудование непосредственно для таких собраний. Это одна из форм резервирования ресурсов. Вложите средства в поддержку инфраструктуры, необходимой для успешного проведения этих собраний (люди, процессы, сеть и оборудование) ‘ Sean Olson, главный менеджер группы программирования, OCS Server |
|---|
Понимание веб компонентов
Веб компоненты (Web Components) представляют собой набор ASP.NET приложений и виртуальных директорий, создаваемых на Internet Information Services (IIS) во время развертывания Office Communications Server 2007. Веб компоненты поддерживают следующие функции:
Понимание границ процесса и машины (Process & Machine Boundaries) для компонентов конференции
Рисунок 5-2 демонстрирует границы процесса и машины для всех компонентов конференции, которые мы обсудили в предыдущих разделах.
Рисунок 5-2: Граница процесса и машины всех компонентов конференции
Focus, Focus Factory, Conferencing Server Factory, IM Conferencing Server и Telephony Conferencing Server все работают как часть внешнего сервера. Их нельзя разделить и установить на разных машинах.
Web Conferencing Server и A/V Conferencing Server можно запустить на одной машине в качестве внешнего сервера (в объединенной конфигурации Office Communications Server 2007 Standard Edition или Enterprise Edition). Однако они также могут выступать в качестве раздельных ролей сервера, и их можно устанавливать на раздельное оборудование (Office Communications Server 2007 Enterprise Edition расширенная конфигурация). Такая конфигурация позволяет предприятиям разделять развертывание Office Communications Server 2007 посредством установки необходимого для их модели количества конференцсерверов. Хост для веб компонентов (IIS) может быть установлен, как часть каждого сервера Office Communications Server 2007 Standard Edition или Enterprise Edition в объединенной конфигурации, или же, как отдельная веб область за компенсатором нагрузки оборудования в расширенной конфигурации Enterprise Edition.
Понимание серверов Edge Servers
Office Communications Server 2007 позволяет пользователям организации, работающим за пределами корпоративной сети, участвовать в местных конференциях. Вдобавок, он дает право пользователям предприятия приглашать смежных и анонимных пользователей принимать участие в местных конференциях. Разрешение участия в конференции и возможности делиться данными с пользователями вне корпоративного брандмауэра требует следующих четырех ролей сервера в корпоративной сети:
Сервер Access Edge Server
Сервер Web Conferencing Edge Server
Сервер A/V Edge Server
HTTP Reverse Proxy
Рисунок 5-3 иллюстрирует архитектуру компонентов конференции с серверами edge servers.
Рисунок 5-3: Архитектура компонентов конференции с серверами edge servers
Понимание протоколов конференции (Conferencing Protocols)
В этом разделе обсуждаются различные протоколы для связи между различными компонентами в архитектуре конференции. По большому счету существует два класса протоколов, связанных с местными конференциями: протоколы сигнала и медиапротоколы.
Протоколы сигнала (Signaling Protocols)
Протокол сигнала относится к протоколам, способствующим созданию сеансов, обмену емкостями, обмену состояниями и контролю конференции.
Протокол инициализации сеанса (Session Initiation Protocol (SIP)) – это первичный протокол сигнала, используемый в Office Communications Server. SIP – это протокол стандарта отрасли, описанный в Internet Engineering Task Force (IETF) RFC 3261, который определяет стандартный способ выполнения установки сеанса, его удаления и обмена медиасредствами между двумя сторонами.
Методы SIP NOTIFY/BENOTIFY используются для передачи изменений в состоянии конференции. Состояние конференции описывает различные объекты, ассоциируемые с конференцией. Оно описывается с помощью пакета IETF RFC Conference Event (http://www.ietf.org/rfc/rfc4575.txt).
Различные задания модификации контроля и состояния конференции осуществляются посредством C3P протокола. C3P является аббревиатурой для Centralized Conferencing Control Protocol — протокол централизованного контроля конференции. Это протокол на основе XML, обеспечивающий тонкую оболочку вокруг пакета Conference Event (события конференции), а также предоставляющий различные специфические медиа расширения. Команды C3P могут передаваться с помощью методов SIP INFO или SERVICE. В общем, команды C3P можно разделить на три категории:
Компонент Focus и конференцсерверы связываются с помощью C3P и используют HTTPS в качестве протокола передачи для C3P. Клиенты связываются с Focus и Focus Factory, используя методы SIP INFO или SERVICE. SIP INVITE, ACK, BYE, UPDATE, и CANCEL методы используются для создания диалога сигнала между конференцклиентом и Focus. Клиент передает сигнал конференцсерверам с помощью соответствующих поддерживаемых протоколов: SIP для IM Conferencing Server, Telephony Conferencing Server и A/V Conferencing Server; и PSOM для Web Conferencing Server.
Медиапротоколы (Media Protocols)
Медиапротокол относится к протоколам, способствующим обмену определенными типами медиасредств между клиентами и серверами конференции.
Сервер Web Conferencing Server использует PSOM, Live Meeting протокол, для передачи и контроля содержимого конференции обмена данными с клиентами. Концепт распределенных объектов является ключевым для операций PSOM. Распределенный объект – это совокупность двух интерфейсов: один интерфейс для стороны объекта клиента, а второй – для стороны объекта сервера. Сообщения протоколов вписаны в методы этих интерфейсов. Клиентский интерфейс содержит сообщения, передаваемые на клиентскую сторону соединения. Интерфейс сервера содержит сообщения, которые отправляются на сторону соединения сервера.
Сервер IM Conferencing Server использует протокол Session Initiation Protocol для мгновенной передачи сообщений (Instant Messaging) и Presence Leveraging Extensions (SIMPLE) для связи с клиентами IM конференции. SIMPLE – это открытый стандарт, определяемый IETF RFC 3428 (http://tools.ietf.org/html/rfc3428).
RTP/RTCP – это стандартный протокол, используемый сервером A/V Conferencing Server для обмена аудио и видео потоками с клиентами конференции. RTP определяет стандартизированный формат пакета для доставки аудио и видео через Интернет. RTCP обеспечивает контрольную информацию вне полосы (out-of-band control information) для потока RTP. В Office Communications Server все передачи шифруются. Сервер A/V Conferencing Server на самом деле использует SRTP/SRTCP протокол, который обеспечивает шифрование через RTP/RTCP.
Рисунок 5-4 дает обзор того, как различные протоколы взаимодействуют с различными компонентами Office Communications Server.
Рисунок 5-4: Протоколы конференции
Каждая Office Communications Server конференция имеет свой жизненный цикл, как показано на рисунке 5-5. Конференция создается клиентом-планировщиком с помощью Focus Factory. Конференцию можно активировать, к ней можно присоединиться и дезактивировать ее в любой момент, после ее создания, ее также можно удалить с сервера по истечении ее срока действия. Конференция становится просроченной только по истечении срока действия.
Рисунок 5-5: Жизненный цикл конференции
Понимание создания конференции
Конференция Office Communications Server 2007 может быть создана одним из следующих способов:
Во всех вышеперечисленных сценариях клиент-планировщик связывается с Focus Factory, который создает записи в базе данных конференции. Только аутентифицированные пользователи предприятия, находящиеся на домашнем пуле Office Communications Server 2007 могут создавать конференции. Ключевые данные, вводимые Focus Factory, включают следующее:
Ключевые выводимые данные Focus Factory — URI конференции. URI конференции – это глобальный уникальный идентификатор, представляющий конференцию. Пример URI конференции приведен ниже:
sip:ben@contoso.com;gruu;opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A
Параметр opaque определяет тип ресурсов, сгенерированных или принадлежащих этому URI. Для URI конференции, это всегда компонент Focus, таким образом, параметр opaque для URI всегда содержит префикс app:conf:focus. URI конференции также содержит SIP URI организатора и ID конференции, которые вместе идентифицируют конференцию, как уникальную единицу.
URI конференции используется клиентами-планировщиками с целью создания URL для подключения к конференции. Для Microsoft Office Live Meeting Console конференций используется meet: URL, например:
meet:sip:ben@contoso.com;gruu;opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A
Для аудио конференций Microsoft Office Communicator используется conf: URL, например:
conf:sip:ben@contoso.com;gruu;opaque=app:conf:focus:id:a291a144d9764f38973835f816e52db1 %3Fconversation-id=b2796a94efe040cb9afadc49157557e6
Понимание активации конференции
Конференция активируется, когда первый участник успешно подключен. Первым пользователем, присоединившимся к собранию, может быть пользователь предприятия, смежный или анонимный пользователь. Пользователям разрешено подключение независимо от их роли ведущего или посетителя. Конференцию можно активировать в любое время после ее создания и до ее окончательного удаления из базы данных.
При активации конференции происходит следующее:
1. Объект собрания, под названием Focus, создается на внешнем сервере Office Communications Server. Этот объект конференции содержит следующую, присущую исключительно ему, информацию:
2. Создается SIP диалог между клиентом и Focus; создается подписка/публикация событий конференции.
3. Focus обеспечивает конференцсервер всеми необходимыми для конференции типами медиасредств. Эта информация задается при создании конференции.
4. Команда addConference C3P передается на все участвующие серверы. Каждый конференцсервер назначает ресурсы для конференции и готов к ее проведению.
5. Клиент создает прямое соединение с каждым участвующим конференцсервером.
Понимание дезактивации конференции
Собрание дезактивируется, когда объект конференции Focus удален с внешних серверов. Конференцию можно дезактивировать в любое время после ее активации следующими способами:
При дезактивации конференции происходит следующее:
Дезактивированная конференция все еще существует в RTC базе данных и может быть повторно активирована в любое время, пока не истек ее срок действия, как описано в следующем разделе.
Понимание срока действия конференции (Conference Expiration)
Для сохранения места на диске и улучшения производительности, Office Communications Server не хранит конференции и их содержимое в течение неопределенного срока. Когда конференция создается, ей назначается срок действия («годности») — expiration time. По истечении срока действия все записанные данные конференции удаляются из внутренней базы данных конференции и все данные, связанные с этим собранием удаляются. После истечения срока действия конференции ни один участник, включая организатора, не сможет к ней подключиться.
Внешний сервер использует процесс истечения срока с низким приоритетом для базы данных RTC. При пробуждении этот процесс ищет все конференции, соответствующие следующим критериям:
Любое собрание, соответствующее вышеупомянутым критериям, удаляется из RTC базы данных.
Право установки срока действия конференции принадлежит клиенту-планировщику при ее создании на сервере. Срок действия передается на каждый конференцсервер, участвующий в конференции. Вот некоторые рекомендации по типам конференции:
Заметка: Если клиентом не определяется срок действия, максимальный льготный период (шесть месяцев), разрешенный сервером, используется в качестве срока действия. Максимально допустимый льготный период возобновляется после каждой активации конференции. Например, после активации и дезактивации конференции ее срок истечет через шесть месяцев. Если активировать конференцию через три месяца, ее срок истечет через еще шесть месяцев, а не через три.
Web Conferencing Server запускает процесс истечения срока с низким приоритетом, как и внешний сервер. При пробуждении процесс сканирует содержимое метаданных конференции и проверяет каждую конференцию на предмет истечения ее срока. Web Conferencing Server устанавливает льготный период (по умолчанию 14 дней) поверх срока действия. Он удаляет содержимое папок, ассоциируемых с конференцией, только по истечении срока ее действия и прошествии 14 дней, то есть льготного периода. (продолжение следует)
www.windowsnetworking.com
Tags: Exchange, mac, nat, proxy, SQL, tun