Пакет ресурсов для сервера Microsoft Office Communications Server (Глава 5): Сценарии конференций (часть 3)

Права принадлежат WindowsNetworking.com! Это третья заключительная часть серии, которая представляет собой целую главу о пакете ресурсов для сервера Microsoft Office Communications Server, выпуск которого ожидается в ближайшее время. Пакет ресурсов (Resource Kit) будет руководством для развертывания, настройки и поддержки Office Communications Server 2007 и будет включать множество экспертных мнений и советов непосредственно от команды разработчиков Microsoft Office Communications Server Team. Пакет ресурсов дает глубокое техническое описание архитектуры, развертывания, безопасности, администрирования, настройки производительности и диагностики Office Communications Server 2007.

Содержимое этих статей было взято из Главы 5 авторов: Hao Yan из Microsoft Office Communications Server Resource Kit, Jeremy Buch, Jochen Kunert, и Rui Maximo совместно с Byron Spurlock, Hao Yan, James OпїЅNeill, John Clarkson, Kintan Brahmbhatt, Mitch Tulloch, Rick Kingslan, Stephanie Lindsey, и группой разработчиков Microsoft Office Communications Server Team. Переиздано с разрешения Microsoft Press. Все права защищены. Для дополнительной информации перейдите по http://www.microsoft.com/MSPress/books/10482.aspx.

Рассмотрение технических деталей, лежащих в основе веб конференций

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

• Конференцклиенты, соединяющиеся с Focus
• Конференцклиенты, соединяющиеся с Web Conferencing Server
• Конференцклиенты, загружающие данные на Web Conferencing Server
• Конференцклиенты, принимающие данные с Web Conferencing Server и отображающие их

Понимание последовательности подключения конференцклиентов (Client Conference Joining Sequence)

Пользователь может подключиться к конференции двумя основными способами:

• Нажав по ссылке «Подключиться» в почтовом сообщении, содержащем приглашение к конференции или на ссылке «Подключиться» в IM окне Office Communicator 2007
• Запустив консоль Microsoft Office Live Meeting Console и введя регистрационную информацию

Рисунок 5-6 показывает процесс подключения клиента к конференции:

Рисунок 5-6: Последовательность подключения клиента к конференции

Клиенты Microsoft Office Communicator 2007 и Microsoft Office Live Meeting Console 2007 регистрируют обработчика протоколов операционной системы при их установке. Microsoft Office Communicator 2007 регистрирует обработчика протоколов для conf: протокола, а Microsoft Office Live Meeting Console 2007 регистрирует обработчика для meet: протокола. Когда пользователь нажимает по ссылке «Подключиться» (Join) в сообщении приглашения или в IM окне, запустится нужный клиент в зависимости от префикса conf: или meet: на URL для соединения.

Первый шаг, который выполняет клиент конференции после запуска, это открытие Office Communications Server для пользователя, в зависимости от настроенных пользовательских SIP URI в клиенте. Логика открытия выполняет серию DNS SRV запросов, основанных на доменной части пользовательских SIP URI. После DNS SRV запроса могут возникнуть следующие четыре ситуации:

1. Office Communications Server найден, и это тот сервер, на котором расположена конференция. В этом случае клиент отправляет информацию SIP INVITE на сервер. Пользователь присоединяется к конференции в качестве аутентифицированного пользователя предприятия.
2. Office Communications Server найден, и этот сервер объединен с Office Communications Server, на котором расположена конференция. В этом случае клиент отправляет SIP INVITE на сервер Office Communications Server 2007, на хосте которого расположена конференция. Пользователь аутентифицируется сервером Office Communications Server 2007 в собственном домене, и SIP INVITE успешно направляется на пул Office Communications Server, на хосте которого расположена конференция. Пользователь присоединяется к конференции в качестве смежного пользователя.
3. Сервер Office Communications Server 2007 найден, и этот сервер объединен (смежен) с сервером Office Communications Server 2007, на хосте которого расположена конференция. В этом случае клиент отправляет SIP INVITE на сервер Office Communications Server 2007, на котором расположена конференция. Пользователь аутентифицируется сервером Office Communications Server 2007 в собственном домене. Однако SIP invite не может быть успешно маршрутизирован, поскольку нет смежной связи между собственным Office Communications Server доменом пользователя и доменом Office Communications Server организатора конференции (сопровождается отчетом SIP 504 дополнительно к SIP INVITE). В этом случае клиент конференции попытается присоединиться к конференции в качестве анонимного пользователя. Клиенты конференции должны иметь возможность успешно генерировать уникальный и случайный анонимный SIP URI формы <ID>@anonymous.invalid при подключении к конференции в качестве анонимных пользователей.
4. Сервер Office Communications Server 2007 не найден. В этом случае, клиент конференции попытается присоединиться в качестве анонимного пользователя. Клиенты конференции должны иметь возможность успешно генерировать уникальный и случайный анонимный SIP URI формы <ID>@anonymous.invalid при подключении к конференции в качестве анонимных пользователей.

