IP-адрес представляет собой 32-битовое (по версии IPv4) или 128битовое (по версии IPv6) двоичное число. Удобной формой записи IP-адреса (IPv4) является запись в виде четырёх десятичных чисел (от 0 до 255), разделённых точками, например, 192.168.0.1. (или 128.10.2.30 — традиционная десятичная форма представления адреса, а 00000010 00011110 — двоичная форма представления этого же адреса).

IP-адреса представляют собой основной тип адресов, на основании которых сетевой уровень протокола IP передаёт пакеты между сетями. IPадрес назначается администратором во время конфигурирования компьютеров и маршрутизаторов.

IP-адрес состоит из двух частей: номера сети и номера узла. В случае изолированной сети её адрес может быть выбран администратором из специально зарезервированных для таких сетей блоков адресов (192.168.0.0/16, 172.16.0.0/12 или 10.0.0.0/8). Если же сеть должна работать как составная часть Интернета, то адрес сети выдаётся провайдером, либо региональным интернет регистратором (Regional Internet Registry, RIR).

Существует пять RIR: ARIN, обслуживающий Северную Америку; APNIC, обслуживающий страны Юго-Восточной Азии; AfriNIC, обслуживающий страны Африки; LACNIC, обслуживающий страны Южной Америки и бассейна Карибского моря; и RIPE NCC, обслуживающий Европу, Центральную Азию, Ближний Восток. Региональные регистраторы получают номера автономных систем и большие блоки адресов у IANA, а затем выдают номера автономных систем и блоки адресов меньшего размера локальным интернет регистраторам (Local Internet Registries, LIR), обычно являющимся крупными провайдерами.

Номер узла в протоколе IP назначается независимо от локального адреса узла. Маршрутизатор по определению входит сразу в несколько сетей.

Поэтому каждый порт маршрутизатора имеет собственный IP-адрес.

Конечный узел также может входить в несколько IP-сетей. В этом случае компьютер должен иметь несколько IP-адресов, по числу сетевых связей.

Таким образом, IP-адрес характеризует не отдельный компьютер или маршрутизатор, а одно сетевое соединение.

Так как для обработки сообщений необходимо было, чтобы пакеты доходили до контроллеров целиком и в нужном порядке, на транспортном уровне был выбран протокол TCP.

TCP (Transmission Control Protocol — протокол управления передачей) — один из основных сетевых протоколов Internet, предназначенный для управления передачей данных в сетях и подсетях TCP/IP.

TCP — это транспортный механизм, предоставляющий поток данных, с предварительной установкой соединения, за счёт этого дающий уверенность в достоверности получаемых данных, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета. В отличие от UDP, гарантирует, что приложение получит данные точно в такой же последовательности, в какой они были отправлены, и без потерь. Реализация протокола TCP, как правило, встроена в ядро системы, хотя есть и реализации TCP в контексте приложения.

TCP часто обозначают «TCP/IP». Когда осуществляется передача от компьютера к компьютеру через Internet, TCP работает на верхнем уровне между двумя конечными системами, например, интернет-браузер и интернетсервер. Также TCP осуществляет надежную передачу потока байт от одной программы на некотором компьютере в другую программу на другом компьютере. Программы для электронной почты и обмена файлами используют TCP. TCP контролирует длину сообщения, скорость обмена сообщениям, сетевой трафик.

Формат TCP-сегмента Бит Номер последовательности Номер подтверждения Опции (необязательно) 160/192+ Данные •Порт источника идентифицирует порт, с которого отправлены пакеты.

•Порт назначения идентифицирует порт, на который отправлен пакет.

• Номер последовательности выполняет две задачи:

1) если установлен флаг SYN, то это начальное значение номера последовательности и первый байт данных — это номер 2) в противном случае, если SYN не установлен, первый байт данных — номер последовательности Поскольку TCP-поток в общем случае может быть длиннее чем, число различных состояний этого поля, то все операции с номером последовательности должны выполняться по модулю 2^32. Это накладывается практическое ограничение на использование TCP. Если скорость передачи коммуникационной системы такова, чтобы в течении MSL (максимального времени жизни сегмента) произошло переполнение номера последовательности, то в сети может появиться два сегмента с одинаковым номером, относящихся к разным частям потока, и приемник получит некорректные данные.

• Если установлен флаг ACK, то это поле содержит номер последовательности, ожидаемый получателем в следующий раз.

Помечает этот сегмент как подтверждение получения.

• Это поле определяет размер заголовка пакета TCP в 32-битных словах.

Минимальный размер составляет 5 слов, а максимальный — 15, что составляет 20 и 60 байт соответственно. Смещение считается от начала заголовка TCP.

• Зарезервировано (6 бит) для будущего использования и должны устанавливаться в ноль. Из них два (8-й и 9-й) уже определены:

• CWR (Congestion Window Reduced) — Поле «Окно перегрузки уменьшено» — флаг установлен отправителем, чтоб указать, что получен пакет с установленным флагом ECE • Флаги (управляющие биты). Это поле содержит 6 битовых флагов:

o URG — Поле «Указатель важности» значимо (англ. Urgent pointer field is significant) o ACK — Поле «Номер подтверждения» значимо (англ.

Acknowledgement field is significant) o PSH — (англ. Push function) инструктирует получателя протолкнуть данные, накопившиеся в приемном буфере, в приложение пользователя o RST — Оборвать соединения, сбросить буфер (очистка буфера) (англ. Reset the connection) o SYN — Синхронизация номеров последовательности (англ.

Synchronize sequence numbers) o FIN (англ. final, бит) — флаг, будучи установлен, указывает на завершение соединения (англ. FIN bit used for connection • Поле контрольной суммы — это 16-битное дополнение суммы всех 16битных слов заголовка и текста. Если сегмент содержит нечетное число октетов в заголовке /или тексте, последние октеты дополняются справа 8 нулями для выравнивания по 16-битовой границе. Биты заполнения (0) не передаются в сегменте и служат только для расчета контрольной суммы. При расчете контрольной суммы значение самого поля контрольной суммы принимается равным нулю.

• Указатель важности — 16-битовое значение положительного смещения от порядкового номера в данном сегменте. Это поле указывает порядковый номер октета, которым заканчиваются важные (urgent) данные. Поле принимается во внимание только для пакетов с установленным флагом URG.

Все присылаемые сообщения от сервера MGC состоят из данных в виде XML и HTTP заголовка. Поэтому логично сказать, что на представительном уровне используем язык разметки XML, а на прикладном уровне — протокол HTTP.

XML (англ. eXtensible Markup Language — расширяемый язык разметки) — рекомендованный Консорциумом Всемирной паутины язык разметки, фактически представляющий собой свод общих синтаксических правил. XML — текстовый формат, предназначенный для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки (например, XHTML), иногда называемых словарями.

Целью создания XML было обеспечение совместимости при передаче структурированных данных между разными системами обработки информации, особенно при передаче таких данных через Интернет. Словари, основанные на XML (например, RDF, RSS, MathML, XHTML, SVG), сами по себе формально описаны, что позволяет программно изменять и проверять документы на основе этих словарей, не зная их семантики, то есть не зная смыслового значения элементов. Важной особенностью XML также является применение так называемых пространств имён (англ. namespace).

XML — это иерархическая структура, предназначенная для хранения любых данных, визуально структура может быть представлена как дерево.

Важнейшее обязательное синтаксическое требование — то, что документ имеет только один корневой элемент (англ. root element) (альтернативно называемый элементом документа (англ. document element)). Это означает, что текст или другие данные всего документа должны быть расположены между единственным начальным корневым тегом и соответствующим ему конечным тегом. Остальная часть XML-документа состоит из вложенных элементов, некоторые из которых имеют атрибуты и содержимое. Элемент обычно состоит из открывающего и закрывающего тегов, обрамляющих текст и другие элементы. Открывающий тег состоит из имени элемента в угловых скобках, например, «»; закрывающий тег состоит из того же имени в угловых скобках, но перед именем ещё добавляется косая черта, например, «». Содержимым элемента (англ. content), называется всё, что расположено между открывающим и закрывающим тегами, включая текст и другие (вложенные) элементы.

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

Значения атрибутов всегда заключаются в кавычки (одинарные или двойные), одно и то же имя атрибута не может встречаться дважды в одном элементе. Не рекомендуется использовать разные типы кавычек для значений атрибутов одного тега.

HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных в первую очередь в виде текстовых сообщений. Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.

HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP.

Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

HTTP — протокол прикладного уровня, аналогичными ему являются FTP и SMTP. Обмен сообщениями идёт по обыкновенной схеме «запросответ». Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния.

Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IPадреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.

Цель работы — разработать программно-аппаратный комплекс, имеющий возможность управления сервером видеоконференцсвязи Polycom MGC.

Задачи в работе:

• Изучить протокол взаимодействия с сервером видеоконференцсвязи Polycom MGC.

• Наладить взаимодействие между сервером Polycom MGC и контроллером AMX NI-2100.

• Реализовать логику обработки сообщений от сервера Polycom MGC • Разработать протокол между котроллером AMX NI-2100 и контроллером Crestron PRO2.

• Разработать интерфейс для сенсорной панели Crestron TPMC-8x и логику ее взаимодействия с контроллером Crestron PRO2.

В этом разделе будет описана аппаратная часть разрабатываемого комплекса: будут представлены технические описания устройств и некоторые сравнительные показатели.

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

В многоточечных конференциях одновременно принимают участие сразу несколько точек оконечного оборудования аудио/видеосвязи.

Многоточечная связь устанавливается каждым терминалом, подключенным к многоточечному блоку управления (MCU).

Блок MGC может соединяться с такими терминалами по линиям ISDN, IP, ATM и/или с использованием последовательного соединения, что дает возможность проводить конференции между участниками из разных сетей без помощи внешних шлюзов и прочего оборудования. Пример соединения представлен на рисунке 1-1.

использованием блока MGC Шлюз Universal Transcoding блока MGC автоматически определяет параметры сжатия звука, разрешения изображения, частоты обновления и ширины полосы, а также скорость передачи данных по стандарту Т.120, для каждой точки оконечного оборудования и динамически выполняет все необходимые преобразования. Такая возможность не только ускоряет и упрощает процесс настройки для многоточечных вызовов, но и обеспечивает оптимизацию использования ресурсов каждой точки конечного оборудования.

Поддержка блоком MGC динамического режима Continuous Presence обеспечивает гибкость просмотра и взаимодействия между участниками конференции. В данном режиме доступны сразу несколько различных схем расположения окон просмотра: два симметричных узла (рядом друг с другом или одно над другим), четыре симметричных узла (Quad), комбинации изображений 2+1, 3+1, 4+1, 5+1, 7+1 и 8+1 (несколько маленьких квадратных изображений рядом с одним большим), а также девять симметричных изображений.

Таким образом, всего в режиме Classic доступна 21 схема расположения окон просмотра. В режимах Quad поддерживается новый режим визуализации Continuous Presence (CP), где доступны три новых схемы расположения окон для 10 участников и более (раскладки 2+8, 1+12, 4 на 4).

Некоторые из названных схем расположения изображений показаны на рис.

1-2.

Рис. 1-2. Примеры расположения видеоокон при различных раскладках Самые важные для нас параметры сервера MGC — это возможности управления самим сервером. Для управления блоком MGC используется MGC Manager, приложение для платформ Windows 95®, 98®, ME®, NT®, 2000®, установленное на компьютере или сервере (приобретается пользователем самостоятельно). Данная рабочая станция оператора может подключаться к блоку MGC с использованием соединений следующих типов:

• LAN Ethernet;

• TCP/IP (Интернет);

• RS-232;

• модемное соединение по коммутируемой линии.

К блоку MGC могут быть одновременно подключены до 16 локальных или удаленных рабочих станций MGC Manager, а один оператор может осуществлять управление несколькими блоками MGC и/или конференциями.

Кроме того, управление блоком MGC может осуществляться из веб-браузера через сайт MGC WebCommander.

Рассмотрим основные функции, реализованные в приложении MGC Manager.

1) Резервирование конференций В MGC Manager поддерживаются следующие возможности резервирования конференций:

резервирование ресурсов во время настройки параметров удобный доступ к утилите Call Detail Record;

просмотр списка всех конференций (как активных, так и зарезервированных) по нескольким MCU;

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

2) Определение типов конференций В MGC Manager доступны для определения конференции следующих типов:

Dial-In (входящий вызов);

Dial-In с автоматическим определением пропускной способности канала связи для неустановленных участников;

Meet Me per Conference;

Dial-Out (с ручным или автоматическим/одновременным исходящим Dial-Out с автоматическим определением пропускной способности канала связи для неустановленных участников;

зарезервирована на определенное время в будущем;

зарезервирована для периодического проведения;

On-Demand (с немедленным инициированием по требованию);

Greet & Guide с ручным или автоматическим подключением к конференциям;

H.243 Cascading (каскадные);

с использованием программного модуля Interactive Voice Response (IVR) для доступа к конференции.

3) Управление конференциями MGC Manager предоставляет в распоряжение оператора следующие возможности по управлению конференциями:

активное отображение всех конференций и участников по нескольким MCU;

мониторинг статуса соединения и параметров каждого участника в режиме реального времени;

средства визуальной индикации статуса конференций и участников;

вывод отдельных ведомостей свойств по каждому участнику и конференции;

активное отображение сведений по всем системным ресурсам;

автоматическое завершение конференций;

автоматическое продление конференции;

контроль громкости звучания голоса каждого участника;

LSD — FECC (управление камерой на дальнем конце);

функция Chair Control по стандарту H.243;

возможность использования для управления участниками команд вырезания, копирования и вставки, а также применения метода перемещения с помощью мыши;

расширенные функции приветствия для конференций Greet & Guide расширенные возможности выполнения действий, требующих участия оператора;

управление конференциями с помощью кодов DTMF с оконечного оборудования/телефона конечного пользователя.

Как Вы могли убедиться, данное программное обеспечение обеспечивает управлением всеми функциями, предусмотренными в MGC.

Для завершения описания этого ПО кратко расскажем об интерфейсе и принципе использования приложения MGC Manager.

1) Главное окно После запуска MGC Manager, на экране отобразится главное окно приложения, представленное на рисунке 1-3.

Рис. 1-3. Горизонтальный вид экрана Главное окно разделено на шесть разделов, представленных в таблице 1-1.

Панель Главного Отображает заголовки имеющихся Панель Содержит стандартные кнопки быстрого инструментов выбора команд Windows.

Область обзора Отображает список MCU, с которыми Область Отображает информацию о текущем Область Отображает информацию о различных Индикатор Отображает информацию о различных использования компонентах Таблица 1-1. Области главного окна MGC Manager При использовании шаблона панель обзора «Template/Database»

