ITU-T H.350-2011
マルチメディア会議用のディレクトリ サービス アーキテクチャ (研究グループ 16)

規格番号

ITU-T H.350-2011

制定年

2011

出版団体

ITU-T - International Telecommunication Union/ITU Telcommunication Sector

範囲

この勧告 1 では、軽量ディレクトリ アクセス プロトコル (LDAP) を使用したマルチメディア会議のためのディレクトリ サービス アーキテクチャについて説明します。 標準化されたディレクトリ サービスは、エンドポイント@検索可能なホワイト ページ@およびクリック可能なダイヤルと個人の関連付けをサポートできます。 ディレクトリ サービスは、エンドポイント@ の構成や、信頼できるデータ ソースに基づくユーザー認証にも役立ちます。 この推奨事項では、ネットワーク上のエンドポイントを表し、それらのエンドポイントをユーザーに関連付ける標準化された LDAP スキーマについて説明します。 ビデオおよび音声固有のディレクトリ、エンタープライズ ディレクトリ、コール サーバーおよびエンドポイントの相互関係に関する設計および実装の考慮事項について説明します。 コール サーバー @ エンドポイント @ ユーザー @ 認証およびホワイト ページ情報に common@ 権限のあるデータ ソースを使用することは、大規模なマルチメディア会議環境の重要な側面です。 共通のデータ ソースがない場合、サービス プロバイダーはこれらの各機能を管理するための個別のプロセスを作成する必要があります。 基礎となるデータを表すために使用される LDAP スキーマを標準化することで、さまざまなシステム ベンダーの製品を一緒に導入して全体的なアプリケーション環境を作成できます。 たとえば、あるプロバイダーが開発したホワイト ページ検索エンジンは、さらに 3 番目のプロバイダーが作成したコール サーバーが管理するシグナリングを使用して、2 番目のプロバイダーが作成した IP 電話にディレクトリ情報を提供できます。 これらの異種システムはそれぞれ、同じ基盤となるデータ ソースにアクセスできるため、各システムの個別の管理を調整する必要性が軽減または排除されます。 ユーザーにとっての大きな利点は、このデータの管理を既存の顧客管理ツールに組み込むことができ、アプリケーションを迅速かつ柔軟にスケールアップできることです。 確かに@ 多くのテクノロジー プロバイダーはすでに LDAP を製品に組み込んでいます@ が、標準化されたスキーマの恩恵を受けずにそうすることを余儀なくされています。 この勧告は、相互運用性とパフォーマンスを向上させるためにこれらの表現を標準化する取り組みを表しています。 URL はいくつかの会議プロトコル用にすでに標準化されていますが、ディレクトリ内での URL の表現は標準化されていません。 この推奨事項は、URL を検索および特定するための標準化された方法をサポートします。 これは、「クリック可能なダイヤル」をサポートするために必要な手順です。 サービス プロバイダーとエンドポイントの両方がアクセスできる場所にサービス プロバイダーによって正しい設定が保存されている場合、エンドポイント構成の管理を改善できます。 LDAP は、コール サーバーとエンドポイントの両方からアクセスできる便利な保存場所を提供します。 したがって、ディレクトリを使用してエンドポイント構成をサポートすることができます@。 これは、操作を簡素化し、ユーザーのモビリティをサポートするために重要です。 他のテクノロジーもエンドポイント構成をサポートしていることに注意してください。 特に、完全な構成のための SNMP の使用と、登録サーバー アドレスを取得するための DNS SRV リソース レコードの使用がサポートされています。 したがって、@ ITU-T H.350 は、権威あるエンドポイント構成アーキテクチャ@ ではなく、このタスクを支援できる 1 つのツールとして見なされるべきです。 ITU-T H.350 の使用には、機能としてエンドポイント固有の構成があり、各エンドポイントが固有の構成を持つことが望ましいことに注意してください。 このアーキテクチャでは、commObject@ と呼ばれる汎用オブジェクト クラス @ を使用して、ビデオまたは音声プロトコルに共通の属性を表します。 補助クラスは、ITU-T H.350.x シリーズの勧告に記載されている ITU-T H.323@ ITU-T H.235.x@ または ITU-T H.320@ などの特定のプロトコルを表します。 複数の 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 表現。 さらに、各エントリには、エントリの構造オブジェクト クラスとして機能する commObject が含まれている必要があります。 アーキテクチャには 2 つの基本コンポーネントがあります。 commURI オブジェクトは、人またはリソースを commObject にリンクすることだけを目的とするクラスです。 commURI の「ポインタ」を個人のディレクトリ エントリ @ に配置すると、その個人は特定のターゲット commObject に関連付けられます。 同様に、各 commObject には、commObject に関連付けられた個人またはリソースを指す commOwner@ と呼ばれるポインタ @ が含まれます。 このようにして、人やリソースをエンドポイントに関連付けることができます。 エンタープライズ ディレクトリに必要な唯一の変更は、単純なオブジェクト クラス commURI の追加です。 CommObject データは同じディレクトリまたは完全に別のディレクトリでインスタンス化できるため、柔軟な実装が可能になります。 1 この推奨事項には、commURIObject および commObject のスキーマ構成ファイルを含む電子添付ファイルが含まれています。