SIP INVITE, отправляемый клиентом должен содержать команду addUser C3P в качестве основной части сообщения SIP. Например:

INVITE sip:ben@contoso.com;gruu;opaque=app:conf:focus:id: 5D3747C1DEEB684B8962F4078723A65A SIP/2.0 От кого: <sip:ben@contoso.com>;tag=958d8a3fbc;epid=c5574cd6b6 Кому: <sip:ben@contoso.com;gruu;opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A> Content-Type: application/cccp+xml Content-Length: 736 <request C3PVersion=»1″ to=»sip:ben@contoso.com;gruu;opaque=app:conf:focus:id: 5D3747C1DEEB684B8962F4078723A65A» from=»sip:ben@contoso.com» requestId=»0″><addUser> <conferenceKeys confEntity=»sip:Ben@contoso.com;gruu;opaque=app:conf:focus:id: 5D3747C1DEEB684B8962F4078723A65A»/> <ci:user entity=»sip:Ben@contoso.com»> <ci:roles> <ci:entry>attendee</ci:entry> </ci:roles> <ci:endpoint entity=»{339F927D-6AD4-4090-9104-8414B99EE045}» /> </ci:user></addUser> </request>

Запрос addUser содержит URI конференции и SIP URI пользователя, которые должны быть такими же, как SIP кому от кого URI, соответственно. Вдобавок, он может содержать запрос на определенную роль. Объект конечной точки является необязательным, и Focus игнорирует основную часть объекта конечной точки (endpoint entity), а использует только объект URI, предоставленный клиентом.

На рисунке 5-7 показана логика управления сервера таким запросом SIP join INVITE.

Рисунок 5-7: Последовательность подключения клиента, вид сервера

Когда команда addUser C3P принята, Focus отвечает с назначенной ролью посредством 200 ответа:

SIP/2.0 200 Invite dialog created Contact: <sip:sip.contoso.com:5061;transport=tls>;isfocus Content-Length: 1095 От кого: «Ben Miller»<sip:Ben@contoso.com>;tag=958d8a3fbc;epid=c5574cd6b6 Кому: <sip:Ben@contoso.com;gruu;opaque=app:conf:focus:id: 5D3747C1DEEB684B8962F4078723A65A>;tag=CC020080 Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE Content-Type: application/cccp+xml <response requestId=»0″ C3PVersion=»1″ from=»sip:Ben@contoso.com;gruu;opaque=app:conf:focus:id: 5D3747C1DEEB684B8962F4078723A65A» to=»sip:Ben@contoso.com» code=»success»><addUser> <conferenceKeys confEntity=»sip:Ben@contoso.com;gruu;opaque=app:conf:focus:id: 5D3747C1DEEB684B8962F4078723A65A»/> <ci:user entity=»sip:Ben@contoso.com»> <ci:roles> <ci:entry>presenter</ci:entry> </ci:roles> </ci:user></addUser> </response>

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

NOTIFY sip:157.56.67.50:2383;transport=tls;ms-opaque=02e9ae1f28; ms-received-cid=00031600;grid SIP/2.0 Кому: <sip:Ben@contoso.com>;tag=ccb81c3509;epid=c5574cd6b6 Content-Length: 2373 От: <sip:Ben@contoso.com;gruu;opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A>;tag=183C0080 Content-Type: application/conference-info+xml Event: conference subscription-state: active;expires=3600 <conference-info entity=»sip:Ben@contoso.com;gruu;opaque=app:conf:focus:id: 5D3747C1DEEB684B8962F4078723A65A» state=»partial» version=»2″> <users state=»partial»> <user entity=»sip:Ben@contoso.com» state=»full»> <display-text>Ben Miller</display-text> <roles> <entry>presenter</entry> </roles> <endpoint entity=»{339F927D-6AD4-4090-9104-8414B99EE045}» msci:session-type=»focus» msci:endpoint-uri=»sip:Ben@contoso.com;opaque=user:epid:AD0UTS5DclOh9zyK1XWK2AAA;gruu»> <status>connected</status> </endpoint>

После того, как SIP диалог сигнала успешно создан, клиент конференции и Focus создают диалог подписки. Сначала клиент отправляет SIP SUBSCRIBE:

SUBSCRIBE sip:Ben@contoso.com;gruu;opaque=app:conf:focus:id: 5D3747C1DEEB684B8962F4078723A65A SIP/2.0 От: <sip:Ben@contoso.com>;tag=958d8a3fbc;epid=c5574cd6b6 Кому: <sip:Ben@contoso.com;gruu;opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A> Event: conference Accept: application/conference-info+xml Supported: com.cotoso.autoextend Supported: ms-benotify Proxy-Require: ms-benotify Supported: ms-piggyback-first-notify Content-Length: 0

Затем Focus обрабатывает подписку. Если не найдено ни одного активного соответствующего диалога сигнала, Focus отвергает подписку. Как только подписка принята, Focus реагирует на нее, и затем генерирует сообщение.