(«Шаблон/База данных») может быть размещена рядом с главным окном. Это позволит вам вести работу с двумя окнами, одновременно держа их оба в поле зрения. Панель обзора «Template/Database» отображает доступные на данный момент шаблоны конференций или участников, в соответствие с выбранной опцией.

2) Просмотр списков конференций Каждый MCU содержит три прикрепленных к нему списка конференций. Все конференции, которые работают в текущий момент, описаны в списке активных конференций On Going Conferences. Все резервирования конференции, определенные в MCU, хранятся в списке активируются в момент подключения первого участника к конференции, приведены в списке Meeting Rooms.

Приведенные ниже процедуры предполагают, что приложение уже подключено к MCU, списки конференций которого вы хотите отобразить.

Для просмотра списка активных конференций On Going Conferences блока MCU:

а. В области Browser главного окна щелкните на значке плюса [+], который расположен рядом со значком MCU, при этом отобразятся опции, представленные на рисунке 1-4.

Рис. 1-4. Поле Browser б. В дереве MCU дважды щелкните на значке On Going Conferences, или щелкните на значке [+], рядом со значком On Going Conferences.

Список конференций, проходящих в данный момент, появится внизу значка On Going Conferences. Каждая конференция определяется значком и именем. Рисунок 1-5.

Рис. 1-5. Дерево MCU При первом вводе, или в случае отсутствия активных конференций, список On Going Conferences пуст.

Для того чтобы отобразить список MCU зарезервированных конференций:

1. В области Browser главного окна дважды щелкните на значок MCU или щелкните на значок [+], рядом со значком MCU.

2. Дважды щелкните на значке Reservations, или щелкните на значке [+], рядом со значком Reservations. Список зарезервированных конференций появляется ниже значка Reservations.

Каждое резервирование идентифицируется значком и именем так, как показано на рисунке 1-6.

Рис. 1-6: Зарезервированные конференции 3) Настройка активных конференций Активной конференцией принято считать конференцию, которая или уже запущена, или будет запущена при достижении даты и времени резервирования в расписании. Активная конференция может быть активизирована тремя различными способами:

• Активация через определение новой конференции: On Going conferences — New Conference («Активная конференция — новая • Текущая активация через Reservation Template («Шаблон резервирования») • Текущая активация через Reservation Template in Database («Шаблон резервирования в базе данных») Доступны две категории активных конференций: звуковые конференции и видеоконференции.

Звуковой конференцией принято считать конференцию, в которой участники подключаются к совещанию при помощи телефонных операторов или технологии VoIP (Voice over IP — передача голоса в IP-пакетах). MCU может генерировать вызов, приглашающий участников присоединиться к конференции.

Команда кнопочного набора (DTMF), средства управления MGC Manager, использующиеся для управления конференцией и участниками.

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

При настройке звуковой конференции отображаются только те функции и значки, которые относятся к звуковой конференции. Функции и процедуры, относящиеся только к видеоконференциям, такие как ATM, сетевое соединение или видео опции, удалены или отключены.

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

Могут быть выбраны различные видео форматы для конференции, и организатор встречи может настроить конференцию в виде лекции.

Система поддерживает как планируемые/осуществляемые при помощи оператора конференции, так и автоматические встречи по требованию.

Планируемые конференции.

Планируемые конференции организовываются заранее. Для этого осуществляется определение конференции (если это необходимо), назначение конференции к MCU, настройка даты и времени начала конференции, а также продолжительности конференции. В аудио и видеоконференциях, использующих возможности VoicePlus, имеются функции организатора встреч для заданного номера телефона и пароль для участников встречи, использующих коммутируемые каналы связи. Планирование может быть осуществлено при помощи приложения MGC Manager.

Конференции по требованию.

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

Конференции без резервирования.

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

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

Эти конференции называют «Meeting rooms» конференциями.

Как уже было сказано ранее, нам предстояло модернизировать систему интегрированного управления. Эта система была построена на оборудовании компании «Crestron Electronics Inc.».

Системы управления, построенные на базе оборудования Crestron, состоят из устройств, которые можно поделить на три группы:

• контроллеры управления;

• сенсорные и кнопочные панели;

• периферийное оборудование.

Контроллер управления — это центральная часть всей системы, т.к. он объединяет в себе все интерфейсы. Контроллер PRO2 входящий в исходную систему, представлен на рисунке 1-7, опишем его характеристики.

Контроллер Crestron PRO2 имеет:

6 СОМ-портов, поддерживающих протоколы RS-232 и RS-485;

8 выходов для подключения излучателей инфракрасного 8 аналоговых выходов (выдают напряжение от 0 до 10В);

Шину Cresnet для подключения периферийного оборудования, кнопочных и некоторых сенсорных панелей;

СОМ-порт для настройки контроллера и перемещения в его Рис. 1-7. Контроллер управления Crestron PRO Пользователь системы взаимодействует с сенсорной панелью, на которой отображается графический интерфейс. Для каждой системы разрабатывается индивидуальный интерфейс, который помещается в постоянную память сенсорной панели.

В свою очередь панель, взаимодействуя с контроллером через подключения Cresnet, Ethernet или Wi-Fi, передает ему информацию о происходящих событиях (например нажатие кнопки). Контроллер обрабатывает эту информацию в соответствии с программой, которая находится у него в памяти.

В исходной системе использовалась панель Crestron TPMC-8x, представленная на рисунке 1-8. Это беспроводная (Wi-Fi) сенсорная панель 8,4 дюйма с разрешением 800*600 пикселей.

Рис. 1-8. Сенсорная панель Crestron TPMC-8x Периферийное оборудование обеспечивает дополнительные опции управления. Список этого оборудования очень широкий: это и силовые реле, и различные измерительные приборы, и даже преобразователи в другие интерфейсы.

Схема оборудования до модернизации представлена на рис. 1-9.

COM F IN

Скорость по результатам измерений оказалась очень низкой. Для используемого контроллера Crestron PRO2 скорость была равна 20,2 Кбайт полезной информации в секунду. После аналогичного исследования с другими контроллерами были получены результаты, представленные на рисунке 1-10.

Рис. 1-10. Результат измерения скоростей отправки пакетов по байта контроллерами Crestron и АМХ Для более точного определения скорости мы должны были уточнить размеры пакетов данных, с которыми нам придется работать. В следующей главе будет подробно описаны пакеты, которые будут приходить в контроллер от сервера и те, которые будут отправляться обратно. Самый большой объем трафика будет получаться от сервера при описании списка абонентов, участвующих в конференции. Информация об одном абоненте состоит примерно из 6500 символов. Поэтому мы провели тесты на чтение из сокета и отправку в сокет с длиной пакета 7Кбайт. Результаты приведены на рисунках 1-11 и 1-12.

Рис. 1-11. Результат измерения скоростей отправки пакетов по Кбайт контроллерами Crestron и АМХ Рисунок 1-12: Результат измерения скоростей приема пакетов по Кбайт контроллерами Crestron и АМХ Таким образом, контроллер Crestron PRO2 может за одну секунду получить информацию примерно о 6 участниках конференции. А контроллер АМХ NI-2000 более чем о 80 участниках.

После того, как пользователь внесет какое-либо изменение в любую из конференций, сервер присылает информацию о всех конференциях. И блокировка системы для принятия информации от сервера более чем на 1. секунды недопустимо. Учитывая, что сервер в среднем обслуживает 50- участников, то становится ясно, что контроллеры Crestron не подойдут для этих целей.

Поэтому было принято решение о внедрении в систему дополнительного контроллера AMX NI-2100, скорость которого позволяет поддерживать до 120 участников. Схема оборудования после модернизации представлена на рис. 1-13.

Оборудование АМХ по своему назначению и принципу работы аналогично оборудованию Crestron.

Контроллер АМХ NI-2100 имеет следующие характеристики:

4 выхода для подключения излучателей инфракрасного диапазона;

4 аналоговых выхода (выдают напряжение от 0 до 10В);

Шину ICSNet для подключения периферийного оборудования, кнопочных и некоторых сенсорных панелей;

Шину AXLink для подключения периферийного оборудования, кнопочных и некоторых сенсорных панелей;

СОМ-порт для настройки контроллера и перемещения в его память программы.

Рис. 1-13. Схема оборудования после модернизации В этой работе нам придется разрабатывать программы для контроллера AMX NI-2100, для контроллера Crestron PRO2 и для сенсорной панели Crestron TPMC-8x. В этом разделе мы кратко познакомимся со средствами разработки этих программ.

Программа для контроллера AMX NI-2100 разрабатывается в текстовом редакторе AMX NetLinx Studio 2. Его интерфейс представлен на рис. 1-14.

Рис. 1-14. Текстовый редактор AMX NetLinx Studio Этот язык можно сравнить с языком С, хотя имеется очень много различий. Мы не будем описывать синтаксические особенности, скажем лишь то, что этот язык создан для обработки различных событий. Событием является нажатие на кнопку на сенсорной панели или получение данных из СОМ-порта и др.

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

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

Программа для контроллера Crestron PRO2 разрабатывается в модульном редакторе Crestron SIMPL Windows, интерфейс которого представлен на рисунке 1-15.

Рис. 1-15. Редактор Crestron SIMPL Windows Это приложение рассматривает все события как сигналы. Это могут быть цифровые сигналы (0 или 1), аналоговые сигналы (от 0 до 65537) и строковые сигналы (данные в шестнадцатеричном формате или формате ASCII). Для обработки сигналов используются различные модули и операторы. На рисунке 1-16 представлен простейший оператор «или».

Рис. 1-16. Оператор «или» в редакторе Crestron SIMPL Windows Модули создаются из простых операторов путем последовательной обработки сигналов. Также модули можно создавать в текстовом редакторе Crestron Simpl+.

Интерфейс для сенсорной панели Crestron TPMC-8x создается в графическом редакторе Crestron VisionTools Pro-e. Основные инструменты этого редактора — это создание кнопок, текстовых полей и объектов отображения аналоговых сигналов.

Приведем пример простейшей логики взаимодействия системы. После нажатия кнопки «Включить проектор» на сенсорной панели контроллер получает сигнал о том, что на панели с идентификатором 3 нажата кнопка с номером один. Контроллер обрабатывает этот сигнал, в результате чего отправляет во второй СОМ-порт команду «\x02PON\x03». Проектор, получив такую команду, включается.

Рис. 1-17. Графический редактор Crestron VisionTools Pro-e Глава 2. Разработка программного комплекса Структура протокола обмена данными сервера Polycom MGC После изучения литературы о сервере MGC стало понятно, что информацию он передает в текстовом формате XML. Но описание тегов и их сути не могло дать представления о реальном передающемся пакете данных.

Поэтому возникла идея просмотреть реально передающиеся пакеты данных от сервера MGC к приложению MGC Manager и обратно.

Такую возможность предоставляет приложение «Socket Workbench».

При TCP/IP соединении приложение MGC Manager является клиентом, а сервер MGC — сервером. Поэтому для просмотра передающихся между ними данных необходимо:

o создать серверное подключение для приложения MGC Manager;

o открыть клиентское подключение к серверу MGC;

o передавать сообщения между этими подключениями.

Все эти действия осуществляются в приложении «Socket Workbench», которое может предоставлять данные представительного уровня соединения в двоичном, шестнадцатеричном, ASCII и др. форматах.

Данные операции позволили просматривать все данные, которыми обменивались сервер MGC и приложение MGC Manager. Для примера приведем ответ сервера на запрос о списке конференций, который представлен в приложении 1. Из примера видно, что сообщение состоит их HTTP заголовка и тела сообщения, в формате XML.

Рассмотрим HTTP заголовок.

Content-Length: Content-Type: application/xml; charset=iso-8859- Pragma: MESSAGE_ID= Server: PolycomHTTPServer Connection: Keep-Alive Cache-control: private В нем представлены следующие поля:

• длина сообщения, идущего после заголовка;

• идентификатор сообщения;

Во всех сообщениях изменяются два поля — длина сообщения и идентификатор сообщения.

HTTP заголовок отделен от остального сообщения четырьмя подряд идущими символами в шестнадцатеричном виде: перенос строки, перенос каретки, перенос строки, перенос каретки. Будем называть эти символы разделяющими.

Разработка программы для контроллера NI- Наибольшей частью разработки всего программного комплекса была разработка программы для контроллера AMX NI-2100. В этом разделе мы опишем суть работы программы и методы, используемые при программировании.

У контроллеров АМХ существует внутренняя адресация устройств, в которой точный адрес устройства задается тремя параметрами:

• идентификатор контроллера;

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

mgc=0:first_local_port:0.

Наша программа будет являться клиентом, поэтому программа должна начинать сеанс связи, если таковой отсутствует. Поэтому в разделе, предназначенном для действий при загрузке системы, мы прописываем начало клиентского TCP/IP соединения. Для этого мы должны указать IPадрес сервера MGC, порт, на котором у него открыто серверное соединение, а также порт, который используется на контроллере — mgc.port.

В этом же разделе мы создаем буфер, в который будут помещаться сообщения перед их обработкой.

Как уже было указано, программы для контроллеров АМХ предназначены для обработки различных событий. У устройств события могут быть следующими:

1) online — есть соединение;

2) offline — нет соединения;

3) onerror — ошибка соединения;

4) string — получение данных.

В первом случае мы фиксируем, что с устройством появилось соединение и вызываем функцию f_login.

Во втором и третьем случаях мы фиксируем потерю соединения и начинаем с периодичностью в 0,5 сек. открывать клиентское TCP/IP соединение.

В четвертом случае мы должны обработать полученные данные.

Функция f_login создает сообщение для сервера, в котором содержится XML запрос на авторизацию. Для этого выполняются следующие операции.

1. Проверяются переменные имя пользователя, пароль и имя пользователя в системе. Если значения пустые, то присваиваем необходимые значения.

2. Формируется сообщение:

3. Вызывается функция send_pocket от сформированного сообщения.

Функция send_pocket создана для отправки пакетов данных в сервер MGC. Для этого необходимо окончательное формирование пакета. Попадая в эту функцию, программа проверяет, закончилась ли отправка предыдущего пакета. Формирование пакета начинается только в том случае, если отправка предыдущего закончена.

В ответе на запрос функции f_login, сервер MGC присылает два идентификатора mcu_token и mcu_user_token. Это числовые значения, характеризующие соединение. И в каждом последующем сообщении к серверу необходимо указывать эти значения, для того, чтобы сервер понимал, от какого пользователя идет запрос. Это необходимо для того, чтобы по-разному реагировать на запросы от разных пользователей.

