ビデオデータを送信及び受信する装置を有する装置のトポロジ内の任意の装置に、メッセージ内の種類識別子に応じて該メッセージ内で指定された動作を行わせる段階、を有する方法。前記トポロジ内の、ソースからシンクへ送信されたメッセージを受信する各装置に、該メッセージ内の識別子の特性に応じて動作を行わせる段階、を有する請求項1に記載の方法。前記メッセージ識別子が、動作は宛先に向かう途中で行われると示すか否かを決定する段階、前記メッセージ識別子が動作は宛先に向かう途中で行われると示す場合、前記メッセージを受信すると、要求された動作を実行する段階、を有する請求項1に記載の方法。前記メッセージ識別子が、動作は最終的な宛先からの確認応答に対してのみ行われると示すか否かを決定する段階、前記メッセージ識別子が動作は最終的な宛先からの確認応答に対してのみ行われると示す場合、確認応答を受信したときのみ、動作を実行する段階、を有する請求項1に記載の方法。前記メッセージの識別子が、宛先のみが動作を実行すると示すか否かを決定する段階、前記メッセージの識別子が宛先のみが動作を実行すると示す場合、受信装置が宛先装置であるかどうかを決定する段階、受信装置が宛先装置である場合、及び受信装置が宛先装置である場合のみ、前記メッセージ内の動作を実行する段階、を有する請求項1に記載の方法。装置が前記メッセージの宛先でない場合、前記メッセージを前記宛先への経路に沿って転送する段階、を有する請求項5に記載の方法。前記メッセージ内の動作が完了すると、前記ソースへ確認応答を返す段階、を有する請求項1に記載の方法。前記メッセージを受信すると、動作を要求するメッセージに応答して経路トレーニングを実施する段階、を有する請求項1に記載の方法。前記メッセージの宛先から確認応答を受信したときのみ、動作を要求するメッセージを用いて経路トレーニングを実施する段階、を有する請求項1に記載の方法。メッセージの種類及び装置が該メッセージの宛先か否かに依存して、音声及びビデオデータを送信及び受信する装置のトポロジ内の装置により、動作を要求するメッセージを受信する段階、を有する請求項1に記載の方法。コンピュータ可読媒体であって、ビデオデータのソース及びシンクを有する装置のトポロジ内の装置のプロセッサにより実行されるための命令を格納し、該命令は、実行されるべき命令を有するメッセージを受信し、メッセージの種類を決定し、該メッセージの種類に基づき、該メッセージ内で指定された動作を実行する、ためのものである、ことを特徴とする媒体。前記メッセージの種類が、動作は宛先に向かう途中で行われる種類のものである否かを決定し、前記メッセージの種類が動作は宛先に向かう途中で行われる種類のものである場合、前記メッセージを受信すると、要求された動作を実行する、ための命令を更に格納する請求項11に記載の媒体。前記メッセージが、動作は最終的な宛先からの確認応答に対してのみ実行される種類のものか否かを決定し、前記メッセージが動作は最終的な宛先からの確認応答に対してのみ実行される種類のものである場合、確認応答を受信したときのみ、動作を実行する、ための命令を更に格納する請求項11に記載の媒体。前記メッセージの種類が、宛先のみが動作を実行する種類のものか否かを決定し、前記メッセージの種類が宛先のみが動作を実行する種類のものである場合、受信装置が宛先装置であるかどうかを決定し、受信装置が宛先装置である場合、及び受信装置が宛先装置である場合のみ、前記メッセージ内に示された動作を実行する、ための命令を更に格納する請求項11に記載の媒体。装置が前記メッセージの宛先でない場合、前記メッセージを前記宛先への経路に沿って転送する、ための命令を更に格納する請求項14に記載の媒体。前記メッセージ内に示された動作が完了すると、前記ソースへ確認応答を返す、ための命令を更に格納する請求項11に記載の媒体。前記メッセージを受信すると、動作を要求するメッセージに応答して経路トレーニングを実施する、ための命令を更に格納する請求項11に記載の媒体。前記メッセージの宛先から確認応答を受信したときのみ、動作を要求するメッセージを用いて経路トレーニングを実施する、ための命令を更に格納する請求項11に記載の媒体。メッセージの種類及び前記受信装置が該メッセージの宛先か否かに依存して、ビデオデータを送信及び受信する装置のトポロジ内の装置により、動作を要求するメッセージを受信する、ための命令を更に格納する請求項11に記載の媒体。前記メッセージのソースと宛先との間の該メッセージの経路に沿った装置により、該メッセージを行わせる、ための命令を更に格納する請求項11に記載の媒体。装置のトポロジ内のビデオデータを送信するソースから、該トポロジ内のシンクへのメッセージを受信する受信機、ビデオデータを前記シンクへ送信する送信機、実行されるべき動作を有するソースからのメッセージを受信し、該メッセージの種類を決定し、該メッセージを受信すると、該メッセージの宛先から確認応答を受信すると、該メッセージ内に指定された動作を実行するか又は該動作を全く実行しないかを決定するユニット、を有する装置。前記ユニットは、前記メッセージの種類が、動作は宛先に向かう途中で行われるものであるか否かを決定し、前記メッセージの種類が動作は宛先に向かう途中で行われるものである場合、前記メッセージを受信すると、前記メッセージ内の動作を実行する、ことを特徴とする請求項21に記載の装置。前記ユニットは、前記メッセージが、動作は最終的な宛先からの確認応答に対してのみ実行される種類のものか否かを決定し、前記メッセージが動作は最終的な宛先からの確認応答に対してのみ実行される種類のものである場合、確認応答を受信したときのみ、動作を実行する、ことを特徴とする請求項21に記載の装置。前記ユニットは、前記メッセージの種類が、前記メッセージの宛先のみが動作を実行する種類のものか否かを決定し、前記メッセージの種類が前記メッセージの宛先のみが動作を実行する種類のものである場合、当該装置が宛先装置であるかどうかを決定し、当該装置が宛先装置である場合、及び当該装置が宛先装置である場合のみ、前記メッセージ内に示された動作を実行する、ことを特徴とする請求項21に記載の装置。本発明は、ビデオ及び音声データを発信及び受信する装置を提供する。幾つかの実施形態によると、特定のメッセージが、ビデオ及び音声データを送信及び受信する装置間で交換されてもよい。協調的な動作が、該メッセージに応答して、ソース装置とシンク装置との間の経路に沿った装置により行われてもよい。メッセージは、宛先アドレスにより特定される目標の宛先へ送信されてもよい。図2に示されるように、メッセージENUM_PATH_RESOURCES、COMMIT_PATH_RESOURCES、及びRELEASE_PATH_RESOURCESが用いられてもよい。これらのメッセージは、例えば、DisplayPort仕様のAUXチャネルで送信されうる。アドレス空間は、メッセージ送信の前に生成される。各ソース10は、ENUM_PATH_RESOURCEメッセージ18を所望のシンク16へ送信し、主要リンク帯域幅とストリーム数をエニュメレートする。20で示されるように、所望のシンク16の直ぐ上流にあるブランチ装置14は、利用可能な帯域幅BW=x及びストリーム数STREAMS=sで応答する。この応答が更に上流に伝搬される前に、22に示されるように、上流のブランチ12は、下流のブランチ14からの利用可能な帯域幅BW=x’及びストリーム数STREAMS=s’を変更して、下流の経路から何が達成可能であるかを反映させる。結局、ソース10は、経路資源を得る。メッセージはDisplayPortのAUXのような制御バスで送信されるが、クエリは主要リンクの資源のためのものである。制御バスの帯域幅には如何なる予約もなく、制御メッセージは、主要リンクの資源が1又は2つのソースにより完全に予約済みのときでも、トポロジ内の装置間で交換される。メッセージ処理の一部として、各装置は、下流リンクとして利用可能な帯域幅の量を決定するために、主要リンクを特定の経路に沿ってトレーニングする必要があってよい。また、音声資源は、この手続の一部としてエニュメレートされる。これは、任意の所与の時点でストリーミングに利用可能なエンドポイントの数を決定するためである。リンク帯域幅のエニュメレーションは、ビデオモードエニュメレーションのようなオペレーティングシステムの動作に供給される。送り出されるべきビデオモードのエンドユーザによるこの及び非同期の選択に基づき、コミット手順は、次のようにCOMMIT_PATH_RESOURCESメッセージ24を用いて達成されてもよい。エニュメレートされた帯域幅は、コミット時間で利用可能でないかもしれない。例えば、異なるソースが異なるENUM_PATH_RESOURCESメッセージを任意の所与の時間に同一のシンクへ送信するかもしれない。それらは、共通のリンクを有する経路を有する異なるシンク宛てかもしれない。例として、ソース1のエニュメレーションのシーケンスの次に、ソース2のエニュメレーションが続き、その次にソース1のコミットが続く。ソース1のエニュメレーションのシーケンスの次に、例えば前のソース1のコミットのために失敗したソース2のコミットが続く。ソース10は、COMMIT_PATH_RESOURCEメッセージ24をシンク16へ送信する。メッセージは、所望の帯域幅及びストリーム数を有する。特定の経路に沿った全ての装置例えば、ブランチ12及び14は、このソースのために資源を予約する。応答26及び28は、成功又は失敗を示してもよい。各装置は、所望の資源のコミットに成功できるときにのみCOMMIT_PATH_RESOURCES24を伝達する。異なるソース装置からの独立した資源のコミットに加え、経路に沿った中間リンクは、低い帯域幅を維持し、失敗の別の理由を提供してもよい。リンクトレーニングは、送信機又は受信機を電気的構成に同意させるハンドシェイクである。装置のトポロジを説明するため、この概念は経路全体に拡張される。ここで、経路上の各リンクは、協調型と称される経路トレーニングでトレーニングされる必要がある。幾つかの装置は、下流装置がコミットに失敗する前に、ビデオストリームのコミットに成功した資源を有することが可能である。これらの資源をリリースするために、ソース装置は、COMMIT_PATH_RESOURCESの受信に失敗した後に、RELEASE_PATH_RESOURCES30メッセージを送出してもよい。COMMIT_PATH_RESOURCESの完了が成功した後に、アクティブビデオが開始する。反対に、ストリームが終了するとき、ソースはRELEASE_PATH_RESOURCES32を発行し、経路に沿った装置でコミットされた資源のリリースを可能にする。図3を参照すると、図3に34として示されるように、ソース10、シンク16及び各ブランチ装置12又は14は、プロセッサ36を有する。プロセッサは、受信機38及び送信機40に結合されてもよい。一実施形態では、プロセッサ36は、エニュメレートソフトウェア44を含むソフトウェアを格納する記憶装置42に結合されてもよい。従って、記憶装置42は、プロセッサ36により実行される命令を格納するコンピュータ可読媒体であってもよい。記憶装置42は、半導体、光学又は磁気メモリであってもよい。図4に示されるエニュメレートシーケンス44は、一実施形態ではソフトウェアであってもよいが、ハードウェア又はファームウェアで実施されてもよい。菱形46でのチェックは、エニュメレートメッセージがブランチ装置により受信されているか否かを決定する。受信されている場合、メッセージを受信したブランチ装置は、上流のブランチ装置に対して、該受信した装置の利用可能な帯域幅及び利用可能なストリーム数で応答する。受信した装置が、ある時間の後にエニュメレートメッセージを受信しない場合、菱形50でのチェックは、受信していない装置が、帯域幅及びストリーム数を指定する下流装置からのメッセージを受信する上流装置かどうかを決定する。下流装置からのメッセージを受信する上流装置である場合、上流装置は、該上流装置の能力を反映するために、受信した帯域幅及びストリーム数を変更する。次に、ブロック54に示されるように、該上流装置は、元の帯域幅とストリーム数又は変更された数の何れかを必要に応じて次のブランチ又はソースへ送信する。図5を参照すると、ストリームの追加及び削除のためのメッセージシーケンス図は、適切なストリーム識別子と共に、ソース60及び2つのシンク62、64を有する。シンク162の識別子は1であり、シンク264の識別子は1.2である。各装置は、1又は2でラベル付けされたポートを有する。次に、図6を参照すると、ソース160、ブランチ及びシンク162、並びにシンク264の間のシーケンス図が示される。AUXは制御チャネルを表し、主要リンクはデータチャネルを表す。図5に示されたような、トポロジ内の各リンクは例えば独立した制御及びデータチャネルを有してもよく、接続はポイントツーポイントである。アドレッシング及びルーティング機構を用いて、任意の装置へ制御チャネルでメッセージを送信する機能がある。図6に示されるように、手順は、ソースにおいてストリームのためのローカル一意識別子、マッピングテーブルの保守及びコンセントレータを含む。アドレス生成段階中、アドレスは、アドレス生成メッセージを送信することにより、トポロジ内の各装置に同意される。次に、ソースは、ENUM_PATH_RESOURCES68をAUXとして示される制御チャネルを介してブランチ及びシンク162へ送信する。また、ソースは、COMMIT_PATH_RESOURCESメッセージ70も制御経路を介してブランチ及びシンク162へ送信する。バインディングは、トポロジ内の装置が次のストリームの宛先について同意するための手順である。バインディング手順は、エニュメレーションの後に、新たなストリームを送信したいソースで開始し、ADD_STREAMメッセージ72をローカル一意ストリーム識別子例えば、シンク2の1.2で識別される所望の宛先シンク装置へ送出する。ソース60からシンク装置64への経路に沿った全ての装置は、ストリーム識別子及びストリームが受信された入力ポート例えば、1又は2をマッピングテーブル内に記憶している。各ブランチ装置は、入力ストリーム識別子該ブランチ装置のID1の出力ストリーム識別子シンク264の1.2へのマッピングを実行する。複数のソースがない場合、入力ストリーム識別子は、出力ストリーム識別子と同一である。各ブランチ装置は、出力ストリーム識別子及び出力ポート番号も、自身のマッピングテーブル内に記憶している。最後に、74で示されるように、ブランチ装置に如何なる他の資源の制約も存在しないならば、該ブランチ装置は、メッセージに含まれる経路/アドレスにより示される宛先へ該メッセージを転送する。このような資源の制約がある場合、ブランチ装置は、単に否定応答をソースへ送信する。メッセージは、所望の宛先で終端する。シンク装置がストリームを受信可能な場合、該シンク装置は確認応答76でソースに応答する。その他の場合、シンク装置は、否定応答を送信する。次に、シンクは、データチャネルにある次の新たなストリームを消費する必要があることを知る。全てのブランチ装置は、確認応答78をソースに返す。確認応答を受信すると、ソース装置は、所望の宛先に至る自身のリンクのデータチャネルで新たなストリーム80を送出する。82で示されるように、ブランチ装置は、自身のマッピングテーブルに記憶されている新たなストリームのための経路に沿ってストリームを転送する。シンク装置は、前に受信したメッセージに基づき、新たなストリームを消費する必要があることを知り、該ストリームをディスプレイで提示する。バインディング解除又は削除は、同一のストリーム識別子を有する目的の宛先へ送信されるストリーム削除メッセージ84、86を通じて実行される。これは、シンク装置にストリームの停止を予期させ、ブランチ装置に該ブランチ装置のマッピングテーブルを相応して変更させる。ストリーム削除メッセージに対する確認応答メッセージの受信は、ソースにデータチャネルでストリームを送信するのを停止させる。図7に、図4に示されたトポロジのために構築されうる種々のディスプレイ構成が示される。単一ディスプレイの構成は、音声ビデオデータを提示する単に1つのディスプレイ装置である。該構成は、既に説明したメッセージ72、74、80、82、84及び86を用いる。クローンモード構成は、同一のコンテンツ92が送信され、2つのモニタ又はディスプレイ装置に表示される構成である。拡張デスクトップは、異なる画像94、96が両方のモニタに示される代替のデュアルディスプレイ構成である。図8に示されるように、複数のソース、つまりソース198及びソース2100が提示されるとき、各ソースは、重複する経路で同時に、同一のストリーム識別子を有する例1の場合ADD_STREAMメッセージを発行してもよい。この場合、これらの新たなストリームのための重複する経路上にあるコンセントレータブランチ装置102は、1つのソース本例ではソース1宛にADD_STREAMメッセージを送信するだけであり、他をブロックする。つまり、1つの新たなストリームのみが一度に追加できる。ブロックされないソースのメッセージがデータチャネルを伝達した後に、更なるADD_STREAMメッセージがブロックされたソースのために伝達される。ブランチ装置104に複数の入力ポートが存在する場合、次に利用可能なストリーム識別子が割り当てられ、ブランチ装置は、自身の出力ストリーム識別子及びポート番号に対する入力ストリーム識別子及びポート番号を自身のマッピングテーブル108に記憶する。ある使用例として、新たなストリームが追加されてもよい。コンセントレータブランチ装置は、アクティブでない識別子を有するストリーム追加メッセージを知ったとき、新たなエントリを自身のマッピングテーブルに追加する。必要ならば、コンセントレータブランチ装置は、該ストリームのための新たな出力識別子を生成し、ADD_STREAMメッセージを伝達する間、該出力識別子を使用する。コンセントレータブランチ装置は、この識別子のための宛先アドレスを自身のマッピングテーブルに追加してもよい。別の使用例は、既存ストリームの拡張である。同一のソース装置が、別のADD_STREAMメッセージを通じて既にアクティブなストリームに第2のシンクを追加する場合、コンセントレータブランチ装置は、新たなエントリを自身のマッピングテーブルに追加しない。何故なら、コンセントレータブランチ装置が既に作成したマッピングは、依然として有効であるからである。しかしながら、コンセントレータは、自身の入力識別子への第2の宛先アドレスを自身のマッピングテーブルに追加する。更に別の使用例は、ストリームからのシンクの除去である。コンセントレータは、アクティブな識別子のシンクのアドレスを有するストリーム削除メッセージを受信したとき、宛先装置のリストから削除するためにシンクのアドレスをマーク付けする。次に、コンセントレータは、ストリーム削除確認応答メッセージをシンク装置から受信したとき、マッピングテーブルを用いて該メッセージをソースへ返し、ソースにより認識されるべき識別子を変更する。次に、コンセントレータは、該ストリームのためのシンクのアドレスを自身のマッピングテーブルから削除する。その識別子を有するストリームを受信する最後のシンクであった場合、コンセントレータは、自身のマッピングテーブルからエントリを削除する。その他の場合、その識別子を有するストリームを消費する少なくとも1つのシンクが存在する場合、マッピングテーブル内のエントリは削除されない。図9を参照すると、上述のバインディングを実施する一実施形態によるシーケンス110が示される。このシーケンスはソフトウェア、ハードウェア又はファームウェアで実施されてもよい。ソフトウェアの実施形態では、シーケンスは、ブランチ装置34の図3に示されるプロセッサ36のようなプロセッサにより実行される命令により実施されてもよい。このような場合、シーケンスは、記憶装置42に格納されてもよい。最初に、ブロック112に示されるように、ブランチ装置は、ADD_STREAMメッセージを受信する。ブロック114に示されるように、ブランチ装置は、該メッセージからのSTREAM_ID及び入力ポートを自身のマッピングテーブルに格納する。次に、ブロック116に示されるように、ブランチ装置は、入力STREAM_IDを出力STREAM_IDにマッピングする。ブロック118に示されるように、ブランチ装置は、出力STREAM_ID及び出力ポート番号を自身のマッピングテーブルに格納する。次に、ブロック120に示されるように、ブランチ装置はメッセージを転送する。最後に、ブロック122に示されるように、メッセージの配信が成功した場合、確認応答メッセージが下流装置から受信され、ブランチ装置は確認応答メッセージを上流へ転送する。幾つかの実施形態では、図10に示されるメッセージを送るフレームワーク124は、経路に沿った全ての装置による動作又は宛先装置のみによる動作を可能にしうる。メッセージは識別子を有し、新たな識別子は、新たなメッセージが定められる度に割り当てられる。メッセージを定めることは、経路メッセージか宛先メッセージかを決定することを含む。経路メッセージは、動作が実行される方向に依存して2種類ある。シンクへ向かう下り方向の場合、下り動作経路メッセージである。ソース装置へ向かう上り方向の場合、上り動作経路メッセージである。メッセージは、トポロジ内の任意の装置により開始されてもよい。各メッセージは、宛先アドレス及び関連経路情報を有する。図10に示されるメッセージを送るフレームワーク124は、ソフトウェア、ハードウェア又はファームウェアで実施されてもよい。例えば、フレームワーク124は、例えばブランチ装置又はシンク装置であってよい装置34内の、図3に示された記憶装置42のようなコンピュータ可読媒体に格納された命令の形式のソフトウェアで実施されてもよい。一実施形態によると、図10に示されるシーケンスは、ブロック126に示されるように、上流装置からメッセージを受信することにより開始する。メッセージを受信する装置は、2つの例として、ブランチ装置又はシンク装置であってもよい。ブロック128に示されるように、受信する装置は、最終的な宛先か否かに拘わらず、メッセージ定義を得る。次に、菱形130で、装置は、上り動作メッセージがメッセージ定義により示されるか否かを決定するために調べる。上り動作メッセージが示される場合、ブロック132に示されるように、装置は、該メッセージを受信すると、該メッセージ内で要求された動作を実行する。その他の場合、上り動作メッセージでない場合、菱形134でのチェックは、下り動作メッセージか否かを決定する。下り動作メッセージの場合、ブロック136に示されるように、メッセージの受信とは対照的に、確認応答に対して動作が実行される。反対に、下り動作メッセージでない場合、菱形138で決定されるように宛先メッセージの場合、ブロック140に示されるようにメッセージを受信する装置が最終的な宛先である場合にのみ、動作が実行される。メッセージを送るフレームワークは、接続されたオーディオビジュアルソース、ブランチ及びシンク装置のポイントツーポイントトポロジ内の特定の経路上で、装置に協調した動作を実行させる。このフレームワークは、トポロジの発見、アドレス生成、ルーティング、バインディング及びストリーム管理、資源管理及び電力管理を含む種々の動作のために用いられうる。図11に示されるように、下り動作メッセージは、次のように動作する。メッセージの送信に先立ち、ソース110は、必要な任意のメッセージ固有の動作119を実行する。メッセージ112は、ソースの動作が成功した場合にのみ送信される。ソース装置は、アドレス/経路情報に基づき決定されたように、メッセージをダウンストリームポートで送信することにより、該メッセージを宛先装置へ送信する。メッセージを受信する各ブランチ装置114若しくは116、又はシンク装置118は、該メッセージ種類により要求される動作119を実行する。宛先例えば、シンク118で動作の完了に成功すると、宛先は、確認応答ACK120で応答する。この確認応答は、ソースに返送される。図12に示されるように、上り動作メッセージ112は、次のように動作する。ここで、動作119は、確認応答120の一部として行われる。図13に示されるように、宛先メッセージは動作する。動作119は、宛先、本例ではシンク118によってのみ行われる。経路内の他の装置は、メッセージ及び確認応答を単に転送する。図14に、経路上の全てのリンクをトレーニングする経路トレーニングのための下り動作メッセージの使用が示される。図13で、各装置における動作119はリンクトレーニングである。使用されるメッセージはTRAIN_LINKS_ON_PATHであるが、如何なる他のメッセージも用いられうる。図13で、メッセージはブランチ116へ向けられる。図15は、上り動作メッセージとして実施されるときの、TRAIN_LINKS_ON_PATHのメッセージシーケンス図である。ここで、全ての動作119は、確認応答120の一部として生じる。インタフェース固有のフレームワークは、異なる経路を通じてエニュメレートされた機能が同一の装置の一部であることを、ソース装置に決定させてもよい。DisplayPort規格は、インタフェースの例である。エニュメレーションのための異なる経路は、a異なるインタフェース種類を特徴付ける経路、又はb同一のインタフェース種類の中の単に異なる経路、でありうる。フレームワークは、Microsoft登録商標Windows登録商標及びユニバーサルシリアルバスUSBのような他の技術の対応するコンテナ識別子と関連して装置を使用させ、接続された装置のために機能中心のユーザインタフェースというより装置中心のユーザインタフェースを実現させる。フレームワークは、DisplayPortの場合にはDisplayPortコンフィグレーションデータDPCDでありうる一式のcontainer_IDと通じて公表されるレジスタ16種類のグローバル一意識別子GUIDを有してもよい。DPCDは、基本的に、状態チェック、コマンド通信、及び割り込みの状況を提供するために用いられる一式のレジスタである。container_IDレジスタは、ブランチ装置、複合シンク装置及び複数のトランスポートを有する如何なる装置でも対応されてよい。所与の数のビデオエンドポイントを有するシンク装置は、その数の拡張ディスプレイ識別データExtendedDisplayIdentificationData:EDID構造で応答することを期待される。EDIDデータ構造は、ソースに、モニタの能力に関して教える。EDIDは、VESA規格である。シンク装置が統合ユニバーサルシリアルバスUSB又はハブ装置を有するとき、シンクのグローバル一意識別子は、該USB装置又はハブのコンテナ記述子内のグローバル一意識別子と一致する。装置に統合された全ての機能は、同一のグローバル一意識別子が通過するインタフェース種類に関係なく、該同一のグローバル一意識別子を通知アドバタイズする。複数のビデオエンドポイントを有するシンクでは、各アドレスからのcontainer_IDレジスタは、同一のグローバル一意識別子を返す。トポロジ内の各装置では、ソース装置は、トポロジ発見処理の一部としてグローバル一意識別子を読み出す。装置がグローバル一意識別子を有する場合、ソース装置は、該グローバル一意識別子を読み出し、同一の装置が複数の経路又は複数のインタフェースを通じてアクセスされているかどうかを決定する。その他の場合、ソース装置は、特定のインタフェース特定手段を通じて、同一の物理装置内にある機能を推測する。インタフェースがDisplayPort規格である場合、これは、下流装置の相対アドレスRADに基づきうる。装置のトポロジに直面するとき、通信を開始する各装置は、ネットワーク内で有効な宛先装置のアドレスを生成する必要がある。このアドレスは、相対アドレスと称される。何故なら、各装置により生成されたアドレスは有効であるが、同一の宛先のために別のソースで生成されたものとは異なりうるからである。次に、ソースは各相対アドレスからEDIDを読み出す。グローバル一意識別子が生成され、EDIDを通じて識別されるように装置に関連付けられる。この生成されたグローバル一意識別子は、オペレーティングシステム内のコンテナ識別子のフレームワークと共に用いられる。従って、幾つかの実施形態では、EDIDは、ユニークなシリアル番号を有する。これが有効でない場合、複数のEDIDに関連付けられている同一のグローバル一意識別子が変更され、結果として粗悪なユーザ経験をもたらす。図16に、ソース装置とブランチ装置との間の複数の接続が示される。本例では、シンクへの2つの経路が存在するので、ソースは、該シンク装置のために2つのアドレスを生成する。ソースは、両方の経路を通じて同一のグローバル一意識別子を読み出すので、両方の経路が同一のシンク装置を読み出すと推測できる。グローバル一意識別子が失われてしまうと、ソースは同一であってよい両方の経路からEDIDを読み出し、グローバル一意識別子を生成し、そして該グローバル一意識別子をシンク装置に関連付ける。この識別子は、次に、オペレーティングシステムに返される。図17は、2つのビデオエンドポイントを有する例を示す。このソースのシーケンスは以下の通りである。ソースは、再び、シンク装置内の各エンドポイントに対して1つずつ、2つのアドレスを生成する。ソースは、各ビデオエンドポイントのアドレスからレジスタのコンテナ識別子を読み出す。シンクは自身の中に2つのインタフェースを有するので、フレームワークは、グローバル一意識別子がシンク装置内に存在することを要求し、グローバル一意識別子が両方のインタフェースで同一であることを要求する。ソースは、グローバル一意識別子が同一であることを検出し、2つのビデオエンドポイントが同一の物理装置の一部であると推定する。図18を参照すると、一実施形態によると、シーケンス150は、図3に示された形式でソースにより実施されてもよい。幾つかの実施形態では、図18に示されるシーケンスは、ソフトウェア、ハードウェア又はファームウェアで実施されてもよい。ソフトウェアの実施形態では、シーケンスは、プロセッサ36のようなプロセッサにより実行され記憶装置42に格納される命令により実施されてもよい。初期エニュメレーション又はトポロジ発見段階中に、識別子は、トポロジ内の装置毎に読み出されるブロック152。言い換えると、ソースは、トポロジ内の装置の識別子を得る。該識別子は、本願明細書で上述した如何なる識別子であってもよい。次に、ブロック154に示されるように、ソースは、経路を介してソースの下流の宛先へのコネクションを確立する。次に、ブロック156に示されるように、ソースは、コネクション経路内の装置の識別子を比較する。ブロック158で決定されるように、識別子が一致する場合、ソースは、一致する識別子を有する経路装置が同一のブランチ又はシンク装置の一部であると結論づける。従って、幾つかの実施形態では、2つの装置が同一の識別子を有するときに生じうる不明確さは、容易に対処されうる。本願明細書を通じて一実施形態又はある実施形態のような記載は、実施形態に関連して記載された特定の機能、構造、又は特徴が本発明に包含される少なくとも1つの実施形態に含まれることを意味する。従って、一実施形態又はある実施形態のような記載は、必ずしも同一の実施形態を参照しない。更に、特定の機能、構造又は特徴は、図示された特定の実施形態以外の他の適切な形式で設けられてもよい。また、全てのこのような形式は、本願の特許請求の範囲内に包含されうる。本発明は限られた数の実施形態に関して説明されたが、当業者はこれらの実施形態の多数の変形及び変更を理解するだろう。このような全ての代替、変更及び変形は本発明の真の精神と範囲に包含される。