SIP/2.0 200 OK Content-Length: 3611 От: «Ben Miller»<sip:Ben@contoso.com>;tag=0dc4a6c3d2;epid=c5574cd6b6 Кому: <sip:Ben@contoso.com;gruu;opaque=app:conf:focus:id: A24F0AA5223B4B478801FA8F60D2191D>;tag=31740080 Expires: 3546 Content-Type: application/conference-info+xml Event: conference subscription-state: active;expires=3546 ms-piggyback-cseq: 1 Supported: ms-benotify, ms-piggyback-first-notify пїЅ

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

После того, как оба диалога созданы, клиент конференции может получить сообщения об изменении состояния конференции, (например, еще одно подключение) от компонента Focus. Рисунок 5-8 иллюстрирует последовательность подключения клиента focus.

Рисунок 5-8: Последовательность подключения Focus

Понимание последовательности подключения клиента к серверу Web Conferencing Server

Команда addUser C3P используется клиентами конференции для подключения к конференцсерверу, участвующему в конференции. Команда addUser работает в двух режимах: dial-in и dial-out. В режиме dial-in клиент отправляет addUser на конференцсервер (сообщение передается с помощью Focus) для запроса разрешения на создание сеанса с ним. В ответе addUser конференцсервера содержится информация соединения, которая используется клиентом для созданий сеанса сигнала и медиасеанса. В режиме addUser dial-out, клиент отправляет запрос конференцсерверу на инициализацию создания сеансов сигнала и медиасеансов (signaling/media session), поэтому команда addUser завершается только после того, как сеанс создан.

Клиенты конференции используют режим addUser dial-in для подключения к серверу Web Conferencing Server. Рисунок 5-9 иллюстрирует порядок подключения клиента к Web Conferencing Server.

Рисунок 5-9: Последовательность подключения к Web Conferencing Server

Некоторые сообщения, которые клиент конференции получает от Focus после подключения к конференции, содержат информацию о URI конференцсервера, например:

NOTIFY sip:ben@contoso.com SIP/2.0 … <conference-info xmlns=»urn:ietf:params:xml:ns:conference-info» entity=»sip:ben@contoso.com;gruu; opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A» state=»full» version=»5″ > <conference-description> <display-text>Weekly Sales Meeting</display-text> <subject>Agenda: This monthпїЅs goals</subject> <conf-uris> <entry> <uri>sip:ben@contoso.com;opaque=conf:meeting: id:5D3747C1DEEB684B8962F4078723A65A</uri> <display-text>meeting</display-text> <purpose>meeting</purpose> </entry> <entry> <uri>sip:ben@contoso.com;opaque=conf:audio-video: id:5D3747C1DEEB684B8962F4078723A65A</uri> <display-text>audio video mcu</display-text> <purpose>audio-video</purpose> </entry> </conf-uris> </conference-description> … </conference-info>

Чтобы подключиться к Web Conferencing Server, клиент затем создает запрос addUser C3P, запрашивая у Focus возможности подключиться (dial-in) к Web Conferencing Server. Запрос содержит роль, соответствующую текущей роли пользователя в конференции, определяет значение метода подключения (joining-method value) dialed-in, а также предоставляет конечную точку, которая, как правило, служит GUID для сеанса. From (от кого) URI запроса SIP должен соответствовать атрибуту from запроса C3P. Атрибут mcuUriдолжен присутствовать в элементе addUser, и он определяет MCU (конференцсервер), на который должен быть направлен этот запрос. В нижеприведенном случае Web Conferencing Server URI будет следующим:

sip:ben@contoso.com;opaque=conf:meeting:conf-id

Вот пример этого addUser C3P запроса:

INFO ConfURI To: ConfURI From: sip:ben@contoso.com;tag=f7588dc66124429ab736;epid=1 …SIP headers.. <request xmlns=»urn:ietf:params:xml:ns:cccp» requestId=»2″ from=»sip:ben@contoso.com» to=»sip:ben@contoso.com;gruu; opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A»> <addUser mscp:mcuUri=»sip:ben@contoso.com;opaque=conf:meeting: id:5D3747C1DEEB684B8962F4078723A65A»> <conferenceKeys confEntity=» sip:ben@contoso.com;gruu; opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A»> <user entity=»sip:ben@contoso.com»> <roles> <entry>presenter</entry> </roles> <!пїЅExactly one endpoint node may be present —> < endpoint entity=» {F43E937E-6C66-4649-9481-13133FCF64FE}»> <!пїЅExactly one joining-method and it must be equal to dialed-in —> <joining-method>dialed-in</joining-method> <!— Optional MCU specific parameters —> </endpoint> </user> </addUser> </request>

Focus перенаправляет dial-in запрос на Web Conferencing Server после вписания в него URI организатора и необходимой авторизации. Если Web Conferencing Server решает принять C3P запрос, он должен создать стандартный addUser ответ и вернуть его на Focus, который затем направит ответ клиенту.