Например, если пользователь совершил операцию login и ему не позволено управлять участниками, то все запросы, связанные с действиями над участниками, будут выдавать сообщение об ошибке, если в запросе mcu_user_token соответствует этому пользователю.

В функции send_pocket проверяется, чему равны значения этих идентификаторов (mcu_token и mcu_user_token). Их равенство нулю означает, что с последнего разрыва связи не был завершен процесс авторизации. В этом случае идентификатор сообщения должен стать равным нулю.

Далее в XML сообщение вставляются значения mcu_token, mcu_user_token и идентификатор сообщения. Высчитывается его длина и, исходя из этого, добавляется HTTP заголовок. После того, как пакет готов к отправке, идентификатор сообщения увеличивается на единицу, и этот пакет отсылается в устройство mgc.

После получения корректного запроса сервер высылает ответ.

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

Если же пришли данные и контроллер не обрабатывает предыдущие данные, то начинается обработка пришедших данных. Мы ищем в этих данных HTTP заголовок. Если заголовок не найден, то об этом выводится сообщение и заканчивается обработка данных. Иначе, вырезаем из буфера первый найденный HTTP заголовок и разделяющие символы. После чего извлекаем значение будущей длины сообщения.

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

2. Если же в буфере осталось символов меньше, чем указано в заголовке, то программа ждет следующего события. Если следующим событием будет прерывание связи, то программа уже не будет ждать завершения сообщения. Программа дождется завершения обработки сообщения и очистит буфер. Если следующим событием будет получение данных, то программа проверит, дошло ли сообщение до конца. Если да, то последует обработка согласно пункту 1, иначе будет ждать следующего Отдельно обрабатывается ситуация, когда величина будущего сообщения больше размера буфера.

Первый тег в XML сообщении называется главным тегом (root_tag).

Этот тег определяет тему сообщения. Мы будем обрабатывать сообщения четырех видов:

• сообщение о связи и о состоянии сервера MGC. Главный тег — • сообщение о списке конференций на сервере MGC. Главный тег — • сообщение о конкретной конференции. Главный тег — • сообщение о списке зарезервированных конференций. Главный Следующее, что надо определить это сути тега. Они определяют действия. Исходя из этих параметров, вызываются соответствующие функции.

Если главным тегом является, действием —, то вызывается функция response_trans_mcu_login. Эта функция вычленяет идентификаторы mcu_token и mcu_user_token и фиксирует то, что авторизация была успешно выполнена и вызывает функцию запроса списка конференций f_get_conf_list.

Если главным тегом является, действием —, то вызывается функция response_trans_mcu_logout, которая фиксирует конец авторизации и вызывает функцию f_login.

Если главным тегом является, действием —, то вызывается функция response_trans_mcu_get_state, которая выдает статус сервера MGC.

Если главным тегом является, response_trans_conf_list_get_ls, обрабатывающая сообщение о списке конференций.

Если главным тегом является, действием —, то вызывается функция response_trans_conf_2_get, обрабатывающая сообщение о конференции.

Если главным тегом является < RESPONSE_TRANS_RES_LIST>, действием —, то вызывается функция response_trans_res_list_get_meeting_room_list, обрабатывающая сообщение о списке зарезервированных конференций.

Данная функция формирует запрос списка конференций к серверу MGC в том случае, если выполнены следующие условия:

• выполнена авторизация;

• не идет обработка списка конференций.

Во время формирования запроса функция вставляет в него элемент OBJ_TOKEN, который высылается в ответе сервера. При использовании этого элемента в запросе, сервер в ответе пришлет статус изменения списка конференций по сравнению с прошлым ответом.

Функция обработки сообщений о списке конференций Обработка сообщения о списке конференций начинается после того, как закончится обработка предыдущего сообщения. Обработка начинается с того, что изменяется значение элемента OBJ_TOKEN. После этого просматривается значение тега, если он равен ‘false’, то обработка на этом завершается, т.к. список конференций не изменился.

Иначе, если мы нашли описания конференций, то пока они не кончатся, программа проделывает следующие операции:

• вырезает из XML-сообщения краткое описание конференции;

• заканчивает обработку, если конференция не была изменена;

• записывает в первый элемент списка структур conf данные о • вызывает функцию добавления в список конференций confs_add_record с аргументом, являющимся идентификатором При обнаружении списка удаленных конференций, вызывается функция удаления конференции из списка confs_del_record с аргументом, являющимся идентификатором этих конференций.

Данная структура служит для хранения в ней краткой информации о конференции. На базе массива этих структур организован двусвязный список. Основные функции добавления (confs_add_record) и удаления (confs_del_record) элемента списка будут рассмотрены далее. Структура conf включает следующие элементы:

идентификатор конференции;

количество участников;

состояние активности;

количество неопределенных участников;

идентификатор оператора конференции;

пароль входа в конференцию.

Функция добавления в список конференций confs_add_record После вызова этой функции начинается поиск в списке элемента с таким же идентификатором. Если такого элемента не оказалось, то мы начинаем искать свободный элемент в массиве структур conf и заполняем его данными из первого элемента. Затем корректируем указатели на первый, последний, следующий и предыдущий элементы массива. Затем увеличиваем количество конференций. Если же элемент с таким же идентификатором нашелся, то обновляем все его значения.

Функция confs_del_record устроена таким же образом, но удаляет элемент из списка.

Для поддержания соединения с сервером необходимо отправлять сообщения в сервер с частотой не реже одного сообщения в 50 секунд.

Поэтому при любых обстоятельствах каждые 50 секунд запускается функция f_get_conf_list, которая формирует запрос о состоянии сервера. Этот запрос не отсылается, если не выполнена авторизация или обрабатывается список конференций.

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

начать запись конференции;

закончить запись конференции;

поставить запись конференции на паузу;

закончить конференцию;

запросить список участников выбранной конференции;

выключить микрофон у выбранного участника;

включить микрофон у выбранного участника;

выключить видеосигнал от выбранного участника;

выключить видеосигнал от выбранного участника;

выбрать одну из раскладок, представленных на рис. 2-1.

Рис. 2-1. Варианты раскладок видеоэкранов Но, в основном, эти функции состоят из создания запросов к серверу.

Такого типа функции уже были описаны, поэтому остальные мы описывать не будем. Функции, добавленные для взаимодействия с контроллером Crestron PRO2, будут описаны в следующем разделе.

Последним принципиальным моментом является структура для хранения информации об участниках. Действия над структурой party аналогичны действиям со структурой conf — над массивом этих структур строится двусвязный список. Но параметры этой структуры отличаются:

идентификатор участника;

статус видеосигнала;

статус аудиосигнала;

информация об интерфейсе подключения;

Реализация основных функций программы для контроллера AMX NIпредставлена в приложении 2.

Разработка программы для контроллера Crestron PRO2 и ее взаимодействие с графическим интерфейсом Вся информация, которая будет отображаться на сенсорной панели, проходит через контроллер Crestron PRO2. Поэтому нам понадобилось создать небольшой протокол обмена данными между контроллерами AMX NI-2100 и Crestron PRO2.

Необходимые данные об одном участнике занимают 108 байт. Если использовать открывающие и закрывающие теги, то количество передаваемых данных увеличится примерно в 4 раза. Что будет составлять более 400 байт. Следовательно, информация о 80 участниках будет занимать около 32Кбайт. Наши измерения показали, что скорость чтения полезных данных через интерфейс Ethernet у контроллера Crestron PRO2 очень низкая — 38,1Кбайт в секунду. Таким образом, прием информация о 80 участниках будет занимать около одной секунды.

