ITU-T - International Telecommunication Union/ITU Telcommunication Sector
сфера применения
В данной Рекомендации1 описывается архитектура служб каталогов для мультимедийных конференций с использованием упрощенного протокола доступа к каталогам (LDAP). Стандартизированные службы каталогов могут поддерживать объединение людей с конечными точками@белыми страницами с возможностью поиска@и интерактивным набором номера. Службы каталогов также могут помочь в настройке конечных точек и аутентификации пользователей на основе авторитетных источников данных. В этой Рекомендации описывается стандартизированная схема LDAP для представления конечных точек в сети и связывания этих конечных точек с пользователями. В нем обсуждаются аспекты проектирования и реализации взаимосвязи видео- и голосовых каталогов@корпоративных каталогов@серверов вызовов и конечных точек. Использование общего@авторитетного источника данных для аутентификации сервера@конечной точки@пользователя@ и информации официальных страниц является важным аспектом крупномасштабных сред мультимедийных конференций. Без общего источника данных поставщики услуг должны создавать отдельные процессы для управления каждой из этих функций. Путем стандартизации схемы LDAP, используемой для представления базовых данных, продукты разных поставщиков систем можно развертывать вместе для создания общей среды приложений. Например, поисковая система «белых страниц», разработанная одним провайдером, может доставлять справочную информацию на IP-телефоны, произведенные вторым провайдером, с сигнализацией, управляемой сервером вызовов, созданным еще третьим провайдером. Каждая из этих разрозненных систем может получить доступ к одному и тому же базовому источнику данных@, что снижает или устраняет необходимость координации отдельного управления каждой системой. Значительным преимуществом для пользователя является то, что управление этими данными можно включить в существующие инструменты управления клиентами@, что позволяет быстро и гибко масштабировать приложения. Действительно, многие поставщики технологий уже включили LDAP в свои продукты, но были вынуждены сделать это, не имея возможности воспользоваться стандартизированной схемой. Данная Рекомендация представляет собой попытку стандартизировать эти представления для улучшения совместимости и производительности. Хотя URL-адреса уже стандартизированы для нескольких протоколов конференц-связи, их представление в каталоге еще не стандартизировано. Данная Рекомендация поддерживает стандартизированный способ поиска и определения местоположения URL-адресов. Это необходимый шаг для поддержки интерактивного набора номера. Управление конфигурациями конечных точек можно улучшить, если правильные настройки сохраняются поставщиком услуг в месте, доступном как поставщику услуг, так и конечной точке. LDAP обеспечивает удобное место хранения, доступ к которому может получить как сервер вызовов, так и конечная точка; таким образом, можно использовать каталог для поддержки конфигурации конечной точки@, что важно для упрощения работы и поддержки мобильности пользователей. Обратите внимание, что другие технологии также поддерживают настройку конечной точки@, в частности, использование SNMP для полной настройки и записей ресурсов DNS SRV для получения адресов серверов регистрации. Поэтому@ МСЭ-Т H.350 следует рассматривать не как авторитетную архитектуру конфигурации конечной точки@, а скорее как один инструмент, который может помочь в решении этой задачи. Обратите внимание, что использование ITU-T H.350 имеет особенность конфигурации@, специфичную для конечной точки, где желательно, чтобы каждая конечная точка имела уникальную конфигурацию. В этой архитектуре используется общий класс объектов@, называемый commObject@, для представления атрибутов, общих для любого видео- или голосового протокола. Вспомогательные классы представляют собой конкретные протоколы@, такие как ITU-T H.323@ ITU-T H.235.x@ или ITU-T H.320@, как описано в серии Рекомендаций ITU-T H.350.x. Несколько классов ITU-T H.350.x можно объединить для представления конечных точек, поддерживающих более одного протокола. Например, @ конечные точки, которые поддерживают ITU-T H.323@ ITU-T H.235.x и ITU-T H.320, будут включать ITU-T H.350@ ITU-T H.350.1@ ITU-T H.350.2 @ и ITU-T H.350.3 в их представлениях LDAP. Кроме того, @ каждая запись должна содержать comObject, который будет служить структурным классом объекта записи. В архитектуре есть два основных компонента. Объект commURI — это класс, единственная цель которого — связать человека или ресурс с объектом commObject. Помещая «указатель» commURI в запись @ каталога индивидуума, этот индивидуум становится ассоциированным с конкретным целевым объектом commObject. Аналогично@ каждый commObject содержит указатель@, называемый commOwner@, который указывает на человека или ресурс, связанный с commObject. Таким образом@ люди или ресурсы могут быть связаны с конечными точками. Единственное изменение, необходимое для каталога предприятия, — это добавление простого класса объектов commURI. Данные CommObject могут быть созданы в том же или совершенно отдельном каталоге@, что обеспечивает гибкость реализации. 1 Данная Рекомендация включает электронное приложение, содержащее файлы конфигурации схемы для commURIObject и commObject.