Все конференцсерверы должны предоставлять контактную информацию, которую клиент будет использовать для подключения. Для конференцсерверов, использующих SIP в качестве протокола сигнала (таких, как A/V Conferencing Server), требуется форма предоставления SIP Contact URI и SIP To URI. SIP To URI должен всегда быть равен mcuUri предоставляемому в addUser запросе. SIP Contact URI относится к Conferencing Server URI (прослушивающий адрес/порт/транспортировщик, через который конференцсервер прослушивает и может получать SIP запросы). Для Web Conferencing Server, который использует PSOM вместо SIP, требуется форма предоставления подходящего URL, который клиент сможет распознать.

Некоторые конференцсерверы могут предоставлять символы авторизации или некоторые другие параметры для клиентов. Семантика таких параметров представляется собой контракт между сервером и клиентом конференции. Вот примерный ответ на addUser запрос для подключения к Web Conferencing Server:

From: < sip:ben@contoso.com;gruu; opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A>; tag=052B0080 To: <ben:ben@contoso.com>;tag=d1991b44ef;epid=10caaf88e2 … <response from=» sip:ben@contoso.com;gruu; opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A» to=»sip:ben@contoso.com» responder=» sip:ben@contoso.com; opaque=conf:meeting: id:5D3747C1DEEB684B8962F4078723A65A» code=»success»>

<addUser><conferenceKeys confEntity=» ben@contoso.com;gruu; opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A»/>

<user xmlns=»urn:ietf:params:xml:ns:conference-info» entity=»sip:ben@contoso.com»><display-text>Hao Yan</display-text><roles><entry>presenter</entry></roles><endpoint entity=»{1D3F15F1-68CA-4EF0-9805-704EB5795F60}»><joining-method>dialed-in</joining-method><media id=»1″><type>meeting</type><label>meeting</label></media><authMethod xmlns=»http://schemas.microsoft.com/rtc/2005/08/confinfoextensions»> enterprise</authMethod><accessMethod xmlns=»http://schemas.microsoft.com/rtc/2005/08/confinfoextensions»> internal</accessMethod>

</endpoint></user><info xmlns=»http://schemas.microsoft.com/rtc/2005/08/cccpextensions»><contact>pod/ben/check/check1.html</contact></info><connection-info xmlns=»http://schemas.microsoft.com/rtc/2005/08/cccpextensions»><entry><key>serverURL</key><value>https://conference.contoso.com/etc/place/null</value></entry><entry><key>pw.eName</key><value>sip:ben@contoso.com;gruu; opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A </value></entry><entry><key>PodName</key><value> ben@contoso.com;gruu; opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A</value></entry><entry><key>pwuid</key><value>sip:ben@contoso.com</value></entry><entry><key>sAuthId</key><value>71C00000000000001A36B1629961D219</value></entry><entry><key>pwrpc.modes</key><value>tls</value></entry><entry><key>pwrpc.port</key><value>8057</value></entry><entry><key>pwrpc.authPattern</key><value>&lt;sAuthId&gt;</value></entry><entry><key>pw.rtcp.enabled</key><value>false</value></entry><entry><key>pwrpc.tcpEnableSig</key><value>false</value></entry><entry><key>locale</key><value>en_US</value></entry><entry><key>directURL</key><value>https://conference.contoso.com:8057</value></entry><entry><key>pwrpc.pwsURI</key><value>https://conference.contoso.com:8057</value></entry><entry><key>uType</key><value>pre</value></entry><entry><key>alternativeName</key><value>conference.contoso.com</value></entry></connection-info></addUser></response>

Информация, включенная в C3P ответ, состоит из следующих компонентов:

• Fully Qualified Domain Name (FQDN – полное доменное имя машины) или IP адрес сервера Web Conferencing Server и номер порта.
• URL для загрузки HTTP содержимого.
• Информация доступа (FQDN и порт) для множества, одного, или более Web Conferencing Edge Servers, если клиент подключается вне корпоративного брандмауэра.
• Авторизирующий файл cookie для Web Conferencing Edge Server, если клиент подключается вне корпоративного брандмауэра. Файл cookie закодирован в base64. Клиенту необходимо предоставить этот файл cookie при создании соединения с Web Conferencing Edge Server.
• Авторизационный cookie для Web Conferencing Server. Этот cookie также закодирован в base64. Клиенту необходимо предоставить этот cookie при создании соединения с Web Conferencing Server.
• Уникальный идентификатор для собрания (например, Conference URI). Он необходим для того, чтобы клиент мог определить, к какой конференции он подключается, соединяясь с Web Conferencing Server.

Понимание контроля конференции (Conference Control)

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

• Команды, которые блокируются на Focus и не включают MCU взаимодействие (например, renameUser)
• Команды авторизированные компонентом Focus, но просто передаваемые конференцсерверам, чтобы состояние Focus не было изменено, если только конференцсервер не сгенерирует предупреждение (например, modifyEndpointMedia)
• Команды обрабатываемые как Focus, так и конференцсервером (например, deleteConference, modifyConferenceLock)

Типичная команда контроля конференции работает по следующему принципу:

1. Клиент отправляет SIP INFO запрос на Focus, в основной части которого содержится команда C3P.
2. Focus подтверждает и авторизирует C3P запрос.
3. Focus обрабатывает C3P запрос и генерирует один или более SIP ответов обратно клиенту, содержащих C3P незаконченный или окончательный ответ.
4. Focus может направить или ответвить запрос еще одному конференцсерверу в случае необходимости. Ответы с конференцсерверов направляются обратно к клиентам, за исключением случая ответвленной команды (forking-command), где они обрабатываются компонентом Focus.
5. Все объекты содержат таймеры C3P трансакций для контролирования срока действия запроса.

Когда Focus принимает команду от отправителя, он обычно генерирует C3P запрос для сервера конференции, а также отвечает с помощью SIP 202 Accepted сообщения на INFO запрос. Когда результаты C3P доступны, Focus генерирует другой INFO запрос и отправляет его клиенту. C3P запрос может быть успешным или неуспешным, а также успешным/неуспешным после того, как промежуточный ответ был сгенерирован. Более того, успешный C3P запрос обычно сопровождается отправкой C3P сообщения с сервера, содержащего информацию об обновленном состоянии конференции. При получении такого сообщения Focus обновляет состояние конференции и генерирует сообщение для всех клиентов.

Рисунок 5-10 демонстрирует поток звонков C3P modifyConferenceLock команды. Эта команда выпускается, когда организатор конференции пытается блокировать (lock) или разблокировать (unlock) конференцию в клиенте. В этом случае команда разветвляется компонентом Focus и направляется на A\V Conferencing Server и Web Conferencing Server.

Рисунок 5-10: Последовательность подключения к Web Conferencing Server

Понимание управления содержимым Web Conferencing Server

В Office Communications Server 2007, Web Conferencing Server хранит содержимое данных конференции и информацию ее состояния в файлах. Для каждого Office Communications Server пула настроены два файловых ресурса (директории):

• Ресурс файлов метаданных, используемый для хранения информации состояния конференции и метаданных, описывающих содержание данных.
• Ресурс файлов содержания, используемый для хранения загруженного пользователем содержимого данных, например, PowerPoint файл. Загруженное содержимое шифруется при сохранении в ресурс файлов содержания.

Все серверы Web Conferencing Servers в пуле используют эти файловые ресурсы. Файловые ресурсы идентифицируются с помощью Universal Naming Convention (UNC) путей. Они могут располагаться на той же машине, что и Web Conferencing Server (как в случае с Office Communications Server2007 Standard Edition) или на разных (выделенных) файловых серверах (как в случае, рекомендуемом для Office Communications Server 2007 Enterprise Edition).

Файловые ресурсы имеют контролируемый доступ, поэтому ни один клиент не сможет получить прямой доступ к ним. Ресурсы метаданных предназначены исключительно для внутреннего пользования Web Conferencing Server. Web Conferencing Server должен обладать правом чтения и записи для этих ресурсов. А к ресурсам файлов содержания, напротив, доступ может получить любой клиент конференции не напрямую, а, используя IIS – виртуальная директория IIS создается и соединяется с ресурсом файлов содержания при установке веб компонента Office Communications Server, поэтому клиент имеет доступ к файлам в ресурсе файлов содержания через HTTP. Web Conferencing Server требует наличия права записи для ресурса файлов содержания, в то время как IIS требуется право только на чтение этого ресурса.

На рисунке 5-11 представлена схема управления Web Conferencing Server этими файловыми ресурсами.

Рисунок 5-11: Управление содержанием Web Conferencing Server

Когда сервер Web Conferencing Server начинает конференцию – т.е. получает команду addConference с компонента Focus – создается папка метаданных для конкретной конференции в каталоге, определенном UNC файлового ресурса метаданных. Ресурс метаданных строится следующим образом:

• Для каждого организатора; Web Conferencing Server создает отдельную папку в корне каталога метаданных. Имя папки организатора представляет собой рассчитанное значение хэш-функции из SIP URI организатора.
• Для каждой конференции; Web Conferencing Server создает отдельную папку в подпапке организатора. Имя папки конференции такое же, как и ее ID.
• Файлы метаданных хранятся в папке конференции. Все файлы, за исключением conference.xml файла, в папке конференции зашифрованы. Файл conference.xml содержит случайно сгенерированный ключ шифра для конференции. Этот ключ используется для шифровки всех прочих файлов метаданных конференции. Поскольку незащищенная информация, например ключ шифра, хранится в этой папке, администратор должен назначать разрешения чтения и записи для этой папки только той группе пользователей, которая использует этот Web Conferencing Server.

На рисунке 5-12 показана структура папки метаданных.

Рисунок 5-12: Структура папки метаданных

Файловый ресурс содержания строится так же, как и ресурс метаданных. На рисунке 5-13 показана структура папки содержания.

Рисунок 5-13: Структура папки содержания