Это допустимое время реакции, но если учесть, что перед этим контроллер NI-2100 будет работать около секунды, то задержка получается значительная. Поэтому было принято решение отказаться от формата XML.

Формат XML очень удобен и универсален, но наш протокол не должен быть универсальным или легко расширяемым. Он должен быть максимально компактным. Исходя из этого требования, был реализован следующий способ передачи информации.

Если надо передать список участников от контроллера АМХ NI- контроллеру Crestron PRO2, то по TCP/IP соединению между контроллерами передавалось сообщение вида «part:имя участника\x1F идентификатор участника\x1F статус видеосигнала\x1F статус аудиосигнала\x1F информация об интерфейсе подключения\x1F метод подключения\x1F IP-адрес\x1F статус подключения\x1F\x0A имя участника\x1F идентификатор участника\x1F статус видеосигнала\x1F статус аудиосигнала\x1F информация об интерфейсе подключения\x1F метод подключения\x1F IP-адрес\x1F статус подключения\x1F\x0A\x03».

Где \x1F, \x0A, \x03 это шестнадцатеричный вид символов «разделитель данных», «новая строка» и «конец текста» в ASCII.

Аналогично передается информация о конференциях.

«сonf:имя конференции\x1F идентификатор конференцииx1F количество участников\x1F состояние активности\x1F количество неопределенных участников\x1F идентификатор оператора конференции\x1F статус записи\x1F пароль входа в конференцию\x1F\х0А имя конференции\x1F идентификатор конференцииx1F количество участников\x1F состояние активности\x1F количество неопределенных участников\x1F идентификатор оператора конференции\x1F статус записи\x1F пароль входа в конференцию\x1F\х0А\х03»

Единичные команды отправляются с символом «конец текста», например: «MGC_online\x03», «MGC_offline\x03». После того, как контроллер принимает такое сообщение, он присваивает соответствующей переменной значение 0 или 1.

Для создания TCP/IP соединения контроллеру Crestron было решено отвести роль сервера, так как для контроллера АМХ уже была разработана клиентская часть.

Реализовав передачу информации между контроллерами, нам необходимо было реализовать хранение и отображение этих данных. Для хранения данных мы разработали в текстовом редакторе Crestron SIMPL+ структуры, аналогичные структурам conf и party. В этом приложении разрабатывался модуль для решения проблемы отображения списка.

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

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

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

Для этой цели на контроллере Crestron запущен осциллятор, который каждые две секунды отправляет команду обновления списка в контроллер АМХ. Таким образом, мы получали обновляемый каждые две секунды список.

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

• Из контроллера АМХ структуры conf и party отправляются по порядку, в котором они следуют в списке. Т.е. следующим отправляется элемент, на который указывает указатель next.

• В контроллере Crestron эти структуры сохраняются в массив структур, но без организации списка.

• Определить диапазон элементов, которые должны отображаться, несложно. Поэтому остается только вывести подряд десять Интерфейс сенсорной панели разрабатывается средствами, доступными в графическом редакторе Crestron VisionTools Pro-e.

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

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

отображение и завершение конференций, начало, пауза и остановка записи конференции и др.

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

• Программу для контроллера AMX NI-2100 объемом более 1000строк.

Данная программа разрабатывалась в текстовом редакторе AMX NetLinx Studio 2. В программе реализован протокол для взаимодействия с сервером видеоконференцсвязи Polycom MGC и частичная обработка сообщений, принимаемых от сервера.

• Программу для контроллера Crestron PRO2, состоящую из 40 модулей.

Данная программа разрабатывалась в среде разработки Crestron SIMPL Windows. В программе реализовано взаимодействие с контроллером АМХ NI-2100 и с графическим интерфейсом сенсорной панели Crestron TPMC-8x.

• Графический интерфейс для сенсорной панели Crestron TPMC-8x включающий 2 страницы и 6 подстраниц. Интерфейс был разработан в графическом редакторе Crestron Vision Tools Pro-e. Интерфейс обеспечивает взаимодействие пользователя со всей системой.

Реализованный программно-аппаратный комплекс внедрен в эксплуатацию в компании ЗАО «КРОК инкорпорейтед», о чем свидетельствует прилагаемая справка.

Список используемой литературы 1. «NI-2100 netlinx® integrated controller», http://www.amx.com//techdocs/datasheets/NI-2100NetLinxControllerDS.pdf, 2004 г.

2. «MGC Manager руководство пользователя», http://www.polycom.com/common/documents/support/user/products/network/mgc_ma nager_user_guide_v8.0.pdf, 2006 г.

3. www.wikipedia.ru – энциклопедический портал.

4. «NetLinx Programming Language», http://www.amx.com//techdocs/NetLinxStudio2.OperationReferenceGuide.pdf, 5. «PRO2 Professional Dual Bus Control System», http://www.crestron.com/downloads/pdf/product_manuals/av2_pro2.pdf, 2004 г.

6. «Crestron TPMC-8X Isys i/O™ WiFi Touchpanel Operations Guide», http://www.crestron.com/downloads/pdf/product_manuals/tpmc-8x.pdf, 2006 г.

7. «Crestron Simpl Windows»

http://www.crestron.com/downloads/pdf/product_misc/sw-simpl_primer.pdf, 2003 г.

8. «MGC XML API Version 8.0 e-book», http://www.polycom.com/emea/en/support/network/Previous_MGC_software.html, 9. «Структуры данных и алгоритмы», Альфред В. Ахо, Джон Э.

Хопкрофт, Джеффри Д. Ульман. Издательство "Вильямс", 2000 г. – 384 стр.

10. «Алгоритмы: построение и анализ (2-е издание)», Рональд Ривест, Томас Кормен, Чарльз Лейзерсон. Издательство "МЦНМО", 2000 г. – 960 стр.

11. «Протоколы TCP/IP. Практическое руководство», Р. Стивенс.

Издательство "Невский Диалект", 2003 г. – 672 стр.

Приложение 1. Ответ сервера MGC на запрос о списке конференций.

Для удобства чтения уровни тегов были отформатированы смещениями. Для исключения избыточности была оставлена информация только о двух конференциях.

Content-Length: Content-Type: application/xml; charset=iso-8859- Pragma: MESSAGE_ID= Server: PolycomHTTPServer Connection: Keep-Alive Cache-control: private 2008-12-11T09:16: 2008-12-11T11:16: switching контроллера AMX NI-2100.

PROGRAM_NAME='main' (***********************************************************)

(* STRUCTURE DEFINITIONS GO BELOW *)

DEFINE_DEVICE

DEFINE_CONSTANT

DEFINE_VARIABLE

DEFINE_START

pocket_in_process= conf_list_busy= ip_client_open(mgc.port, '192.168.1.10', 81, 1) ip_client_open(crestron.port, '192.168.1.11', 56789, 1) create_buffer mgc, socket_rx create_buffer crestron, crestron_rx confs_num= confs_first_index= confs_last_index= for(q=1; q=max_confs; q++) conf[q].id='-1' confs_obj_token='-1' rooms_num=0;

rooms_first_index=0;

rooms_last_index=0;

for(q=1; q=max_rooms; q++) rooms[q].id='-1';

rooms_obj_token='-1';

DEFINE_EVENT

socket_connected= print('mgc online!!!') send_string crestron, "'mgc_online',$0D,$0A" //print ("ITOA(MAX_LENGTH_STRING(socket_rx))") offline:

socket_connected=0; logged_in= message_not_full= if(pocket_in_process=0) socket_rx = '' print('mgc offline!!!') send_string crestron, "'mgc_offline',$0D,$0A" mcu_token=0; mcu_user_token=0;

wait(50) ip_client_open(mgc.port, '192.168.1.10', 81, 1) onerror:

socket_connected=0; logged_in= mcu_token=0; mcu_user_token=0;

message_not_full= if(pocket_in_process=0) socket_rx = '' print('mgc connect error!!!') send_string crestron, "'mgc_onerror',$0D,$0A" wait(50) ip_client_open(mgc.port, '192.168.1.10', 81, 1) string:

char http_header[1024]; char root_tag[32]; char return_status[1024]; char action[32] //if(debug) print("data.text, ' - it`s received from mgc!!!',$0D,$0A") while(pocket_in_process=1){} if (message_not_full=0){ pocket_in_process= if(debug) print("'find pocket!!!',$0D,$0A");

if (find_string(socket_rx, "$0D,$0A,$0D,$0A", 1)!=0) http_header =get_buffer_string(socket_rx, (find_string(socket_rx, "$0D,$0A,$0D,$0A", 1)+3))//give with end if(debug) print("'find http header!!!',$0D,$0A");

future_messages_length = length_from_http_header(http_header) if(debug) print("'futures_messages_lengt = ',ITOA(future_messages_length),'!!!',$0D,$0A") if(future_messages_length>500000) print("'ERROR!!! Messages size = ', ITOA(future_messages_length), '!!!'") print('dont find http_header!!!') if (length_string(socket_rx)>=future_messages_length) message_not_full= xml_message=get_buffer_string(socket_rx,future_messages_length) if(debug) print('Start processing!!!') start_processing() //string_preprocessing() print ('message not full!!!') message_not_full= pocket_in_process=0;

data_event[crestron] online:

print('crestron online!!!') if (socket_connected) send_string crestron, "'mgc_online',$0D,$0A" offline:

print('crestron offline!!!') ip_client_open(crestron.port, '192.168.1.11', 56789, 1) onerror:

print('crestron connect error!!!') ip_client_open(crestron.port, '192.168.1.11', 56789, 1) string:

print('find string from crestron!!!') crestron_message =get_buffer_string(crestron_rx, (find_string(crestron_rx, "$03", 1)))//give with end if (find_string(crestron_message, 'get_conf_list', 1)) f_get_conf_list() if (find_string(crestron_message, 'get_party_list', 1)){ selected_conf_id= get_tags_value(crestron_message, 'get_party_list') if (find_string(crestron_message, 'terminate_conf', 1)){ selected_conf_id= get_tags_value(crestron_message, 'terminate_conf')

DEFINE_PROGRAM

char post[65534];

char pocket[65534];

while(send_pocket_busy=1){} send_pocket_busy=1;

if((mcu_token=0) && (mcu_user_token=0)) message_id=0;

if(debug) print ('start transmitting to mgc!!!') // substitute MCU_TOKEN, MCU_USER_TOKEN and MESSAGE_ID post="";

post="post, remove_string(message,'',1), itoa(mcu_token), remove_string(message, '', 1)";

post="post, remove_string(message,'',1), itoa(mcu_user_token), remove_string(message,'',1)";

post="post, remove_string(message,'', 1), itoa(message_id), remove_string(message,'',1)";

post="post, message";

header="";

header="header, 'POST http://mgc HTTP/1.1',$0D,$0A";

header="header, 'Content-Type: text/xml',$0D,$0A";

header="header, 'Content-Length: ', itoa(length_string(post)),$0D,$0A";

header="header, 'Host: mgc',$0D,$0A";

header="header, 'Cookie:',$0D,$0A";

header="header, 'Pragma: MESSAGE_ID=', itoa(message_id),$0D,$0A";

header="header, 'Server: PolycomHTTPServer',$0D,$0A";

header="header, 'Connection: Keep-Alive',$0D,$0A";

header="header, 'Cache-control: private',$0D,$0A";

header="header,$0D,$0A";

pocket="header, post";

message_id=message_id+1;

send_string mgc, pocket if(debug) print("'end of transmitting pocket length ',itoa(length_string(pocket)),' bytes to mgc!!!',$0D,$0A");

send_pocket_busy=0;