Эта – Slide Files – папка содержит все загруженные пользователем слайды, переданные через HTTPS. Все файлы зашифрованы с помощью Advanced Encryption Standard (AES) и случайно сгенерированного ключа (по одному для каждого файла содержания). Ключ хранится в соответствующем файле метаданных в соответствующей папке метаданных. Имена файлов генерируются случайно, чтобы скрыть настоящее имя файлов. Сгенерированное имя файла, как и его оригинальное имя, хранится в соответствующем файле метаданных. В папке «ft» хранятся все раздаточные материалы – файлы, которые переданы в своей начальной форме, без преобразования в зашифрованном виде.

Понимание загрузки (Download) и выгрузки (Upload) содержимого Web Conferencing Server

Существует два типа данных в веб конференции: загружаемые пользователем (user uploaded) и генерируемые пользователем (user generated). Загружаемое пользователем содержание относится к содержимому, имеющему происхождение (либо файл, либо картинка) на стороне клиента, которое выгружено на Web Conferencing Server с помощью PSOM протокола. Загружаемое пользователем содержимое включает файлы презентаций PowerPoint, документы MODI, раздаточные материалы и слайды снимков. Генерируемое пользователем содержимое относится к содержимому, которое исходит не от оригинального файла, а создается в конференции. Сюда входят аннотации, содержимое опросов, содержимое вопросно-ответных данных, общие заметки, текстовые слайды, веб слайды и т.д.

Процесс выгрузки одинаков для обоих типов содержимого. Однако процесс загрузки отличается. Загружаемое содержимое расположено на IIS; сервер Web Conferencing Server оправляет URL содержимого и ключ шифра клиентам, чтобы они смогли загрузить и расшифровать это содержимое. Генерируемое содержимое загружается через PSOM.

На рисунке 5-14 показан принцип выгрузки и загрузки генерируемого содержимого.

Рисунок 5-14: Выгрузка и загрузка генерируемого содержимого

На рисунке 5-14 показана следующая последовательность процессов:

1. Пользователь создает слайд и его содержимое через PSOM.
2. Сервер Web Conferencing Server проверяет разрешение пользователя (то есть, разрешено ли пользователю создавать такой типа содержимого).
3. Web Conferencing Server создает состояние для нового слайда и сохраняет его в файловой системе (в папке метаданных конференции) в зашифрованном формате.
4. Web Conferencing Server направляет всем клиентам конференции новое состояние слайда.

Для всех типов генерируемого содержимого, за исключением слайдов опроса, содержимое отправляется с первым PSOM сообщением, которое создает слайд. Для слайдов опроса (Poll slides), содержимое (вопросы и варианты ответов) отправляется в новом PSOM сообщении, после того как первичное сообщение о создании слайда (Create Slide) было отправлено. Генерируемое содержимое сохраняется в папке метаданных только в виде зашифрованных XML файлов. Оно не сохраняется в папке содержания конференции. Вот пример XML метаданных для слайда опроса (перед шифрованием):

<?xml version=»1.0″ encoding=»UTF-8″?> <POLL> <POLLENTITY ID=»0AA61051-12BC-A1FF-A98F-A240BCB8ABDB» TIMESTAMP=»5/21/2007 11:39 AM»> <POLLUSER VALUE=»sip:ben@contoso.com»/> <POLLCHOICE VALUE=»MON»/> <POLLCHOICE VALUE=»TUE»/> <POLLCHOICE VALUE=»WED»/> <POLLCHOICE VALUE=»THU»/> <POLLCHOICE VALUE=»FRI»/> <POLLCHOICE VALUE=»SAT»/> <POLLCHOICE VALUE=»SUN»/> </POLLENTITY> </POLL>

На рисунке 5-15 показан принцип загрузки и выгрузки загружаемого содержимого.

Рисунок 5-15: Выгрузка и загрузка загружаемого содержимого

Этот процесс проходит в такой последовательности:

1. Пользователь начинает загрузку существующего содержимого. Сообщение PSOM отправляется от пользовательского клиента на Web Conferencing Server.
2. Web Conferencing Server проверяет разрешения для пользователя (то есть, разрешено ли пользователю создавать такой тип содержимого).
3. Клиент пользователя готовит содержимое для выгрузки. Тип подготовки зависит от типа загружаемого содержимого: — Для файлов презентации PowerPoint, клиент преобразовывает каждый слайд в файл .PNG рисунка, затем упаковывает и сжимает оригинальный .PPT(x) файл и все .PNG файлы в один .LMP файл. — Для файлов Microsoft Office, клиент преобразовывает их в MODI файлы, затем преобразовывает каждую страницу MODI файлов в файл .PNG рисунка. Затем клиент упаковывает и сжимает MODI .MDI файл и все .PNG файлы в один .LMP файл. — Для раздаточных материалов (handouts), клиент просто сжимает и упаковывает их в один .LMP файл.
4. Клиент начинает отправку .LMP файла через поток на Web Conferencing Server.
5. Web Conferencing Server распаковывает .LMP файл. Для каждого распакованного файла Web Conferencing Server генерирует ключ шифра и использует его для зашифровки файлов. Зашифрованные файлы сохраняются в папке содержания конференции. Ключ шифра и информация метаданных, например пользовательский SIP URI, сохраняются в виде зашифрованного XML файла в метаданных в папке метаданных конференции.
6. Web Conferencing Server рассчитывает URL, с которых можно будет получить доступ к зашифрованному содержимому через HTTPS. Это возможно благодаря тому, что веб компонент создает виртуальную директорию, ссылающуюся на тот же ресурс данных содержания, которому пишет Web Conferencing Server.
7. Web Conferencing Server отправляет URL и ключ шифра для файлов содержимого обратно клиентам через PSOM.
8. Каждый клиент, участвующий в конференции, использует URL для загрузки зашифрованного содержимого с IIS.
9. Используя ключ шифра, каждый клиент расшифровывает содержимое и отображает его.

Понимание совместимости собраний (Meeting Compliance)

Совместимость с регулирующими требованиями стала мотивацией для добавления возможностей архивирования IM в Live Communications Server. Те же самые требования применимы и к определенным аспектам Office Communications Server конференций. В Office Communications Server есть два параметра, которые в совокупности обеспечивают совместимость для местных конференций.

Во-первых, параметр CDR записывает информация участия в собрании, включая следующее:

• Время начала и окончания собрания Live Server
• Список участников, посетивших собрание

Во-вторых, параметр совместимости собрания (Meeting Compliance), запущенный на Web Conferencing Server, если активен, записывает действия, производимые с содержанием, включая:

• Запись любой загрузки содержимого, включая, кто и когда загрузил содержимое конференции
• Оригинальное загруженное содержимое, независимо от того, было ли оно впоследствии удалено и было ли оно перед аннотацией
• Все аннотации к любому содержимому, или любое содержимое виртуальной аудиторной доски
• Запись всех вопросов и ответов
• Запись всех опросов
• Запись всех чатов
• Запись передачи всех первичных загружаемых файлов

Записи всех действий хранятся в XML файлах, а загружаемое содержимое хранится в оригинальном формате. Эти XML журналы совместимости и файлы содержания хранятся в настраиваемом файловом ресурсе, определяемом UNC путем. В отличие от файловых ресурсов содержания и метаданных, файловый ресурс совместимости хранит журналы совместимости и содержания в незашифрованном виде. Администраторам следует быть внимательными при разрешении доступа к этим ресурсам. Web Conferencing Server требуются разрешения записи, и только авторизированные пользователи должны иметь разрешения записи и чтения.

На рисунке 5-16 показана структура папки ресурса совместимости собраний. Структура папки этого ресурса сходна со структурой папок файловых ресурсов содержания и метаданных. В каждой папке ID конференции папка содержимого хранит все действия загруженного содержимого, а оригинальные загруженные файлы отправляются в директорию загруженного содержимого. Папка чатов, опросов, вопросов и ответов хранит XML журналы для чатов, опросов, Q&A, соответственно.

Рисунок 5-16: Структура папки файлового ресурса

Вот пример XML журнала для опроса, который проводился на собрании:

<?xml version=»1.0″ encoding=»UTF-8″?> <POLLLOG> <POLLENTITY ID=»0AA61051-12BC-A1FF-A98F-A240BCB8ABDB» TIMESTAMP=»5/21/2007 11:39 AM»> <POLLUSER VALUE=»sip:ben@contoso.com [Ben]» /> <POLLQUESTION VALUE=»What day is today?» /> <POLLCHOICE VALUE=»MON» /> <POLLCHOICE VALUE=»TUE» /> <POLLCHOICE VALUE=»WED» /> <POLLCHOICE VALUE=»THU» /> <POLLCHOICE VALUE=»FRI» /> <POLLCHOICE VALUE=»SAT» /> <POLLCHOICE VALUE=»SUN» /> </POLLENTITY> <POLLENTITY ID=»0AA61051-12BC-A1FF-A98F-A240BCB8ABDB» TIMESTAMP=»5/21/2007 11:39 AM»> <POLLUSER VALUE=»sip:ben@contoso.com [Ben]» /> <POLLSEQ VALUE=»1″ /> <POLLCHOICE VALUE=»1″ /> </POLLENTITY> <POLLENTITY ID=»0AA61051-12BC-A1FF-A98F-A240BCB8ABDB» TIMESTAMP=»5/21/2007 11:39 AM»> <POLLUSER VALUE=»sip:john@contoso.com [John]» /> <POLLSEQ VALUE=»2″ /> <POLLCHOICE VALUE=»0″ /> </POLLENTITY> <POLLENTITY ID=»0AA61051-12BC-A1FF-A98F-A240BCB8ABDB» TIMESTAMP=»5/21/2007 11:39 AM»> <POLLUSER VALUE=»sip:ben@contoso.com [Ben]» /> <POLLSEQ VALUE=»3″ /> <POLLCHOICE VALUE=»0″ /> </POLLENTITY> <POLLENTITY ID=»0AA61051-12BC-A1FF-A98F-A240BCB8ABDB» TIMESTAMP=»5/21/2007 11:39 AM»> <POLLUSER VALUE=»sip:john@contoso.com [John]» /> <POLLSEQ VALUE=»4″ /> <POLLCHOICE VALUE=»-1″ /> </POLLENTITY> <POLLENTITY ID=»0AA61051-12BC-A1FF-A98F-A240BCB8ABDB» TIMESTAMP=»5/21/2007 11:39 AM»> <POLLUSER VALUE=»sip:john@contoso.com [John]» /> <POLLSEQ VALUE=»5″ /> <POLLCHOICE VALUE=»0″ /> </POLLENTITY>