define_function f_login(){ //integer t;

char message[1024];

if(user_name="") user_name='POLYCOM';

if(password="") password='POLYCOM';

if(station_name="") station_name='AMX';

message="'00', user_name, '', password, '', station_name, 'falsefalse'";

if(debug) send_string 0:0:0, "'sending login!!!',$0D,$0A" send_pocket(message);

define_function f_get_state(){ char message[500];

message="' '";

if(debug) send_string 0:0:0, "'sending get state!!!',$0D,$0A" send_pocket(message);

define_function f_get_conf_list() char message[500];

integer i;

if(logged_in=0){ if(debug) print("'no conf list available - need log in!!!',$0D,$0A");return;} if(conf_list_busy){ print("'conf list busy!!!',$0D,$0A"); return;} message="'00', confs_obj_token, ''";

if(debug) print("'sending get conf list!!!',$0D,$0A");

send_pocket(message);

define_function start_processing() char root_tag[64]; char return_status[1024]; char action[64] root_tag=remove_string(xml_message,'>',1);

if(debug) print("'find root_tag: ',root_tag,$0D,$0A");

return_status=remove_string(xml_message,'',1);

if(debug) print("'find return status: ', return_status,$0D,$0A");

action=remove_string(xml_message,'',1);

action=remove_string(xml_message, '>', 1);

if(debug) print("'find action ', action,$0D,$0A");

if(root_tag='') if(action='') response_trans_mcu_login(return_status) if(action='') response_trans_mcu_logout(return_status) if(action='') response_trans_mcu_logout(return_status) if(action='') response_trans_mcu_get_state(return_status) if(root_tag='') if(action='') response_trans_conf_list_get_ls(root_tag) if(root_tag='') if(action='') print('it`s get??!!')//call 'response_trans_conf_2_get'(root_tag, action) if(action='') print('it`s get??!!!')//call 'response_trans_conf_2_get'(root_tag, action) if(root_tag='') //if(action='') response_trans_res_list_get_meeting_room_list(root_tag) print("'Indefinet Root tag!!!'") xml_message="" define_function response_trans_mcu_login(char return_status[1024]) char t[4048] //t=gather('', xml_message) mcu_token=atoi(get_tags_value(xml_message, 'MCU_TOKEN'));

remove_string(xml_message,'',1) mcu_user_token=atoi(get_tags_value(xml_message, 'MCU_USER_TOKEN'));

remove_string(xml_message,'',1) // mcu_version=getsubtag(t, "MCU_VERSION", "MAIN")+"."+getsubtag(t, "MCU_VERSION", "MAJOR")+"."+getsubtag(t, "MCU_VERSION", "MINOR");

// mcms_version=getsubtag(t, "MCMS_VERSION", "MAIN")+"."+getsubtag(t, "MCMS_VERSION", "MAJOR")+"."+getsubtag(t, "MCMS_VERSION", "MINOR");

// authorization_group=gettag(t,"AUTHORIZATION_GROUP");

// API_Number=gettag(t,"API_NUMBER");

// product_type=gettag(t,"PRODUCT_TYPE");

// operation_system=gettag(t,"OPERATING_SYSTEM");

logged_in=1;

if(debug) print("'LOGGET IN!!!',$0d,$0A") f_get_conf_list() define_function response_trans_mcu_logout(char return_status[1024]) logged_in=0;

if(debug) print("'LOGGED OUT!!!',$0d,$0A") //xml_message="" f_login() define_function response_trans_mcu_get_state(char return_status[1024]) //...

//............

integer ID_state ID_state=atoi(get_tags_value(return_status, 'ID'));

remove_string(xml_message,'ID',1) if(ID_state=0) print("'MCU_STARTUP_STATE',$0d,$0A") if(ID_state=1) print("'MCU_NORMAL_STATE',$0d,$0A") if(ID_state=2) print("'MCU_DISCONNECTED_STATE',$0d,$0A") if(ID_state=3) print("'MCU_MAJOR_STATE',$0d,$0A") if(ID_state=4) print("'MCU_MINOR_STATE',$0d,$0A") if(ID_state=5) print("'MCU_RESETTING_STATE',$0d,$0A") if(ID_state=6) print("'MCU_LOW_MEMORY_STATE',$0d,$0A") if(ID_state=6) print("'MCU_DIAGNOSTICS_STATE',$0d,$0A") define_function response_trans_conf_list_get_ls(char root_tag[256]) integer debug_trasactions, debug_xml char conf_summary[2048] char conf_change[8] char duration[256] char changed[8] char deleted_conf_list[2048] char deleted_id[512] while (conf_list_busy){} conf_list_busy=1;

debug_xml= debug debug_trasactions = debug if(debug_xml) print("'confs obj token sended: ',confs_obj_token,$0d,$0A") confs_obj_token=get_tags_value(xml_message,'OBJ_TOKEN');

remove_string(xml_message,'',1) if(debug_xml) print("'confs obj token received: ',confs_obj_token,$0d,$0A") changed=get_tags_value(xml_message,'CHANGED');

remove_string(xml_message,'',1) if(debug_xml) print("'changed attribute received: ',changed,$0d,$0A") if(changed!='false') //while((find('', socket_rx)=0) && (find('', socket_rx)=0) && (find('', socket_rx)=0)) delay(1);

if(find_string(xml_message,'', 1)) while(find_string(xml_message,'', 1)!=0) conf_summary=get_tags_value(xml_message,'CONF_SUMMARY');

remove_string(xml_message,'',1) conf_change=get_tags_value(conf_summary, 'CONF_CHANGE');

if(debug_xml) print("'conf_summary found with conf name:

',(get_tags_value(conf_summary,'NAME')),conf_change,$0d,$0A") if(conf_change!='none') conf[1].name=get_tags_value(conf_summary, 'NAME');

remove_string(conf_summary, '',1) conf[1].id=get_tags_value(conf_summary, 'ID');

remove_string(conf_summary, '',1) conf[1].num_parties=get_tags_value(conf_summary, 'NUM_PARTIES'); remove_string(conf_summary, '',1) conf[1].num_connected_parties=get_tags_value(conf_summary, 'NUM_CONNECTED_PARTIES'); remove_string(conf_summary, '',1) conf[1].on_hold=get_tags_value(conf_summary, 'ON_HOLD');

remove_string(conf_summary, '',1) conf[1].num_undefined_parties=get_tags_value(conf_summary, 'NUM_UNDEFINED_PARTIES'); remove_string(conf_summary, '',1) conf[1].numeric_id=get_tags_value(conf_summary, 'NUMERIC_ID'); remove_string(conf_summary, '',1) conf[1].recording_status=get_tags_value(conf_summary, 'RECORDING_STATUS'); remove_string(conf_summary, '',1) conf[1].entry_password=get_tags_value(conf_summary, 'ENTRY_PASSWORD'); remove_string(conf_summary, '',1) //if(conf_change="new") confs_add_record("-1"); // old //if(conf_change="update") confs_add_record(confs[0].id); // old //while(len(socket_rx)=max_rooms) if(debug_internal) print("'confs array is full',$0D,$0A");

conf[i].name=conf[1].name;

conf[i].id=conf[1].id;

conf[i].num_parties=conf[1].num_parties;

conf[i].num_connected_parties=conf[1].num_connected_parties;

conf[i].on_hold=conf[1].on_hold;

conf[i].num_undefined_parties=conf[1].num_undefined_parties;

conf[i].numeric_id=conf[1].numeric_id;

conf[i].recording_status=conf[1].recording_status;

conf[i].entry_password=conf[1].entry_password;

// correct queues registrs if(new) if(confs_first_index=1) confs_first_index=i;

confs_last_index=i;

conf[i].prev_index=0;

conf[i].next_index=0;

conf[confs_last_index].next_index=i;

conf[i].prev_index=confs_last_index;

conf[i].next_index=0;

confs_last_index=i;

if(debug_internal) print("'conf id ',conf[i].id,' added at index ',itoa(i),$0d,$0A");

confs_num=confs_num+1;

if(debug_internal) print("'conf id ',conf[i].id,'updated at index ',itoa(i),$0d,$0A");

confs_num=confs_num;

define_function confs_del_record(char id[]) integer i;

i=1;

while((imax_confs) if((conf[i].prev_index!=1) && (conf[i].next_index!=1)) conf[conf[i].prev_index].next_index=conf[i].next_index;

conf[conf[i].next_index].prev_index=conf[i].prev_index;

else if(conf[i].prev_index!=1) conf[conf[i].prev_index].next_index=1;

confs_last_index=conf[i].prev_index;

else if(conf[i].next_index!=1) conf[conf[i].next_index].prev_index=1;

confs_first_index=conf[i].next_index;

confs_first_index=1;

confs_last_index=1;

if(debug) print("'conf id ',conf[i].id,' deleted at index ',ITOA(i),$0d,$0A");

conf[i].id='-1';

confs_num=confs_num-1;

define_function response_trans_res_list_get_meeting_room_list(char root_tag[]) char room_summary[65534];

char room_change[8];

char changed[8];

char deleted_room_list[65534];

char deleted_id[65534];

integer debug_xml debug_xml=debug if(debug_xml) print("'rooms obj token sended %s\n', rooms_obj_token,'!!!'") rooms_obj_token=get_tags_value(xml_message,'OBJ_TOKEN');

remove_string(xml_message,'',1) if(debug_xml) print("'rooms obj token received ', rooms_obj_token,'!!!'") changed=get_tags_value(xml_message,'CHANGED');

remove_string(xml_message,'',1) if(debug_xml) print("'changed attribute received ', changed,'!!!'") if(changed!='false') if(find_string(xml_message,'', 1)) while(find_string(xml_message,'', 1)!=0) room_summary=get_tags_value(xml_message,'MEETING_ROOM_SUMMAR Y'); remove_string(xml_message,'',1) room_change=get_tags_value(room_summary, 'RES_CHANGE');

if(debug_xml) print("'meeting_room_summary found with room name ', get_tags_value(room_summary, 'NAME')");

if(room_change!='none') rooms[1].name=get_tags_value(room_summary, 'NAME');

rooms[1].id=get_tags_value(room_summary, 'ID');

rooms[1].entry_password=get_tags_value(room_summary, 'ENTRY_PASSWORD');

rooms[1].password=get_tags_value(room_summary, 'PASSWORD');

rooms[1].numeric_id=get_tags_value(room_summary, 'NUMERIC_ID');

if(room_change='new') rooms_add_record('-1');

if(room_change='update') rooms_add_record(rooms[1].id);