Администратор может активировать и дезактивировать параметр совместимости собраний на каждом пуле Office Communications Server. Администратор также может настроить регистрацию совместимости на работу в критическом — critical режиме. В этом режиме запуск новых конференций блокируется. Существующие конференции немедленно блокируются, если в какой-то момент Web Conferencing Server потребуется доступ к файловому ресурсу совместимости по каким-либо причинам.

Понимание инструментов содержания веб конференций (Web Conferencing Content Tools)

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

В пакете Resource Kit для Office Communications Server 2007 есть три инструмента, помогающие администраторам управлять содержимым файловых ресурсов. Пожалуйста, посмотрите информацию по установке и использованию этих инструментов в документации о Resource Kit.

DMInsider.exe

В целях безопасности Web Conferencing Server сохраняет содержимое конференции в зашифрованном формате в директории файлов содержания. Поэтому, даже если пользователь имеет доступ к этой директории, администратор не сможет просмотреть действительное содержимое. Программа DMInsider.exe помогает администраторам Microsoft Office Communications Server 2007 найти и просмотреть содержимое конференции, управляемое Web Conferencing Server. Этот инструмент обладает следующими функциями:

• Возможность создавать списки и просматривать содержимое по организаторам и конференциям. Содержимое отображается так же, как и в консоли Microsoft Office Live Meeting Console.
• Возможность просматривать XML журналы совместимости. Инструмент может отображать содержимое совместимости так же, как оно отображается в консоли Microsoft Office Live Meeting Console.
• Возможность просматривать статистику директории файлов содержания. Статистические данные включают количество организаторов, количество конференций, размещенных в конкретной директории файлов и т.д.

DMHash.exe

Web Conferencing Server хранит содержимое конференций по организаторам. Содержимое всех конференций, организованных одним пользователем, хранится в одной директории. Имя директории представляет собой строку случайных символов (hash string), которая генерируется на основе SIP URI организатора. В результате этого, администраторам трудно найти папки содержимого конференций конкретного организатора.

Dmhash.exe помогает администраторам Microsoft Office Communications Server 2007 генерировать хэш-значение для пользовательского URI. Значение хэш-функции используется для создания папок содержимого для каждого организатора. Администраторам полезно перемещать содержимое конференции пользователя, когда его SIP URI изменяется.

DMDel.exe

Инструмент Dmdel.exe помогает администраторам Microsoft Office Communications Server 2007 найти содержимое конференции, которое устарело, и удалить его.

Web Conferencing Server, по умолчанию, удаляет содержимое конференций, которые не активировались примерно в течение 28 дней. Этот инструмент позволяет администраторам вручную удалять содержимое неактивных конференций по собственному графику.

Понимание политики собраний (Meeting Policy) и внедрения политики (Policy Enforcement)

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

По умолчанию, Office Communications Server 2007 имеет пять определений в политике собраний. Все политики собраний включают одинаковые параметры, но некоторые или все параметры можно настроить по-разному для каждой политики собрания. Администраторы могут задавать политику собраний в глобальном масштабе, то есть одна политика собраний для всех пользователей, расположенных на всех пулах одной и той же области Active Directory. Либо администраторы могут задавать параметры политики для каждого пользователя отдельно. В этом случае администраторы выбирают политику собраний для каждого пользователя, как части опции пользователя. В таблице 5-2 показаны настройки, которые можно изменять для каждой отдельной политики, чтобы управлять параметрами.

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

• Давать разрешение на глобальном уровне для приглашения анонимных участников, в этом случае все пользователи в области Active Directory могут приглашать анонимных участников на собрания.
• Запретить всем пользователям на глобальном уровне, в этом случае ни один пользователь в области не сможет приглашать анонимных участников на собрания.
• Использовать политику для отдельных пользователей, в этом случае только отдельные учетные записи пользователей могут быть настроены на разрешение приглашения анонимных участников на собрания.

Заключение

Эта глава раскрывает основные понятия и сценарии Microsoft Office Communications Server местных конференций. В ней также описана архитектура, поддерживающая эти сценарии конференций. Технические подробности веб конференций описывают жизненный цикл типичной конференции и разъясняют процесс присоединения клиентов, а также процесс управления содержимым Web Conferencing Server. Такое техническое понимание очень важно для администраторов, которым нужно применять, настраивать и диагностировать местные конференции в Office Communications Server.

www.windowsnetworking.com

• Wds служба развертывания
• K exchange servers как удалить
• Nat Windows 2003
• Ограничение времени выполнения хранимой процедуры oracle
• Уникальные шрифты

Tags: dns, domain, nat, proxy