JP2009506601A - メディア適応を備えたメディアセッションの確立 - Google Patents

メディア適応を備えたメディアセッションの確立 Download PDF

Info

Publication number
JP2009506601A
JP2009506601A JP2008527340A JP2008527340A JP2009506601A JP 2009506601 A JP2009506601 A JP 2009506601A JP 2008527340 A JP2008527340 A JP 2008527340A JP 2008527340 A JP2008527340 A JP 2008527340A JP 2009506601 A JP2009506601 A JP 2009506601A
Authority
JP
Japan
Prior art keywords
media
terminal
nsis
session
router
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2008527340A
Other languages
English (en)
Other versions
JP4746102B2 (ja
Inventor
ホセ・ルイス・レイ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Publication of JP2009506601A publication Critical patent/JP2009506601A/ja
Application granted granted Critical
Publication of JP4746102B2 publication Critical patent/JP4746102B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)

Abstract

本発明は、要求中の端末に対してパケット交換型通信ネットワークを介して端末間で確立されるメディアセッションのメディアストリームのメディアフォーマットを変換するために、メディアフォーマット適応リソースを記録するための方法および端末に関する。本発明はさらに、端末間で確立されるメディアセッションのメディアストリームのメディアフォーマットを変換するメディアフォーマット適応リソースを記録する方法およびＮＳＩＳルータに関する。端末がメディア適応を利用してメディアセッションを確立することを可能にするために、本発明は、ＮＳＩＳ（Ｎｅｘｔ Ｓｔｅｐ Ｉｎ Ｓｉｇｎａｌｉｎｇ）に基づくシグナリングフレームワークを提供し、メディアデータがセッションに関与している端末の中でメディアトランスポートプロトコルを利用して移送されるメディアデータパスにおいて（およびこのメディアデータパスから離れて）メディア適応リソースの検出および確保を容易にする。

Description

本発明は、要求中の端末に対してパケット交換型通信ネットワークを介して端末間で確立されるメディアセッションのメディアストリームのメディアフォーマットを変換するために、メディアフォーマット適応リソースを記録するための方法および端末に関する。本発明はさらに、端末間で確立されるメディアセッションのメディアストリームのメディアフォーマットを変換するために、メディアフォーマット適応リソースを記録するための方法およびＮＳＩＳルータに関する。
ＮＳＩＳフレームワーク
ＮＳＩＳは、ネクストステップインシグナリング（Ｎｅｘｔ Ｓｔｅｐｓ ｉｎ Ｓｉｇｎａｌｉｎｇ）の略語である。ＮＳＩＳは、シグナリングフレームワークのためのモジュール手法を定義することを目的としており、ＮＳＩＳトランスポートレベルプロトコル（ＮＴＬＰ：ＮＳＩＳ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｐｒｏｔｏｃｏｌ）と一般に呼ばれるシグナリングメッセージを搬送するためのプロトコルと、ＮＳＩＳシグナリング層プロトコル（ＮＳＬＰ：ＮＳＩＳ Ｓｉｇｎａｌｉｎｇ Ｌａｙｅｒ Ｐｒｏｔｏｃｏｌ）と一般に呼ばれるシグナリングアプリケーションのそれぞれに関して指定されなければならない別のプロトコルと、からなる（ＲＦＣ４０８０、「Ｎｅｘｔ Ｓｔｅｐｓ ｉｎ Ｓｉｇｎａｌｉｎｇ（ＮＳＩＳ）：Ｆｒａｍｅｗｏｒｋ」参照、これは、参照によって本願明細書に援用されるものとし、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇで利用可能である）。
ＮＴＬＰプロトコルに関する一例は、シュルツリン（Ｓｃｈｕｌｚｒｉｎｎｅ）らによるインターネットドラフト「ＧＩＭＰＳ：Ｇｅｎｅｒａｌ Ｉｎｔｅｒｎｅｔ Ｍｅｓｓａｇｉｎｇ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｓｉｇｎａｌｉｎｇ」（ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ｎｔｌｐ−０７．ｔｘｔ）に明記されているＧＩＭＰＳプロトコルであり、これは、参照によって本願明細書に援用されるものとし、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇで利用可能である。
ＮＳＬＰプロトコルの例は、マナー（Ｍａｎｎｅｒ）らによるインターネットドラフト「ＮＳＬＰ ｆｏｒ Ｑｕａｌｉｔｙ−ｏｆ−Ｓｅｒｖｉｃｅ ｓｉｇｎａｌｉｎｇ」（ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ｑｏｓ−ｎｓｌｐ−０７．ｔｘｔ）またはスティマリング（Ｓｔｉｅｍｅｒｌｉｎｇ）らによるインターネットドラフト「ＮＡＴ／Ｆｉｒｅｗａｌｌ ＮＳＩＳ Ｓｉｇｎａｌｉｎｇ Ｌａｙｅｒ Ｐｒｏｔｏｃｏｌ（ＮＳＬＰ）」（ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ｎｓｌｐ−ｎａｔｆｗ−０７）に明記されている。（いずれの文書も、参照によって本願明細書に援用されるものとし、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇで利用可能である）。
ＮＳＩＳ ＱｏＳ ＮＳＬＰプロトコルは、インターネットにおけるＱｏＳ確保に関する長期にわたる問題を扱っており、ＮＡＴ／ＦＷトラバーサルコンフィギュレーションシグナリングを用いて、それを拡張している。したがって、本発明の以下の詳細な説明から明白となるように、メディアデリバリがネットワークのＱｏＳ機能（帯域幅、遅延、．．．）と、オーバレイノードにおけるネットワーク側の処理（メディア適応）機能の両方に適合しなければならない場合には、ＱｏＳ ＮＳＬＰは、特に関連性がある可能性がある。
ＮＳＬＰデータオブジェクトは、ＧＩＭＰＳメッセージなどのＮＴＬＰメッセージのペイロードであってもよい。ＧＩＭＰＳ ＱＵＥＲＹメッセージの基本構造は、以下の通りである。
GIMPS-Query = Common-Header
Message-Routing-Information
Session-Identification
Network-Layer-Information
Query-Cookie
[ Stack-Proposal Stack-Configuration-Data ]
[ NSLP-Data ]
一般的なマルチメディアシナリオおよびその欠点
一般的なマルチメディアシナリオでは、第１のステップとして、セッションに関与している通信ピアの機能（サポートされるコーデック、有効なリンク、有効なバッファリング機能など）を調べるために、シグナリング交換が要求される。現在、対話型のシナリオの場合には、セッション開始プロトコル（ＳＩＰ：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）（ＲＦＣ３２６１、「ＳＩＰ： Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ」参照、これは参照によって本願明細書に援用されるものとする）は通常、ＲＦＣ ３２６４、「Ａｎ Ｏｆｆｅｒ／Ａｎｓｗｅｒ Ｍｏｄｅｌ ｗｉｔｈ ｔｈｅ Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＤＰ）」（参照によって本願明細書に援用されるものとする）に明記されているように、オファー／アンサーモデル（Ｏｆｆｅｒ／Ａｎｓｗｅｒ Ｍｏｄｅｌ）により、ＳＤＰ用の機能交換意味論と共に用いられる。ストリーミングサービスの場合には、機能交換は、ＲＴＳＰ（ＲＦＣ ２３２６、「Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ（ＲＴＳＰ）」、これは参照によって本願明細書に援用されるものとする）またはＳＤＰを用いて行われてもよい。
ＳＩＰは、照会／応答プロトコルであり、確立されるマルチメディアセッションの詳細のほか、エンドホストの機能情報の交換を協議することができる。ＳＤＰは、通信ピアのパラメータ、フロー数、接続の詳細などを表現するためのプロトコルである。ＳＤＰはまた、セッション接続またはコーデックの機能を表現し、詳細を協議することも可能である。
両方の通信当事者（エンドホスト）が共通の機能を有する場合には、マルチメディアセッションを直接的に確立することができる。しかし、エンドホストのメディア機能に不適合がある場合には、セッションは確立されない。
セッションが確立されることができるか、または許容されることができる状況下で、サービスを要求するユーザが対応するノード（別のユーザ、サービスプロバイダなど）と通信することができない場合には、セッションは通常、確立されることはできない。セッションにおいて用いられるメディアストリームのフォーマットにおける不適合を克服することができるネットワークにおいて利用可能なメディア適応リソースがあるとしても、必要なメディア適応を決定して記述するための方法論は見当たらず、適切なメディア適応リソースを検索して確保することが可能な手順のフレームワークもない。
本発明の目的は、端末の機能に不適合が検出される場合に、メディアセッションに関与している端末にメディア適応リソースの利用を可能にするシグナリングフレームワークを提供することである。
本発明の目的は、独立請求項の主題によって克服される。好都合な実施形態は、従属請求項に対する主題である。
本発明の一実施形態は、メディアセッションに関与する端末の動作に関する。この実施形態によれば、パケット交換型通信ネットワークを介して第１の端末と第２の端末との間に少なくとも１つのメディアストリームを備えるメディアセッションを確立するための方法が、提供される。本発明のすべての実施形態において、少なくとも１つのメディアストリームが、メディアトランスポートプロトコルを用いて通信される。
第１の端末は、セッションを開始するために、セッション管理プロトコルを用いて、第２の端末にセットアップメッセージを送信する。このセットアップメッセージは、メディアフォーマット［０］を提示するセッション記述を含んでもよく、任意に、メディアセッションにおいて通信される各メディアストリームに関する対応するパラメータおよび属性を含んでもよい。
第１の端末はさらに、セッション管理プロトコルを用いて、セットアップメッセージに対する応答を受信する。この応答は、メディアセッションの少なくとも１つのメディアストリームに関する代替メディアフォーマットを提示する修正セッション記述を含んでもよく、この場合には、第２の端末によってサポートされていないメディアフォーマットが、第１の端末によって送信されるセットアップメッセージに含まれるセッション記述に提示されている。
第１の端末は、それぞれの代替メディアフォーマットが第１の端末によってサポートされる場合には、セットアップメッセージに対する応答に含まれるセッション記述において、各代替メディアフォーマットに関する決定に進む。これが当てはまらない場合には、すなわち、修正セッション記述に提示されたすべての代替メディアフォーマットが、第１の端末によってサポートされるとは限らない場合には、第１の端末は、第１の端末によってサポートされていない各代替メディアフォーマットに関して、ネクストステップインシグナリング（Ｎｅｘｔ Ｓｔｅｐ ｉｎ Ｓｉｇｎａｌｉｎｇ）ＮＳＩＳフレームワークを用いて、少なくとも１つのＮＳＩＳルータを検出し、（それぞれの）検出されたＮＳＩＳルータは、セットアップメッセージにおけるセッション記述において第１の端末によって提示されるメディアフォーマットから、セットアップメッセージにおける応答のセッション記述において第２の端末によって提示されるそれぞれの代替メディアフォーマットに、メディアストリームのパケットデータを変換することができる。
第１の端末によってサポートされていない各代替メディアフォーマットに関して、少なくとも１つのＮＳＩＳルータが、検出される場合には、第１の端末は、提示されたメディアフォーマットにおけるパケットデータを、第１の端末によってサポートされていないそれぞれの代替メディアフォーマットに関して検出された少なくとも１つのＮＳＩＳルータで、それぞれの代替メディアフォーマットに変換するためのリソースの確保に進む。メディアフォーマット変換のためのリソースを首尾よく確保したときには、メディアセッションが開始される。メディアセッションの少なくとも１つのメディアストリームのパケットデータが、メディアトランスポートプロトコルを用いて、第１の端末によってサポートされていない各代替メディアフォーマットに関して、メディアフォーマット変換のためのリソースが確保されている少なくとも１つのＮＳＩＳルータを介して、第１の端末から第２の端末に提供される。
他の実施形態によれば、ＮＳＩＳシグナリングフレームワークを用いた少なくとも１つのＮＳＩＳルータの検出は、以下の機構によって実行されてもよい。第１の端末は、パケット交換型ネットワークを介した第１の端末から第２の端末へのメディアセッションの少なくとも１つのストリームのパケットデータのパスに沿って、ＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて照会メッセージを送信する。メッセージは、セットアップメッセージに対する応答におけるセッション記述において、第１の端末によってサポートされていない提示されたメディアフォーマットから、第２の端末によって提示されたそれぞれの代替メディアフォーマットに、メディアセッションのストリームのパケットデータを変換するための機能に関する照会メッセージを受信する各ＮＳＩＳルータに照会する。照会メッセージに対する応答において、第１の端末は、ＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、提示されたメディアフォーマットからそれぞれの代替のメディアフォーマットに、メディアセッションのストリームのパケットデータを交換することができる第１の端末から第２の端末へのパケットデータのパスにおける少なくとも１つのＮＳＩＳルータを表す応答メッセージを受信する。ＮＳＩＳルータが照会されたメディアフォーマット変換を行うことができない場合には、応答メッセージにおいて表されるＮＳＩＳルータはない。
他の変形において、照会メッセージはまた、第１の端末によってサポートされていない提示されたメディアフォーマットから中間メディアフォーマットに、または中間メディアフォーマットから別の中間メディアフォーマットまたはメディアセッションのそれぞれのメディアストリームに関するそれぞれの代替メディアフォーマットに、メディアセッションのメディアストリームのパケットデータを変換する機能に関する照会メッセージを受信する各ＮＳＩＳルータに照会する。したがって、提示されたメディアフォーマットから第１の端末によってサポートされていない代替メディアフォーマットへのメディアデータの直接変換が照会されることができるだけでなく、適切に「組み合わせられた」場合に、提示されたメディアフォーマットから第１の端末によってサポートされていない代替メディアフォーマットへのメディアデータの変換を生じうる適応リソースも照会されることができる。
したがって、応答メッセージはさらに、第１の端末から第２の端末へのパスにおける少なくとも１つのＮＳＩＳルータが、提示されたメディアフォーマットから中間メディアフォーマットに、または中間メディアフォーマットから別の中間メディアフォーマットまたはそれぞれの代替のメディアフォーマットに、メディアセッションのメディアストリームのパケットデータを変換することができるかどうかを示してもよい。
他の実施形態によれば、ＮＳＩＳルータにおけるパケットデータを変換するためのリソースの確保は、以下のように行われてもよい。第１の端末は、提示されたメディアフォーマットから第２の端末によってセットアップメッセージに対する応答におけるセッション記述によって提示される代替メディアフォーマットに、メディアセッションのストリームのパケットデータを変換するためのメディア適応リソースの確保を要求するリソース確保要求メッセージを、ＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、少なくとも１つのＮＳＩＳルータに送信する。それに対する応答において、第１の端末は、ＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、ＮＳＩＳルータが変換用のリソースを確保したかどうかを表す応答メッセージを受信する。
本発明の他の実施形態において、セットアップメッセージに含まれるセッション記述はさらに、第２の端末がセッション記述においてメディアストリームの提示されたメディアフォーマットをサポートしない場合には、メディアセッションの少なくともメディアストリームに関して、第１の端末がメディアフォーマット変換を自発的に行うかどうかを示す。
本発明の別の実施形態において、セットアップメッセージに含まれて送信されるセッション記述はさらに、第２の端末に対し、メディアセッションのそれぞれのメディアストリームの受信が、メディアセッションの確立のために必須であるかどうかを示す。
この実施形態の変形において、セットアップメッセージに含まれて送信されるセッション記述はさらに、第２の端末が提示されたメディアフォーマットをサポートしない場合には、メディアセッションのメディアストリームに関する別のメディアフォーマットへの提示されたメディアフォーマットの変換が、メディアセッションの確立のために任意であるか、または必須であるかを示す。
さらに、本発明の別の実施形態において、それぞれのメディアストリームに関して提示されたフォーマットが第２の端末によってサポートされない場合には、修正セッション記述は、第２の端末が、代替メディアフォーマットにおけるメディアストリームのパケットデータを提示されたメディアフォーマットにおけるメディアストリームのパケットデータに変換するために、少なくとも１つのＮＳＩＳルータにおいてリソースを自発的に検出して確保するかどうかを示す。もしそうであるならば、修正セッション記述はまた、セットアップメッセージに対する応答の送信時に、第２の端末がメディアフォーマット変換リソースの検出および確保を開始したことを示す。
本発明の別の実施形態によれば、第１の端末によって送受信されるサービス記述は、セッションに関連するサービスの品質制約条件を含んでもよく、セットアップメッセージに対する応答における修正セッション記述は、セットアップメッセージのセッション記述に含まれるサービスの品質制約条件に対する代替のサービスの品質制約条件を提示することを含む。
後者の場合には、本発明の別の実施形態は、第１の端末が、代替のサービスの品質（ＱｏＳ）制約条件が、第１の端末のユーザに関して許容可能であるかどうかを決定することを提示する。これが当てはまる場合には、第１の端末は、第２の端末のセッション記述において示された代替のサービスの品質制約条件に基づき、パケット交換型通信ネットワークを介した第１の端末から第２の端末へのパスに沿ってリソースを確保してもよく、メディアセッションの少なくとも１つのメディアストリームのパケットデータは、上記のパスに沿って第１の端末から第２の端末に供給される。
本発明の別の実施形態において、セットアップメッセージに対する応答において受信されたセッション記述において提示された各代替メディアフォーマットに関して、検出されるＮＳＩＳルータがない場合、それぞれのＮＳＩＳルータでメディアフォーマットを変換するために確保されることができるリソースが十分でない場合、またはパケット交換型通信ネットワークを介したパスに沿って、セットアップメッセージに対する応答において受信されたセッション記述において提示された代替のサービスの品質制約条件を満たすために確保されることができるリソースが十分でない場合には、メディアセッションは、中断される。
本発明の別の実施形態によれば、メディアセッションの開始は、メディアセッションのそれぞれのストリームに関する適応ノードにおいてメディアフォーマット変換を記述する更新されたセッション記述を含む更新メッセージを第１の端末によって第２の端末に送信するステップを含んでもよく、この場合には代替メディアフォーマットが、パケット交換型通信ネットワークを介して第１の端末から第２の端末にパスに沿って提示された。メディアセッションの少なくとも１つのメディアストリームのパケットデータは、上記のパスに沿って第１の端末から第２の端末に供給される。
この実施形態の変形において、送信された更新メッセージはさらに、第１の端末から第２の端末へのパスに沿って、第１の端末によって確保されるリソースに関する情報を含む。
他の変形によれば、第１の端末は、メディアセッションのそれぞれのストリームに関する適応ノードにおいてメディアフォーマット変換を記述する更新されたセッション記述を含む更新メッセージを第２の端末から受信してもよく、この場合には代替メディアフォーマットが、パケット交換型通信ネットワークを介して第２の端末から第１の端末にパスに沿って提示され、メディアセッションの少なくとも１つのメディアストリームのパケットデータは、上記のパスに沿って第２の端末から第１の端末に供給される。
実施形態のさらに他の変形において、受信された更新メッセージはさらに、第２の端末から第１の端末へのパスに沿って、第１の端末によって確保されるリソースに関する情報を含む。
メディアトランスポートプロトコルは、たとえば、リアルタイムトランスポートプロトコル（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）ＲＴＰであってもよく、セッション記述は、セッション記述プロトコル（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ＳＤＰフォーマットまたはリアルタイムストリーミングプロトコル（Ｒｅａｌ−Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）ＲＴＳＰフォーマットで、提供される。
本発明の別の実施形態によれば、セッション管理プロトコルは、セッション開始プロトコルＳＩＰであり、セットアップメッセージは、ＳＩＰプロトコルの招待（Ｉｎｖｉｔｅ）メッセージである。したがって、セットアップメッセージに対する応答は、第２の端末がメディアフォーマット変換リソースの検出および確保のための第１の端末の意思を承認することと、第２の端末が第１の端末によってサポートされていない代替メディアフォーマットにおけるメディアセッションのメディアストリームを第１の端末によってサポートされるそれぞれの提示されたメディアフォーマットに変換するために、少なくともＮＳＩＳルータでメディアフォーマット変換のためのリソースの検出および確保を開始したことを第１の端末に示すＳＩＰプロトコルのセッション進行（Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓ）メッセージである。
セッション進行メッセージに含まれるセッション記述において提示された代替メディアフォーマットが、第１の端末によってサポートされていない場合には、第１の端末は、第１の端末が、セッション記述において提示された各代替メディアフォーマットに関して、ＮＳＩＳルータでメディアフォーマット変換のためのリソースの検出および確保を開始したことを第２の端末に示す暫定応答承認（Ｐｒｏｖｉｓｉｏｎａｌ Ｒｅｓｐｏｎｓｅ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージを送信してもよく、メディアフォーマット変換のためのリソースが第２の端末によって確保された適応ノードが検出され、代替メディアフォーマットから第１の端末によって提示されたメディアフォーマットに、メディアセッションのメディアストリームのパケットデータを変換するように構成される。さらに、第１の端末は、この暫定応答承認メッセージの応答における暫定応答承認を受信してもよい。
本発明の別の態様は、メディア適応リソースの検出をサポートする動作ＮＳＩＳルータである。本発明の別の実施形態によれば、要求中の端末に対してパケット交換型通信ネットワークを介して端末間で確立されるメディアセッションのメディアストリームのメディアフォーマットを変換するためのメディアフォーマット適応リソースを記録するための方法が提供される。メディアトランスポートプロトコルによってカプセル化されたセッションのメディアストリームのパケットデータが、要求中の端末から確立されるメディアセッションに関与している宛先端末にパケット交換型ネットワークを介して移送されるメディアデータパスにおけるＮＳＩＳルータによって行われる方法ステップは、照会メッセージは、パケット交換型ネットワークを介してＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、オンパス（ｏｎ−ｐａｔｈ）ＮＳＩＳルータによって受信されてもよい。照会メッセージは、第１のメディアフォーマットから第２の異なるメディアフォーマットに、メディアセッションのストリームのパケットデータを変換するための機能に関する照会メッセージを受信するＮＳＩＳルータに照会する。
受信された照会メッセージに対する応答において、オンパスＮＳＩＳルータは、ＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、要求中の端末に対して、ＮＳＩＳルータが、第１のメディアフォーマットから第２のメディアフォーマットに、メディアセッションのストリームのパケットデータを変換する機能を有するかどうかを示す応答メッセージを送信する。
メディアデータパスのオンパスＮＳＩＳルータの位置に応じて、照会メッセージが照会端末から直接的に受信され、照会中の端末または隣接するＮＳＩＳルータにＮＴＬＰ機能性を提供するそのプロキシを形成することができることを留意すべきである。したがって、照会メッセージが受信されたという応答メッセージは、それぞれのエンティティに返される。
実施形態の変形において、照会メッセージはさらに、第１のメディアフォーマットから中間メディアフォーマットに、または中間メディアフォーマットから別の中間メディアフォーマットまたは第２の代替のメディアフォーマットに、メディアセッションのメディアストリームのパケットデータを変換するための機能について照会する。したがって、応答メッセージはさらに、ＮＳＩＳルータが、照会されたメディアフォーマット変換の少なくとも１つを提供することができるかどうかを示す。
本発明の他の実施形態において、照会メッセージは、適応機能が照会される１つまたは複数のメディアフォーマット変換を示すメディアフォーマット適応記述を含む。
本発明の別の実施形態において、オンパスＮＳＩＳルータは、ＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、リソース確保要求メッセージを受信してもよく、このメッセージは、リソースが割り当てられるように要求されるＮＳＩＳルータによって行われるメディアフォーマット変換の記述を含む。オンパスＮＳＩＳルータは、記述によって示されるメディアフォーマット変換のためのリソースが、ＮＳＩＳルータで割り当てられることができるかどうかを決定し、そうである場合には、変換のためのリソースを確保してもよい。したがって、オンパスＮＳＩＳルータによって送信される応答メッセージは、ＮＳＩＳルータが変換のためにリソースを（首尾よく）確保したかどうかを示す。
本発明の別の実施形態において、オンパスＮＳＩＳルータは、メディアデータパスに位置する別のＮＳＩＳルータで確保されるメディアフォーマット変換の記述を含むＮＴＬＰを用いて、リソース確保要求メッセージを受信してもよい。リソース確保要求メッセージを処理するＮＳＩＳルータは、メディアデータパスに位置する他のＮＳＩＳルータに対するトンネルを確立し、メディアセッションの開始時に、変換のためにメディアデータパスに位置するＮＳＩＳルータに変換されるメディアストリームのパケットデータを転送する。
本発明の他の実施形態において、オンパスＮＳＩＳルータは、ＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、メディアデータパスに位置しないＮＳＩＳルータで、確保されるメディアフォーマット変換の記述を含むリソース確保要求メッセージを受信する。オンパスＮＳＩＳルータは、リソース確保要求メッセージをメディアデータパスに位置しないＮＳＩＳルータ（オフパス（ｏｆｆ−ｐａｔｈ）ＮＳＩＳルータ）に転送し、オフパスＮＳＩＳルータへのトンネルを確立する。メディアセッションの開始時に、オンパスＮＳＩＳルータは、変換のために、変換されるメディアストリームのパケットデータをオフパスＮＳＩＳルータに転送する。
本発明の別の実施形態によれば、オンパスＮＳＩＳルータは、ＮＳＩＳルータで利用可能なメディアフォーマット適応機能の記述を照会メッセージに追加し、追加した記述を含む受信した照会メッセージを次のＮＳＩＳルータ、メディアデータパスまたは宛先端末に転送する。転送された照会メッセージに対する応答において、オンパスＮＳＩＳルータは、メディアデータパスにおける次のＮＳＩＳルータまたは宛先端末から応答メッセージを受信してもよい。照会されたメディアフォーマット適応機能が利用可能である場合には、応答メッセージは、メディアデータパスに位置するＮＳＩＳルータで利用可能であるメディアフォーマット適応機能の少なくとも１つの記述を含む。さらに、照会されたメディアフォーマット適応機能が利用可能である場合には、送信された応答メッセージは、メディアデータパスに位置するＮＳＩＳルータで利用可能であるメディアフォーマット適応機能の少なくとも１つの記述を含む。
実施形態の変形において、オンパスＮＳＩＳルータはまた、照会メッセージを少なくとも１つのメディアデータパスに位置しないＮＳＩＳルータに転送し、少なくとも１つのメディアデータパスに位置しないＮＳＩＳルータから、メディアパスに位置しない少なくとも１つのＮＳＩＳルータで利用可能であるメディアデータ適応機能の記述を含む応答メッセージを受信する。
他の変形において、オンパスＮＳＩＳルートは、受信された照会メッセージをメディアデータパスにおける次のＮＳＩＳルータに転送する前に、メディアパスに位置しない少なくとも１つのＮＳＩＳルータで利用可能なメディアデータ適応機能の記述を、上記の受信された照会メッセージに追加する。
本発明の別の実施形態において、要求中の端末に対して送信される応答メッセージはさらに、メディアパスに位置するか、または位置しない少なくとも１つのＮＳＩＳルータで利用可能なメディアデータ適応機能の記述を含む。
本発明の別の実施形態によれば、パケット交換型通信ネットワークを介して端末と第２の端末との間で、少なくとも１つのメディアストリームを含むメディアセッションを確立するための端末が設けられる。端末は、セッションを開始するために、セッション管理プロトコルを用いて、セットアップメッセージを第２の端末に送信するための送信器を備え、メッセージは、メディアセッションにおいて送信されるメディアフォーマットと、各メディアストリームに関する対応するパラメータおよび属性と、を提示するセッション記述を含む。端末はまた、セッション管理プロトコルを用いて、セットアップメッセージに対する応答を受信するための受信器を備え、セットアップメッセージに対する応答は、修正セッション記述を含み、修正セッション記述は、メディアセッションの少なくとも１つのメディアストリームに関する代替メディアフォーマットを提示し、この場合には、第２の端末によってサポートされていないメディアフォーマットがセットアップメッセージに含まれるセッション記述において提示されている。
端末は、セットアップメッセージに対する応答に含まれるセッション記述において、各代替メディアフォーマットに関してそれぞれの代替メディアフォーマットが端末によってサポートされるかどうかを決定するための処理装置を備える。処理装置はさらに、それぞれの代替メディアフォーマットが端末によってサポートされていない場合には、ネクストステップインシグナリングＮＳＩＳフレームワークを用いて、各代替メディアフォーマットに関して、少なくとも１つのＮＳＩＳルータを検出するように構成される。それによって、検出されたＮＳＩＳルータは、セットアップメッセージにおけるセッション記述において、第１の端末によってサポートされるメディアフォーマットから、セットアップメッセージにおける応答のセッション記述において、第２の端末によって提示されるそれぞれの代替メディアフォーマットに、メディアストリームのパケットデータを変換することができる。
さらに、端末は、第１の端末によってサポートされていない各代替メディアフォーマットに関して、少なくとも１つのＮＳＩＳルータが検出されている場合には、第１の端末によってサポートされていないそれぞれの代替メディアフォーマットに関して検出される少なくとも１つのＮＳＩＳルータで、提示されたメディアフォーマットにおけるパケットデータをそれぞれの代替メディアフォーマットに変換するためのリソースを確保するための確保ユニットを備える。さらに、端末は、メディアフォーマット変換のためのリソースを首尾よく確保したときに、メディアセッションを開始し、メディアトランスポートプロトコルを用いて、メディアフォーマット変換のためのリソースが、端末によってサポートされていない各代替メディアフォーマットに関して確保されている少なくとも１つのＮＳＩＳルータを介して端末から第２の端末に、メディアセッションの少なくとも１つのメディアストリームのパケットデータを提供するように適合される。
本発明の別の実施形態は、上記の種々の実施形態および変形の１つに基づき、メディアセッションを確立するための方法を行うように適合される手段を備える端末を提供する。
他の実施形態は、要求中の端末に対してパケット交換型通信ネットワークを介して端末間で確立されるメディアセッションのメディアストリームのメディアフォーマットを変換するためのメディアフォーマット適応リソースを記録するために、ＮＳＩＳルータを提供する。ＮＳＩＳルータ（オンパスＮＳＩＳルータ）は、メディアトランスポートプロトコルによってカプセル化されたセッションのメディアストリームのパケットデータが、要求中の端末から確立されるメディアセッションに関与している宛先端末までパケット交換型ネットワークを介して移送されるメディアデータパスに位置する。ＮＳＩＳルータは、パケット交換型ネットワークを介してＮＴＬＰを用いて照会メッセージを受信するための受信器を備え、照会メッセージは、第１のメディアフォーマットから第２の異なるメディアフォーマットにメディアセッションのストリームのパケットデータを変換するための機能に関する照会メッセージを受信するＮＳＩＳルータに照会する。
オンパスＮＳＩＳルータはまた、受信された照会メッセージに対する応答において、ＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、要求中の端末に対して応答メッセージを送信する送信器を備え、応答メッセージは、ＮＳＩＳルータが、第１のメディアフォーマットから第２のメディアフォーマットにメディアセッションのストリームのパケットデータを変換する機能を有するかどうかを示す。
別の実施形態は、上記の種々の実施形態およびその変形の１つに基づき、メディアフォーマット適応リソースを記録するための方法を行うように適合された手段を備えるＮＳＩＳルータを提供する。
さらに、本発明の別の実施形態は、上記の種々の実施形態およびその変形の１つに基づき、端末のプロセッサによって実行されるときに、メディアセッションを確立するための方法のステップを端末に行わせる命令を格納するコンピュータ読み出し可能メディアを提供する。
本発明の別の実施形態は、上記の種々の実施形態および変形の１つによれば、オンパスＮＳＩＳルータのプロセッサによって実行されるときに、メディアフォーマット適応リソースを記録するための方法をオンパスＮＳＩＳルータに実行させる命令を格納するコンピュータ読み出し可能メディアに関連付けられる。
以下において、本発明は、添付の図および図面を参照してさらに詳細に記載される。図における類似の詳細または対応する詳細は、同一の参照符号で表記される。
本発明をよりよく理解するために、本文書で頻繁に用いられるいくつかの用語が、最初に明記される。
エンドポイントは、特定のサービスに関する要求を発行する（または処理する）ユーザまたはユーザエージェントを示す。サーバおよびクライアントは、エンドポイントであってもよい。エンドポイントはまた、ユーザエージェントおよびプロキシインスタンス、すなわちユーザの代わりに作用し、ユーザのサービス要求の詳細、機能および好みを承知しているソフトウェアエンティティであってもよい。エンドポイントの一例は、ＳＩＰユーザエージェントである。
ＮＳＩＳルータまたはプロキシは、経路指定機能の提供に加えて、パケット処理を行う可能性を有するネットワークノードを示す。パケット処理は、たとえば、メディアデータフローのトランスコーディング、メータリング、バッファリング、分割または同期であってもよい。パケット処理リソースは、メディア（フォーマット）適応リソースとも呼ばれ、ＮＳＩＳルータに必ずしも位置しなくてもよいが、それを介してアクセスされることが可能である。ＮＳＩＳルータは、ＱｏＳの根底にある基盤、すなわちＱｏＳ技術分野への入口点：ＤｉｆｆＳｅｒｖ入口ルータ、ＭＰＬＳ Ｌａｂｅｌ出口ルータなどを認識するネットワークノードと同じ場所に配置されてもよい。提案された解決策は、必要なメディア適応リソースの確保のために、ＮＳＩＳシグナリングフレームワークを用いることから、ＮＳＩＳルータまたはプロキシは、ＮＳＩＳ操作可能である。
オーバレイネットワークは、同一の仮想トポロジの一部を形成するＮＳＩＳルータ（およびプロキシ）の集合によって形成される。トポロジは、根底にある経路指定から抽出するという意味で仮想である。通常、オーバレイネットワークにおけるノードは、ＯＳＰＦ経路指定またはＲＩＰ経路指定などの根底にある経路指定を認識していない。
図１は、パケット交換型ネットワークの概略図を示し、この概略図に基づいて、本発明の例示の実施形態が以下に説明される。説明の目的だけのために、本願明細書で定義されるシグナリング拡張を理解するＮＳＩＳ操作可能ルータ１０３〜１０８、いわゆるＮＳＩＳルータが、ネットワークの中心部分に示される。しかし、ここで関心のあるＮＳＩＳ機能性を実現しない２つの隣接するＮＳＩＳルータの間に、別のルータまたはネットワークノードが存在してもよいことは明白である。したがって、ＮＳＩＳプロトコルレベルで、ＮＳＩＳルータ１０３〜１０８によって「見られる」ネットワークは、図２に示されるオーバレイネットワークに類似しており、このことから、ＮＳＩＳを実現していないルータは、ＮＳＩＳプロトコルレベルでＮＳＩＳルータに対して透過的であることを認識されることができる。
ＮＳＩＳルータ１０８はまた、ＮＳＩＳルータ１０８に接続される端末１１０〜１１２用のプロキシとして機能する。同じことが、移動体通信ネットワークにおけるワイヤレス端末１１６〜１２３用のプロキシサーバとして作用するＮＳＩＳルータ１０３に当てはまる。図１に示される実施例において、移動体通信ネットワークは、ＵＭＴＳネットワークである。端末１１６〜１２３（ＵＭＴＳ用語におけるユーザ機器ＵＥを示す）は、エアインターフェイスを介してノードＢ１２４または１２５に接続される。ノードＢ１２４、１２５および付属の無線ネットワーク制御装置（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）ＲＮＣは、ＵＭＴＳネットワークのいわゆる無線アクセスネットワーク（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）ＲＡＮを形成する。ＲＮＣは、サービングＧＰＲＳサポートノード（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）ＳＧＳＮおよびゲートウェイＧＰＲＳサポートノード（Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）ＧＧＳＮを介して、パケット交換型ネットワークのＮＳＩＳルータ１０３および１０７に連結される。同様に、移動体通信ネットワークにおける中間ノード（ＧＧＳＮ、ＳＧＳＮ、ＲＮＣ、ノードＢ）は、特に移送およびアドレス指定の機能性を提供するＮＳＩＳプロトコルレベルでＯＳＩ参照モデルの下位プロトコル層を実現するのに対し、ＮＳＩＳプロトコル層のような高位の層は中間ノードに対して透過的である。
一般に、端末は、メディアセッションを確立して関与するために、十分な機能を装備したデスクトップコンピュータ、ラップトップ、ＰＤＡ、携帯電話、タブレットＰＣなどの任意の種類の固定またはワイヤレス端末であってもよい。たとえば、端末は、メディアセッションの確立時に、ＮＳＩＳルータ／プロキシ（ＮＳＩＳルータ１０３または１０８など）、パケット交換型ネットワークの他のノードまたは通信当事者と通信するためのトランシーバを装備してもよい。メディアサービスは、たとえば、マルチキャストまたはブロードキャストメディアストリーミング、ボイスオーバＩＰ（ＶｏＩＰ）のようなエンドツーエンド指向の会話メディアサービス、ビデオ会議またはビデオ／オーディオストリーミングなどのストリーミングサービスなどを含んでもよい。
図３は、図１のパケット交換型ネットワークにおいて、エンドツーエンドメディアセッションを提供するために用いられることができる例示のプロトコルスタックを示す。
一般に、１つまたは複数のメディアストリームにおいて、メディアセッションのメディアデータが、提供される。メディアデータは、メディアトランスポートプロトコルを用いて、パケット化された形で移送される。たとえば、リアルタイムトランスポートプロトコルＲＴＰは、メディアトランスポートプロトコルとして用いられてもよい。セッション開始および管理のために、セッション管理プロトコルが用いられてもよい。たとえば、セッション管理プロトコルの適切な選択は、セッション開始プロトコルＳＩＰである。ＳＩＰの別法として、リアルタイムストリーミングプロトコルＲＴＳＰが用いられてもよい。通常、ＲＴＳＰは、クライアントサービスへのマルチメディアサーバの場合に用いられ、ＴＣＰプロトコルを介して接続指向の通信方式で移送されるのに対して、ＳＩＰメッセージは、コネクションレスＵＤＰプロトコルを介して行われる。また、ＲＴＰは、トランスポート層でＵＤＰを介して一般に提供される。しかし、ＴＣＰの使用もまた、可能である。セッション管理プロトコルは、セッションの記述、いわゆるセッション記述を搬送する。この目的のために、セッション記述プロトコルＳＤＰのようなプロトコルが、用いられてもよい。たとえば、ＳＩＰプロトコルメッセージにおいてカプセル化されたＳＤＰデータが、搬送されてもよい。
本発明の異なる実施形態によれば、ＮＳＩＳフレームワークは、セッション開始および管理、メディアデータトランスポートおよびセッション記述のほか、拡張機能を実現するために用いられる。
ＮＳＩＳシグナリングフレームワークは、２つのプロトコル、すなわちＮＳＩＳシグナリング層プロトコル（ＮＳＬＰ）と一般に呼ばれるシグナリングアプリケーション層およびＮＳＬＰデータのための根底にあるトランスポート機構と、ＮＳＩＳトランスポートレベルプロトコル（ＮＴＬＰ）と、に分割されてもよい。ＮＴＬＰ層において、ＮＳＬＰデータをカプセル化するために、ジェネラルインターネットメッセージングプロトコルフォーシグナリング（Ｇｅｎｅｒａｌ Ｉｎｔｅｒｎｅｔ Ｍｅｓｓａｇｉｎｇ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｓｉｇｎａｌｉｎｇ）（ＧＩＭＰ）が用いられてもよい。ＮＴＬＰ層においてカプセル化されたＮＳＬＰデータは、トランスポート層におけるＵＰＤ接続またはＴＣＰ接続を介して、提供されてもよい。
以下にさらに詳細に説明されるように、本発明の１つの態様は、メディアセッションにおいて用いられるメディアコーディクのメディアフォーマットにおける非互換性を克服するために、メディアセッションにおいて強化した機能性を備えたＮＳＩＳルータに対応するメディアフォーマット適応ノードを含むことができる新たなメディア適応ＮＳＬＰプロトコルの実現である。さらに、メディア適応ＮＳＬＰプロトコルは、適切なメディアフォーマット適応ノードの検出およびメディアフォーマット適応ノードにおけるリソースの確保を可能にする。
図３において、ネットワークおよびリンク層（層３および２）は、アドレス指定のためのＩＰプロトコルおよびＭＡＣプロトコルによって具体化される。しかし、ネットワークおよびリンク層プロトコルの実現は、ネットワークまたはその異なる部分に用いられるネットワーク基盤に左右される。
図４は、本発明の実施形態による２つの端末間のメディアセッションの例示の確立を示す。図４に基づき、本発明の主な態様のいくつかが、以下においてさらに詳細に説明される。
プロキシＡを用いることができる端末Ａ（エンドポイントＡ）は、第一に、プロキシＢを用いることもできる別の端末ノードＢ（エンドポイントＢ）に対するメディアセッションを最初に開始する。端末Ａから端末Ｂに送信されるセットアップメッセージは、セッション管理プロトコルを用いて移送され、セッション記述を含む。セットアップメッセージに含まれるセッション記述は、メディアフォーマット、セッションにおいて搬送される各メディアストリームに関するパラメータおよび属性を識別することによって、メディアセッションを記述する。ストリームのそれぞれは、単方向ストリームまたは双方向ストリームのいずれであってもよい。これに関連して、双方向は、２つのストリームがそれぞれ、共通のメディアフォーマットで端末Ａから端末Ｂにおよび端末Ｂから端末Ａに提供されることを意味するのに対し、単方向は、１つのストリームが記載したメディアフォーマットで端末Ａから端末Ｂにまたは端末Ｂから端末Ａの一方に提供されることを意味する。たとえば、ビデオ会議セッションは、ＰＣＭフォーマットにおける双方向のオーディオストリームと、ＭＰＥＧフォーマットにおける双方向のビデオストリームと、からなってもよい。この実施形態の変形において、強化されたＳＤＰプロトコルは、確立されるメディアセッションの内容を記述するために用いられる。
セッション記述のパラメータおよび属性は、メディアセッション、たとえば、セッションの各個別のストリームに関するＱｏＳ必要条件を任意に含んでもよい。さらに、パラメータおよび属性はまた、メディアセッションのストリームが、セッションに関して任意であるか、または必須であるかを示してもよい。
さらに、パラメータおよび属性はまた、端末Ａがその提案されたセッション記述に対する変更、たとえば、異なるＱｏＳ必要条件の使用、個別のメディアストリームに関して提示されたメディアフォーマット（たとえば、フォーマットのディスプレイサイズ、コーデック、ビット速度、フレーム速度など）などの変更を承認することに同意することを端末Ｂに示してもよい。したがって、セッション記述におけるパラメータおよび属性は、メディアフォーマットにおける非互換性が端末Ａおよび端末Ｂで利用可能な有効リソースを用いて解決されることができない場合には、端末Ａがまた、メディアフォーマット適応ノードの使用に同意するという信号を端末Ｂに送ってもよい。
端末Ｂは、セットアップメッセージを受信し、セッション記述を評価する。この評価手順において、端末Ｂは、十分な機能が、メディアセッションを確立するために端末で利用可能であるかどうかを決定する。たとえば、ビデオストリームがメディアセッションに含まれる必要があるが、端末Ｂは、セッション記述において端末Ａによって提示されたメディアフォーマットにおけるビデオデータを符号化および／または復号化するための適切なコーデックを有していない場合、またはたとえば、適切なディスプレイサイズが利用可能でない場合には、端末Ｂは、確立されることができるようにセッション記述を変更することを決定してもよい。
セットアップメッセージに対する応答において、端末Ｂは、端末Ａにセッションに関して端末Ｂが提案する変更を認識させるために、修正セッション記述を含む暫定承認を端末Ａに送り返す。
たとえば、端末Ａは、ビデオ会議セッションを確立することを望み、６４０×４００ピクセルのサイズで双方向のＭＰＥＧビデオストリームを用いることを提示する。しかし、端末Ｂは、わずか３２０×２００ピクセルのディスプレイサイズを装備しており、ＤｉｖＸビデオフォーマットでしか符号化および復号化することができない。端末Ｂが、ディスプレイサイズを局所的に変換可能なリソースを装備しており、６４０×４００ピクセルの提示されたサイズのビデオを符号化することができる場合には、ビデオに関する６４０×４００ピクセルのサイズの提示が端末Ｂには許容可能であってもよい。適切なリソースが利用可能でない場合には、端末Ｂは、３２０×２００ピクセルでＤｉｖＸ符号化されたビデオを用いることを提案することを示すように、セッション記述を修正してもよい。
端末Ｂからの応答の受信時に、端末Ａは、セッション記述に対する変更を認識し、新たな記述が利用可能なリソースが許容可能であるか、および／またはセッションに関するメディアフォーマット適応を用いる可能性を決定してもよい。
実施例に戻ると、端末Ａがまた３２０×２００ピクセルのフォーマットでビデオストリームを作成して復号化することができるＤｉｖＸ符号変換器を有する場合には、セッション記述に対する修正が許容可能であることを暫定承認メッセージにおいて、端末Ｂに示してもよい。ＤｉｖＸコーデックが端末Ａで利用可能ではないが、セッションに関するメディアフォーマット適応ノードの使用が端末Ａによって許容される場合には、端末Ｂに暫定承認の信号を送ってもよい。この暫定承認は、ネットワークにおけるメディアフォーマット適応が、ビデオストリームを移送するパケットがそれぞれ端末Ａから端末Ｂにおよび端末Ｂから端末Ａに供給される両方のパスで可能であるという前提条件下で、メディアセッションが開始されることができることを端末Ｂに示してもよい。
ネットワークのパケット交換性のために、メディアトランスポートプロトコルを用いて、メディアセッションのそれぞれのメディアストリームのデータを搬送するパケットの移送は、端末Ａから端末Ｂにおよび端末Ｂから端末Ａのいずれかの方向においてそれぞれ、異なるパスで経路指定されてもよいことを認識することが重要である。したがって、ビデオセッションのパケットデータが、端末Ａと端末Ｂとの間の両方向における１つのパスを介して供給されることを保証することができない場合には、双方向のストリームが関連しているのであれば、端末Ａから端末Ｂにおよび端末Ｂから端末Ａへのいずれかのパスで独立に、メディアフォーマット適応機能が検出される必要がある。
ＱｏＳ制約条件がメディアセッションの確立のための前提条件として満たされなければならない場合において、ネットワークリソースは、所与のＱｏＳ制約条件（たとえば、保証される待ち時間、保証される最小帯域幅など）で、メディアトランスポートプロトコルを用いてメディアデータを移送するために、いずれかのパスに沿って確保されてもよい。この実施形態の変形において、ＮＳＩＳシグナリングフレームワークのＱｏＳ−ＮＳＬＰプロトコルが、この目的のために用いられる。
本発明の異なる実施形態によれば、パスに沿ったメディアフォーマット変換機能の検出および確保は、図５〜図１３を参照して以下にさらに詳細に説明される。簡単に言えば、機構は、ＮＳＩＳルータを検出するために、新たなメディア適応ＮＳＬＰを提供することによって、ＮＳＩＳシグナリングフレームワークを用いる。このフレームワークは、インターフェイスをとり、たとえば、トランスコーディング／変換によって、セッションに関してメディアフォーマットの不適合を克服することができるメディア適応リソースと共に用いることができ、これらのＮＳＩＳルータのメディア適応機能のリソースを確保することを可能にする。実施例に戻ると、端末Ａは、６４０×４００ピクセルのＭＰＥＧビデオを３２０×２００ピクセルのＤｉｖＸビデオに変換（トランスコード）することを可能にするビデオトランスコーダとインターフェイスをとるＮＳＩＳルータに関して、ＮＳＩＳオーバレイネットワークにおいてＮＳＩＳルータに照会してもよい。
この照会に対する応答において、端末Ａは、所望のメディアフォーマット適応機能性を提供することができるＮＳＩＳルータを識別する情報を受信する。次に、端末Ａは、識別されたＮＳＩＳルータで、メディア適応のためのリソースを確保する。
類似の手順が、パケット交換型ネットワークを介して端末Ｂから端末Ａにパスに沿って、メディア適応リソースを検出して確保するために、端末Ｂによって行われる。したがって、実施例において、端末Ｂは、６４０×４００ピクセルのＭＰＥＧビデオを３２０×２００ピクセルのＤｉｖＸビデオに変換（トランスコード）することを可能にするビデオトランスコーダとインターフェイスをとるＮＳＩＳルータに関して、ＮＳＩＳオーバレイネットワークにおいてＮＳＩＳルータを照会してもよい。
ネットワークにおいてメディア適応リソースを十分に確保したときに、端末Ａは、更新されたセッション記述を含むメッセージを送信することによって、端末Ｂに通知してもよい。更新されたセッションは、端末Ａが所望のメディアフォーマット変換を提供するＮＳＩＳルータを見つけることが可能であったことと、それについてリソースを確保することが可能であったことと、を端末Ｂに示す。任意に、ＱｏＳ制約条件が満たされる場合には、メッセージはまた、ネットワークにおいて端末Ａによって確保されることが可能であったＱｏＳ制約条件を示してもよい。端末Ｂは、端末Ｂによって確保されたメディア適応リソースおよび任意にネットワークにおいて確保されたＱｏＳリソースを反映するように、セッション記述を「補正する」さらに更新されたセッション記述を含む別のメッセージを送信することによって、メッセージに応答する。
更新されたセッション記述に基づくセッションが端末Ａおよび端末Ｂにとって許容可能である場合には、メディアセッションが開始される。たとえば、端末ＡまたはＢのいずれかのポリシーに基づき、メディアフォーマット適応が可能でない場合、メディア適応リソースは検出されない場合、または確保されることができない場合には、セッションの確立は、中断されてもよい。
次に、本発明の例示の実施形態によるメディア適応リソースの検出および確保が、さらに詳細に記載される。図５は、メディアセッションの確立を可能にするために、所望のメディアフォーマット変換に関与することができるＮＳＩＳルータを識別するために適した本発明のこの実施形態によるオンパスＮＳＩＳルータ検出機構を示している。例示の実施形態において、端末１１０（端末Ａ）が端末１２２（端末Ｂ）とメディアセッションを確立しようとすると仮定される。
例示だけのために、端末１１０から端末１２２へのメディアデータの伝送のために、メディアフォーマット適応ノードの検出および確保が示される。類似の検出および確保のプロセスが、端末１２２から端末１１０へのメディアデータの伝送のために、端末１２２によって用いられる。
第一に、端末１１０（または端末１００によって用いられるプロキシ）は、次のＮＳＩＳルータ１０８へのメディア適応ノード検出照会を作成して、送信する。照会メッセージは、端末１２２に達するまで、ホップバイホップ方式で、１つのＮＳＩＳルータから次の隣接するＮＳＩＳルータに経路指定される。それによってパスに沿って照会メッセージは、経路指定され、メディアトランスポートプロトコルにおいてカプセル化されるメディアデータは、セッションの開始時に送られる。ＮＳＩＳシグナリングフレームワークにおいて、ＮＴＬＰプロトコルは、メディアストリームのパケットデータが、ネットワークを介して端末１１０から端末１２２にとるルート（パス）を検出することが可能である。したがって、このルートに沿ったすべての中間ＮＳＩＳルータは、パスに沿って隣接するＮＳＩＳルータを知っており、ＮＳＬＰプロトコルに基づいて、それらのＮＳＩＳルータが照会メッセージを転送することを可能にする。メディアストリームのパケットデータが、ネットワークを介してとる実際のパスの知識により、パスに沿ってメディア適応リソースを検出することを可能にする。メディアフォーマット適応リソースを照会するために、それぞれのノードは、ＮＴＬＰおよびＮＳＬＰの下層を含むＮＳＩＳシグナリングフレームワークを実現する必要があり、メディアトランスポートプロトコルにおいてカプセル化されるメディアデータは、それぞれのノードに送って、ネットワークノードでメディアデータ適応を実行する必要がある。
照会メッセージは、端末１１０によって必要とされるメディアフォーマット適応の記述を含む。したがって、通常、端末１１０（または端末１１０のプロキシ）は、端末１１０によってサポートされるが、端末１２２によってサポートされないフォーマットＸにおけるメディアデータを、端末１２２によってサポートされるが、端末１１０によってサポートされないフォーマットＹに変換することができるメディア適応リソースとインターフェイスをとるＮＳＩＳルータを探索する。端末自体が必要な機能性、たとえば、この文書において提示されるＮＳＩＳメディアフォーマット適応ＮＳＬＰを実現していない場合には、プロキシは通常、サービスにおいて端末をサポートするために用いられる。以下の節でさらに詳細に説明されるＮＳＩＳメディアフォーマット適応ＮＳＬＰに関連して、これは、端末がプロキシで「記載する」ことができ、プロキシがネットワークにおいてメディアフォーマット適応リソースを検出して確保するために、これらの端末にサービスを提供することを意味する。
この例示の実施形態によれば、照会メッセージが端末１２２に達するときに、端末１２２（または端末１２２のプロキシ）は、照会が端末１２２（またはそのプロキシ）に達するまでＮＳＩＳルータからＮＳＩＳルータに行われるパスと同一のパスに沿ったホップバイホップ方式で応答を返す。同じことが照会に適合する場合には、ＮＳＩＳルータはそれぞれ、応答に対するメディアフォーマット変換機能を含む。
端末１１０（または端末１１０のプロキシ）における応答受信時には、同じように応答を解析して、メディアフォーマット変換のためのＮＳＩＳルータを選択する（所望のメディア適応機能を備えた候補のＮＳＩＳルータが２つ以上ある場合）。メディアフォーマット変換のために選択されたＮＳＩＳルータでリソースを確保するために、端末１１０（または端末１１０のプロキシ）は、ＮＳＬＰプロトコルに基づいて、ホップバイホップ方式で選択されたＮＳＩＳルータに確保メッセージを送信し、選択されたＮＳＩＳルータは、所望のリソースが十分に確保されたかどうかを示す応答メッセージを返す。
上述したように、ＱｏＳ制約条件がメディアセッションによって満たされなければならない場合において、図５に示されているような類似の機構が、端末１１０から端末１２２に（またはそれらのプロキシ間で）メディアデータのパスに沿ってネットワークリソースを確保するために用いられてもよい。実施形態の変形において、ＮＳＩＳシグナリングフレームワークがネットワークリソース確保のために用いられる場合には、ネットワークリソースの照会および確保およびメディアフォーマット適応の照会および確保が、組み合わせられてもよい。
結果として生じるシグナリングは、以下の相違を除き、図５に示されるシグナリングと類似である。照会メッセージが、端末１１０によって所望のＱｏＳ制約条件および所望のメディアフォーマット適応を指定する。さらに、照会メッセージに対する応答はまた、ＱｏＳにＮＳＩＳルータが提供することができる情報も含む。確保メッセージはさらに、ＱｏＳにメディアデータのパスに沿ったＮＳＩＳルータが確保するために要求されるほか、上述したメディアフォーマット適応要求の情報を含む。さらに、ネットワークリソースが、端末１１０から端末１２２への完全なメディアデータパスに沿って確保されなければならないため、確保メッセージは、端末１２２に送られる必要がある。同様に、確保メッセージに対する応答が、端末１２２（またはそのプロキシ）で作成され、応答メッセージはさらに、すべてのＮＳＩＳルータが要求に基づきネットワークリソースを確保することができたかどうかと、要求に基づきメディアフォーマット適応リソースが確保されたことと、を示す。
この実施形態の別の変形において、メディアフォーマット適応は、ソースフォーマットＸからターゲットフォーマットＹにパケットデータを直接的に変換するために必要としなくてもよい。メディアフォーマット適応はまた、ネットワークにおいて２つ以上のメディアフォーマット適応ノードを検出して用いることを可能にしてもよい。たとえば、第１のＮＳＩＳルータは、ソースフォーマットＸにおけるメディアデータをフォーマットＹ’に変換してもよく、第２のＮＳＩＳルータは、フォーマットＹ’におけるメディアデータをターゲットフォーマットＹに変換してもよい。
照会は、たとえば、変換のソースフォーマットおよびターゲットフォーマットを指定してもよく、変換のために適切であれば、端末Ｂに対して照会を転送するときに、すべてのＮＳＩＳルータは、照会に対する適応機能を含んでもよい。
たとえば、第１のＮＳＩＳルータは、６４０×４００ピクセルから３２０×２００ピクセルのみにＭＰＥＧビデオのサイズをトランスコーディングすることができることを示す情報を照会に追加してもよいが、端末Ｂに向かう次のＮＳＩＳルータに対して照会を送る前に、コーデックフォーマットを変換することはできない。端末Ｂへのパスにおける別のＮＳＩＳルータが３２０×２００ピクセルのＭＰＥＧビデオから３２０×２００ピクセルのＤｉｖＸ符号化ビデオへの欠けている変換を提供することができる場合には、このルータは、照会において同じことを示してもよい。したがって、応答は、いずれのＮＳＩＳルータが、中間／ソースメディアフォーマットから中間／ターゲットメディアフォーマットへの変換を提供することができるかを示してもよい。また、メディアフォーマット適応機能の検出および確保とネットワークリソースの検出および確保を組み合わせることが、可能である。
以下の節において、メディアフォーマット適応の検出および確保機構の本発明の異なる実施形態によるさらに詳細な実現が、記載される。以下の節において、例示のために、ＳＤＰプロトコルがメディアセッション（セッション記述）を記述するために用いられることと、ＳＩＰプロトコルがＳＤＰフォーマットにおいてカプセル化されたセッション記述を搬送し、端末１１０と端末１２２との間のメディアセッションの開始および制御を行うために用いられることと、が仮定される。さらに、セッションのメディアストリームが、ＲＴＰプロトコルを用いて移送されることが仮定される。
よりよい理解のために、メディアセッションの確立は、２つの段階に分割されてもよい。
・段階Ｉ：必要なメディア適応が確認され、探索され、見つかった場合には、確保される。メディア適応リソースが確保された後、この段階が終了し、次の段階に進む。
・段階ＩＩ：エンドポイント（端末１１０および１２２）の間の最後のセッションの詳細の通信および既に確保されたリソースを用いることによる通信の開始
メディアセッションの記述に関して従来のＳＤＰプロトコルを用いて、メディアセッション（サービス）を要求するエンドポイントは、セッションのそれぞれのストリームがセッションの必須または任意のいずれの構成要素であるか、および／またはセッションの要求されたストリームのいくつかが利用可能でない場合には、セッションが許容可能であるかを指定するための手段を持たない。ユーザが、受信を望むストリームに関して、ネットワークにおいてエンドポイントまたはメディアフォーマット適応ノードで局所的に利用可能であるメディア適応リソースを前向きに実行または利用することができない。
本発明の一実施形態によれば、既存のＳＤＰプロトコルに対する拡張が提案され、これらの欠点の克服を可能にする。この実施形態によれば、新たな前提条件タグは、ストリームのそれぞれまたはセッションに関して導入され、ストリームのそれぞれが、セッションの必要な部分であるかどうかを指定可能であるか、または適応が見つからない場合（「必須」または「任意」のいずれであっても、「強度タグ」であり、以下参照のこと）には、いくつかのストリームを残すことができる。
特に、ＳＤＰの前提条件フレームワークを新たなメディア適応前提条件を有するように拡張することが提示される。既存の“ｑｏｓ”トークンのほかに、前提条件タイプに関する新たなトークン値、すなわち“ａｄａｐｔａｔｉｏｎ”が定義される。この新たな前提条件に加えて、２つの新たなＳＤＰ属性、すなわちターゲット“ａ＝ｔａｒｇｅｔ：”および“ａ＝ｓｏｕｒｃｅ：”属性が定義される。これらの属性は、メディア適応のターゲット／ソース、たとえば、ソースメディアフォーマットにおけるメディアデータがいずれのターゲットメディアフォーマットにトランスコードされるかを示す。任意に、また、送信器（端末１１０）と受信器（１２２）との間の各中間ノードの“ｆｏｏｔｐｒｉｎｔ”を示すための新たな属性も定義される。ｆｏｏｔｐｒｉｎｔは、“ａ＝ｉｎｔｅｒｍｅｄｉａｔｅ：”の行におけるメディアフォーマットパラメータによって記載されるフォーマットにおける値のセミコロンで分離されたリストに提供されてもよい。
新たな定義パラメータの例示の定義が、以下に示される。
target-tag = "a=target:" media-format
source-tag = "a=source:" media-format
intermediate-tag = "a=intermediate:value-type value-list

where
media-format = payload type number
value-type = format of the footprint, e.g., RTP SSRC.
value-list = list of footprint identifiers
前提条件フレームワークにおいて、新たなトークンが、前提条件タイプに導入される。
precondition-type = "qos" | "adaptation" | token
前提条件フレームワークの残りの定義は、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇで利用可能なＲＦＣ３３１２に明記されているように、再使用される。
セッションを確立するために、端末１１０のユーザは、上記の新たなＳＤＰ定義に基づき、セッションの１つまたは複数のストリームに関して適応のための前提条件を設定するメディアセッションのセッション記述を含むＳＩＰプロトコルの招待（ＩＮＶＩＴＥ）メッセージを送信する。この例示の実施形態によれば、前提条件属性は、端末１１０が指定（提示）されたメディアフォーマットにおける対応するストリームを受信することができるが、別のメディアフォーマットでは受信することができないことを端末１２２に通知する。したがって、要求されたように、端末１２２によって指定されたメディアフォーマットで提供されることができる場合には、メディア適応は必要ではない。
同時に、前提条件属性は、端末１１０が端末１２２に前提条件付きのストリームが利用可能である、すなわちメディア適応リソースが見つかって確保されるまで、端末１１０が端末１２２に入ってくるセッションについて警告したくないことを端末１２２に示してもよい。
段階Ｉの例示のステップごとの手順が、以下に示される。端末１２２は、セッション記述の以下の例示の抜粋を含む招待メッセージを送信してもよい。
m=audio 20000 RTP/AVP 0
a=rtpmap:0 iLBC/8000
c=IN IP4 192.0.2.1
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=curr:adaptation e2e none
a=des:adaptation mandatory e2e sendrecv
これらの行は、セッションが、ポート番号２００００でＲＴＰプロトコルを用いて移送され、ペイロードタイプ０を有する双方向のオーディオストリームを含む必要があることを指定する。第２行は、ペイロードタイプ０のオーディオストリームが、サンプリング周波数８０００Ｈｚを用いてｉＬＢＣ符号化されたオーディオストリームであることを明記する。残りの行は、他のストリームは承認されないため、要求されたストリームが利用可能でない場合に限り、適応が必須であることを明記する。すなわち、このストリームが（適応または他の方法のいずれかによって）提供されない場合には、セッションは確立されないことになる。ａ＝ｃｕｒｒ：は、適応の現在の状態を示し、“ｎｏｎｅ”は、このセッションオファを発行する瞬間に、エンドポイント（端末）が適応、すなわちエンドツーエンド（「ｅ２ｅ」）適応を確保していないことを意味する。ａ＝ｄｅｓ：の行は、提案されたメディアフォーマットが承認されない場合における所望の適応を示す。メディア適応は、双方向のストリームが通信されている場合には、両方向（端末１１０から１２２へおよび端末１２２から１１０へ）においてエンドツーエンド適応でなければならない。
以下において、ＮＳＩＳメッセージの送信者または受信者として、使用端末１１０および端末１１０のプロキシ（ＮＳＩＳルータ１０８）は、等価である。端末１１０自体がＮＳＩＳメディアフォーマット適応ＮＳＬＰをサポートするかどうか、または端末１１０が検出および確保のシグナリングのために提供するプロキシに付属しているかどうかに応じて、ＮＳＩＳメッセージを送信する端末１１０またはプロキシ１０８であってもよいためである。プロキシがセッションにおいてシグナリングのために用いられる場合には、必要とされるメディア適応の設定が、ＳＩＰメッセージを交換することによって検出されることができるため、両方の端末１１０および１２２におけるＳＩＰユーザエージェントは、プロキシの存在を認識してもよい。したがって、ＳＩＰとメディアフォーマット適応ＮＳＬＰとの間のインターフェイスもまた、設けられてもよい。
端末１２２が、ストリームの指定されたメディアフォーマットをサポートしないことを（たとえば、指定されたコーデックが存在しない）検出する場合には、ＳＩＰプロトコルの暫定応答メッセージ（コード１８３）を端末１１０に送信する。必要なコーデックが端末１２２で利用可能でないために、それぞれのメディアストリームが指定されたメディアフォーマットで端末１１０によって受信のみが可能であることを前提条件属性が示すときには、端末１２２は、セッションを確立するためにメディアフォーマット適応が必要であることを認識する。したがって、端末１２２がまた、“ａｄａｐｔａｔｉｏｎ”前提条件をサポートするため、端末１２２から端末１１０にネットワークを介してメディアデータパスに沿って、メディアフォーマット適応リソースの検出および確保を直ちに開始してもよい。
さらに詳細には、端末１２２は、上記で示された例示のセッション記述を含む招待メッセージを受信し、ｉＬＢＣコーデックをサポートせず、代替のメディアフォーマットＰＣＭ符号化オーディオとしてサポートすることができることを認識する。代替のメディアフォーマットとしてＰＣＭコーデックの存在を示すために、端末１２２は、ポート番号をゼロ（“０”）に設定し、ＰＣＭコーデックのための新たなペイロードタイプ、“１”を追加することによって、セッション記述を修正する。したがって、端末１２２は、オーディオストリームに関してサポートするメディアフォーマットを含むようにセッション記述を修正し、セッションを確立するために、準備としてメディア適応を用いることを示している。
暫定応答において端末１２２によって送信されたセッション記述の例示の修正の抜粋は、以下のようであってもよい。
m=audio 0 RTP/AVP 0 1
a=rtpmap:0 iLBC/8000
a=rtpmap:1 PCM/8000
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
a=curr:adaptation e2e unknown
a=des:adaptation mandatory e2e sendrecv
a=conf:adaptation e2e recv
メディアフォーマット適応リソースの検出および確保のために、端末１２２がＮＳＩＳシグナリングフレームワークを用いるため、上記で既に概略を述べたように、ネットワークからその照会メッセージへの応答メッセージに基づいて、その「送信」方向（端末１２２から端末１１０に）において利用可能なメディア適応を提供するためのリソースを検出してもよい。しかし、他の方向、すなわちメディアデータが端末１１０から端末１２２に経路指定されるパスで、確保の状態を認識しない。したがって、端末１２２は、その暫定応答を送信することによって、端末１１０へのその「受信」方向においてリソースの確保のための確認の要求に進んでもよい。
さらにおおざっばに言えば、暫定応答メッセージは、端末１２２に対して「了解、こちらはメディア適応を行おうとしている。必要なリソースを確保するまで、そちらに警告を発しない」と宣言することと等価である。ストリームが双方向である場合には、端末１２２は、「了解、こちらはメディア適応を行おうとしている。必要なリソースを確保するまで、そちらに警告を発しない。そちらがメディア適応を行おうとすることは可能であり、そちらがすべての必要なリソースを確保する前に、こちらに警告を発さないで欲しい」ことを示す。
実施例において、ＳＤＰ記述の「ｍ行」によって指定されたストリームが双方向である、すなわち、方向性に関する属性を持たない（“ａ＝ｓｅｎｄｒｅｃｖ”属性がないか）または前提条件において“ｓｅｎｄｒｅｃｖ”値を有するかのいずれかが仮定されている。
応答メッセージを送信した後、端末１２２は、メディアストリームのためにメディア適応リソース（および適用可能である場合には、ネットワークＱｏＳリソース）の確保を開始してもよい。端末１１０は、ＰＲＡＣＫ（暫定応答承認）によって応答メッセージを承認し、端末１１０から端末１２２へのメディアデータパスでメディアフォーマット適応リソースの検出および確保を開始する。
両方の端末１１０および１２２は、ＮＳＩＳシグナリングフレームワークおよび提案されたメディアフォーマット適応ＮＳＬＰプロトコルを用いる。図５を参照して、上記で概略を述べたように、端末１１０は、端末１２２に対する照会メッセージを送信し、端末１２２は、端末１１０に対する照会メッセージを送信する。
端末１２２がメディア適応リソース（およびネットワークＱｏＳリソース）の確保を確認する応答メッセージを受信する場合には、端末１２２は、確認を受信しておらず、前提条件が依然として満たされていないため、他の方向におけるリソースも確保されるまで待機する。
端末１１０は、応答メッセージを受信すると、更新されたセッション記述において、何がメディア適応処理に対する入力および出力であるかを明確に示す。入力は“ａ＝ｓｏｕｒｃｅ：＜ｍｅｄｉａ ｆｏｒｍａｔ＞”属性（この場合にはｉＬＢＣ）によって示され、ターゲットとされる出力（“ａ＝ｔａｒｇｅｔ：＜ｍｅｄｉａ ｆｏｒｍａｔ＞”によって示される）は、返答において要求されるコーデック（ＰＣＭ）である。次に、端末１１０は、更新されたセッション記述の以下の例示の抜粋を含むＳＩＰプロトコルの更新メッセージ（更新オファ）を端末１２２に送信する。
m=audio 20000 RTP/AVP 0 1
a=rtpmap:0 iLBC/8000
a=rtpmap:1 PCM/8000
c=IN IP4 192.0.2.1
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
a=curr:adaptation e2e send
a=source:0
a=target:1
a=des:adaptation mandatory e2e sendrecv
端末１２２は、メディア適応（および任意にネットワーク）リソース確保の現在の状態に関して更新されたセッション記述もまた含む返答メッセージを用いて応答し、セッション記述は特に、以下の部分を含む。
m=audio 30000 RTP/AVP 0 1
c=IN IP4 192.0.2.4
a=rtpmap:0 iLBC/8000
a=rtpmap:1 PCM/8000
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
a=curr:adaptation e2e sendrecv
a=des:adaptation mandatory e2e sendrecv
a=source:1
a=target:0
各“ａ＝ｒｔｐｍａｐ”属性で、セッション記述において指定されたさらにコーデック特有の（ｉＬＢＣまたはＰＣＭ）パラメータであってもよいことを留意されたい。これは、ＮＳＩＳルータ（メディア適応ノード）において行われている正確なメディア処理をさらに高度な詳細で指定可能であってもよい。
必要なメディア処理の記述
次に、本発明の例示の実施形態による利用可能なメディアフォーマット適応リソースを検出するために、端末１１０および１２２によって送信される照会の内容が、さらに詳細に記載される。候補のメディア適応ノードを見つけるために、機構は、必要な処理を指定するために必要とされる。
たとえば、セッション記述オファは、以下のようであってもよい。
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 99
a=rtpmap:99 iLBC/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
a= pkt_rate=20; bw=20000
このセッション記述は、ポート４９１８０におけるＲＴＰを介して移送されるｉＬＢＣフォーマットにおけるオーディオストリームと、ＲＴＰを介して移送されるポート５１３７２でＨ２６１符号化ビデオストリームと、を含むセッションを「オファする」。上述の実施例において、パラメータｐｋｔ＿ｒａｔｅおよびｂｗは、例示のために示されているに過ぎない。これらのパラメータは、簡略化した表現として示される。
このセッション記述（オファ）に対する応答において、開始端末は、以下の修正セッション記述を受信してもよい。
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49172 RTP/AVP 99
a=rtpmap:99 iLBC/8000
m=video 0 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=pkt_rate=10; bw=150000
それによって返答する端末は、ペイロードタイプ３２を有するＭＰＥＧ２（ＭＰＶ）フォーマットにおけるビデオストリームのために、代替のコーデックを提案する。
修正セッション記述から生じるメディア適応に関する一般的な定義は、以下のフォーマットに基づいてもよい。
Figure 2009506601
このフォーマットに基づいて、上記で与えられた実施例において、必要とされるメディア適応の記述は、以下のように見える。
{(media_type =video, media_format= 31), (media_subtype =H261), (parameter_set: rate=90000; pkt_rate=20; bw=20000)} <-> {(media_type= video, media_format= 32), (media_subtype= MPEG2 (MPV)), (parameters: rate= 90000; pkt_rate=10; bw=150000)}
上記の返答端末のセッション記述において、方向性は、メディアストリーに関してｓｅｎｄｒｅｃｖ／ｓｅｎｄｏｎｌｙ ａｎｄ ｒｅｃｖｏｎｌｙ属性によって決定されてもよく、“ｍ＝”の行は通常、各メディアの行に関する“ａ＝”の行に存在する。存在しない場合には、ｓｅｎｄｒｅｃｖが仮定され、存在する場合には最初のｎタプルが必要なメディア変換に対する入力を記述し、第２（および以下）のｎタプルが所望の出力（または複数の出力）を記述する。上述の必要なメディア適応の表現に関する実施例において、双方向性は、“＜−＞”によって示される。
必要な変形の階層順のｎタプルは、データパケットの経路指定に影響を及ぼさず、通常は層４までのプロトコルヘッダにおける変更であり、ＵＤＰまたはＴＣＰは経路指定に影響を及ぼしうるが、これは以下で説明される。この階層リストは、メディアタイプ（オーディオ／ビデオ／テキストなど）から始まり、次に、メディアのサブタイプ（コーデック）およびペイロードタイプ番号（ＲＴＰの場合）および任意の不適合のメディアストリーム属性へと続いてもよい。
必要な変形の階層順のｎタプルは、“ｍ＝”の行を属性“ａ＝”の行に存在する“ｍ＝”の行およびそれらの関連属性と比較することによって、得られる。“ｍ＝”の行を比較することによって、メディアタイプおよびペイロードタイプ（またはＳＤＰにおいて定義されるように「メディアフォーマット」）の不適合が、確認されてもよい。上記の実施例において（ボールド体の“ｍ＝”の行）、返答側がペイロードタイプ３２を有することを望んでいるように、メディアフォーマットに不適合がある。順に並んだｎタプルにおける次の項目は、“ａ＝”の行から得られるメディアサブタイプおよびメディアストリームパラメータ設定である。これらの属性は、機能（メディアサブタイプ（コーデック）、コーデックなど）と、言語またはストリームの定格、たとえば、言語の場合には“ａ＝ｌａｎｇ”などのユーザの好みを表現してもよい。
適応の必要性を生じうる可能な属性のリストは、属性フィールドリスト“ａｔｔ−ｆｉｅｌｄ”に基づき、ｈｔｔｐ：／／ｗｗｗ．ｉａｎａ．ｏｒｇ／ａｓｓｉｇｎｍｅｎｔｓ／ｓｄｐ−ｐａｒａｍｅｔｅｒｓのＩＡＮＡから得られることができる。さらに、各コーデックはそれ自体のパラメータを定義するため、すべてのパラメータの不適合が、１つまたは複数の必要な適応を意味するわけではない。どのパラメータが適応を起動するかを割り当てるために、端末において見られるか、ネットワークにおいてメディア適応リソースで利用可能な変形が割り当てられる一連の規則および制約条件を合わせたすべてのコーデックおよびコーデックパラメータおよびそのすべての可能な変形の対照表があってもよい。残念なことに、変換が有効であるか、場合によって有効でないかを確認することは、自動的に行われない場合がよくある。したがって、一連の規則および制約条件が、提供されてもよい。
たとえば、すべてのオーディオコーデックが同一のパラメータを有するとは限らず、一部は可変ビット速度であり、一部は一定のビット速度である。したがって、一定のビット速度構成に対する可変ビット速度コーデックの所与の構成の直接的な変換は、ない。等価な（または十分に良好な）適応を生じるパラメータの設定は、ユーザによって手動で設定されなければならない。そのような規則および制約条件のリストは、メディア適応記述に含まれるか、またはＵＲＩによってそれに関連付けられることが提案される。
メディア適応の記述は、ＳＤＰｎｇなどの拡張されたセッション記述プロトコルを用いて実現されてもよい。特に、以下に列挙されるｓｄｐｎｇ−ｒｔｐ−ｖｉｄｅｏ−ｔｘｃｏｄｅｃパッケージリストは、規則および制約条件のそのようなコンテナであってもよい。ＳＤＰｎｇは、機能および制約条件を表現可能なより洗練された拡張された文法を有する。ＳＤＰｎｇはまた、外部リソース（用いられる属性が定義されるいわゆるパッケージ）に対する参照も可能である。したがって、ＳＤＰｎｇにおける異なる単方向トランスコーダ機能性の別の実施例の表現は、以下の通りである。
<sdpng xmlns="http://www.iana.org/sdpng"
xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:rtp="http://www.iana.org/sdpng/rtp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iana.org/sdpng \
sdpng-base.xsd
http://www.iana.org/sdpng/rtp/sdpng-rtp-pkg.xsd
http://www.iana.org/sdpng/video/\
sdpng-rtp-video-txcodec\
pkg.xsd"
owner="txcoding-service@example.com" id="98765432" \
version="1">
<cap>
<rtp:udp name="rtpudpip6">[...]</rtp:udp>
</cap>
<cfg>
<video:txcodec name="h263plus-mpg-txcodec">
<video:input-encoding>H.263+</video:encoding>
<video:input-resolution>QCIF</video:resolution>
<video:input-framerate max="30"/>
<video:ouput-encoding>MPEG-4</video:output-format>
<video:output-resolution>QCIF</video:resolution>
<video:output-framerate max="30"/>
</video:txcodec>
</cfg>
<def>
<rtp:udp name="rtp-def" ref="rtp:rtpudpip6">
<rtp:pt-in>31</rtp:pt-in>
<rtp:pt-out>32</rtp:pt-out>
</rtp:udp>
</def>
<constraints>
[where applicable]
</constraints>
</sdpng>
上記の記述は、この記述を作成したメディア適応リソースが、Ｈ２６３、同一の解像度およびフレーム速度でＭＰＥＧ−４ビデオに対して最大毎秒３０フレームのＱＣＩＦ解像度に基づくトランスコーディングをサポートすることを示す。また、コーデックのコーデック特有のパラメータを理解するために、別のパッケージが必要とされることを留意されたい。これは、ｈｔｔｐ：／／ｗｗｗ．ｉａｎａ．ｏｒｇ／ｓｄｐｎｇ／ｖｉｄｅｏ／ｓｄｐｎｇ−ｒｔｐ−ｖｉｄｅｏ−ｔｘｃｏｄｅｃ−ｐｋｇ．ｘｓｄから検索される。また、ペイロードタイプ（メディアフォーマット）は、返答側の要求に適合させるために、３１から３２に変更しなければならないことも留意されたい。
リソースの検出および確保の別の態様
リソース確保のためのトリガは、ネットワークにおいてであってもよく、またはクライアント自体からであってもよく、クライアントがＮＳＩＳメッセージングを実現するか、またはＮＳＩＳプロキシに付属しているかに左右される。いずれの場合でも、ＳＩＰユーザエージェントは、ＮＳＩＳエンティティに対する必要な処理ステップを通信するために、端末またはネットワーク（プロキシ）においてＮＳＩＳエンティティに対するインターフェイスを用いる。したがって、セッションに関して必要なメディア適応を決定したときには、ＳＩＰユーザエージェントは、必要なメディア適応の記述を含む本願明細書で提案されたＮＳＩＳメディアフォーマット適応ＮＳＬＰの照会メッセージをそれ自身に送信することによって、またはプロキシにそれを実行することを示すことによって、リソースの検出および確保を始動させてもよい。
ＱｏＳ前提条件がセッション記述に存在する場合には、ネットワークＱｏＳリソースの検出および確保の後に、たとえば、メディアフォーマット適応リソースの探索および確保が、始動されてもよい。これは、必要なネットワークＱｏＳリソースが確保することができない場合には、検出および確保を中止するという利点を有する。
あるいは、メディアフォーマット適応およびネットワークＱｏＳは、並列でまたは共に始動（および実行）されてもよい。すなわち、ＮＳＬＰメッセージま本願明細書に記載されるメディアフォーマット適応ＮＳＬＰシグナリング情報に加えて、ＱｏＳ−ＮＳＬＰシグナリング情報を含む。
ネットワークにおいてメディア適応機能を探索するときに遭遇されることができる複数の場合がある。望ましい場合において、必要とされるすべての適応リソースは、端末１１０から端末１２２への（および端末１２２から端末１１０への）メディアパスで見つけられる。しかし、それは、一部がメディア適応リソースを必要とする場合であってもよく、またはそれらのすべてが、端末１１０から端末１２２への（および端末１２２から端末１１０への）メディアデータパスで検出されない場合であってもよい。
一部のリソースが欠けている場合には、ＮＳＩＳメディアフォーマット適応ＮＳＬＰアプリケーションは、メディア適応リソースの探索を「オフパス」、すなわち、端末１１０から端末１２２へのメディアデータパスでＮＳＩＳルータに（たとえば、ホップ、待ち時間などに関して）「近い」ＮＳＩＳルータで可能であってもよい。本発明の他の実施形態によって提案されたこの強化はまた、利用可能なメディア適応機能を交換可能にするＮＳＩＳルータに関する情報交換方式を含み、ＮＳＩＳルータが「付近の」ＮＳＩＳルータのメディア適応機能も認識するようになっていてもよい。たとえば、ＸＭＬが、機能記述を定義するために用いられてもよい。この情報交換方式を提供することによって、利用可能なメディアフォーマット適応リソースの検出における待ち時間が、削減されてもよい。
一旦、すべてのメディア適応（およびネットワークＱｏＳ）リソースが、端末１１０によって見つけられて確保されると、既に説明したように、端末１１０は、ＳＩＰプロトコルの更新メッセージを端末１２２に送信する。端末１２２は、セッションに関するすべての前提条件がその端部でも満たされたことを示す更新メッセージに関する２００（ＯＫ）応答を返してもよい。時間におけるこの時点で、端末１２２は、ユーザへの警告を開始し、ＳＩＰプロトコル仕様に基づき、セッション確立が終了する。
メディアフォーマット適応ＮＳＬＰのためのメッセージ
以下において、ネットワークにおいてメディア適応リソースの検出および確保のために、交換されるＮＳＬＰメッセージの例示の定義を示す。メッセージは、詳細に記載されておらず、その機能性のみを記載している。
照会メッセージ
照会メッセージは、必要なメディア適応リソースに関してネットワークを「精査する」ために、端末（またはそれらのプロキシ）によって用いられ、必要なメディアフォーマット適応の記述を含む。
確保メッセージ
確保メッセージは、ＮＳＩＳルータまたはその関連プロセッサで、状態を修正する。確保メッセージは、ＮＳＩＳルータでメディア適応リソース確保の現在の設定を保存し、任意に変更するために用いられてもよい。
応答メッセージ
応答メッセージは、照会（照会メッセージ）またはリソース確保要求（確保メッセージ）の結果に関する情報を提供するために用いられてもよい。
通知メッセージ
通知メッセージは、情報をＮＳＩＳ−ルータに搬送するために用いられてもよい。通知メッセージは、非同期で送信され、具体的な状態または前に受信されたメッセージに関連付ける必要がないと言う点で、応答メッセージとは異なる。通知メッセージによって搬送された情報は、通常、エラー状態に関連付けられる。例は、分解される状態について、または確保の実行権が取り上げられたときを示すための上流ピアへの通知である。
加入メッセージ
このメッセージは、メディア適応リソースの「オフパス」検出および確保が実現される場合に、任意に定義されてもよい。このメッセージは、隣接するピアＮＳＩＳルータで利用可能なメディア機能に関する通知を受信するために、ピアＮＳＩＳルータに加入するために用いられる。
ＭｅｄｉａＳｐｅｃ
以下の節は、上記のＮＳＩＳメディアフォーマット適応ＮＳＬＰメッセージの個別のフォーマットを定義する。本願明細書において定義されるＮＳＩＳメディアフォーマット適応ＮＳＬＰのフォーマット定義はまた、以下では、ＭｅｄｉａＳｐｅｃとも呼ばれる。
本願明細書において定義される例示のメッセージのＭｅｄｉａＳｐｅｃ内容フィールドにおけるデータのフォーマットは、以下のＭｅｄｉａＳｐｅｃテンプレートに基づいている。
+----------------------+-----------------+-----------------+
| MediaSpec/Ctrl.Inf. | Mandatory |Optional |
| Object ID |MediaSpec Params.|MediaSpec Params.|
+----------------------+-----------------+-----------------+
たとえば、確保メッセージは、以下のようであってもよい。
RESERVE = COMMON_HEADER
RSN [ RII ] [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ]
[ POLICY_DATA ] [QSPEC][ MediaSpec ]
確保メッセージの代替定義は、以下のフォーマットおよび内容を有する。
RESERVE = COMMON_HEADER
RSN [ RII ] [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ]
[ POLICY_DATA ] [ *QSPEC including the MediaSPEC data]
これらのメッセージは、ＮＳＩＳトランスポート層プロトコルＮＴＬＰを用いて、ＮＳＩＳルータ間で移送される。ＮＴＬＰプロトコルに関する現在の定義は、上述したＩＥＴＦインターネットドラフト「ＧＩＭＰＳ：Ｇｅｎｅｒａｌ Ｉｎｔｅｒｎｅｔ Ｍｅｓｓａｇｉｎｇ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｓｉｇｎａｌｉｎｇ」に定義されている。
制御情報オブジェクト
制御情報オブジェクトは、オブジェクトＩＤ（Ｏｂｊｅｃｔ ＩＤ）（たとえば、Ｏｂｊｅｃｔ ＩＤ＝０）によって定義され、この実施形態によれば、各ＮＳＬＰメッセージに関して必須である。このオブジェクトは、制御情報を搬送するために用いられる。
メディア適応所望オブジェクト
第１のオブジェクトは、メディア適応所望オブジェクトであり、たとえば、Ｏｂｊｅｃｔ ＩＤ＝１を有してもよい。このオブジェクトは、必要なメディア適応処理の記述に関する少なくとも１つのパラメータを含む。簡単にするため、唯一の適応が必要とされると仮定される。しかし、たとえば、ストリームが最初にトランスコードされ、次に暗号化されなければならない場合には、複数のメディア適応ステップが必要とされる場合がある。必要なメディア適応処理の記述が、上述したように得られてもよい（「必要なメディア適応処理の記述」の節参照）。
このメディア適応処理の１つのきわめて重要な特徴は、シグナリングパケットがデータパケットと同一のルートに従うものとすることである。これは、メッセージ経路指定情報（ＭＲＩ、ＩＥＴＦインターネットドラフト「ＧＩＭＰＳ：Ｇｅｎｅｒａｌ Ｉｎｔｅｒｎｅｔ Ｍｅｓｓａｇｉｎｇ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｓｉｇｎａｌｉｎｇ」、５．８．１．１節参照）を見つけ出すことによって保証される。これは、パケットの経路指定を決定するプロトコルヘッダの設定を定義し、シグナリングが実際に「オンパス」であるように、シグナリングおよびデータパケットで等しいものとする。したがって、データパケットは、ＭＲＩフィールドのいずれにおいても一切変更を受けることはできない。
MRI = { network-layer-version, source-address, prefix-length, destination-address, prefix-length, IP-protocol, diffserv-codepoint, [ flow-label ], [ ipsec-SPI / Layer 4-ports]}
上記の定義において、括弧はパラメータの任意の存在を示す。
ＭＲＩ情報は、パケットの経路指定を決定するものであるため、したがって、メディア適応処理記述は、データパケットのｎｅｔｗｏｒｋ−ｌａｙｅｒ−ｖｅｒｓｉｏｎ、ｓｏｕｒｃｅ−ａｄｄｒｅｓｓ、ｐｒｅｆｉｘ−ｌｅｎｇｔｈ、ｄｅｓｔｉｎａｔｉｏｎ−ａｄｄｒｅｓｓ、ｐｒｅｆｉｘ−ｌｅｎｇｔｈ、ＩＰ−ｐｒｏｔｏｃｏｌ、ｄｉｆｆｓｅｒｖ−ｃｏｄｅｐｏｉｎｔ ｏｒ ｐｏｒｔ ｎｕｍｂｅｒｓ、ｆｌｏｗ ｌａｂｅｌｓまたはＩＰＳｅｃ ＳＰＩの値における詳細を修正してはならない。
メディア適応所望オブジェクトおよび必要なメディア適応処理の記述は、照会メッセージまたは確保メッセージに含まれてもよい。たとえば、ストリーミングの場合には、タイプ（ビデオ）およびサブタイプ名（たとえばＨ２６１ビデオトランスコーダの場合には“Ｈ２６１ｔｘｃｏｄｅｒ”）の仕様およびサポートされるために必要なパラメータは、十分である。さらに、照会メッセージは、さらに一般的であってもよく、ビデオトランスコーティング機能性について尋ねるだけであってもよく、オーバレイノードがメディア適応利用可能オブジェクトにおいて利用可能なすべての利用可能なトランスコーダを列挙するものとする。
メディア適応所望オブジェクトが確保メッセージに含まれる場合には、確保メッセージが定められる特有のメディア適応構造およびＮＳＩＳルータにおけるリソースを要求する。複数の処理ステップが、メディア適応のために必要とされる場合には、複数のメディア適応所望オブジェクトが、有意の順でカスケード化されてもよい。同一のＩＤを有する定義を処理することは、別法を表す。
メディア適応利用可能オブジェクト
第２のオブジェクトは、メディア適応利用可能オブジェクトであり、Ｏｂｊｅｃｔ ＩＤ＝２によって識別されることが可能である。このオブジェクトが配置されるメッセージに応じて、このオブジェクトは、配置され、中間ＮＳＩＳルータによる修正を受けてもよく、受けなくてもよい。オブジェクトが応答メッセージに含まれる場合には、オブジェクトによって搬送される情報は修正されない。オブジェクトが照会メッセージに含まれる場合には、各ＮＳＩＳルータがメディア適応利用可能オブジェクトにおいて利用可能なリソースをオブジェクトに追加してもよい。たとえば、追加された情報は、ＳＤＰｎｇが用いられる場合には、＜ｃａｐ＞タグおよび＜ｃｆｇ＞タグに含まれてもよい。代替のメディア適応構成、範囲およびパラメータのリストは、オブジェクトに含まれることができる。ＳＤＰｎｇの実施例に戻ると、有意の別法は、たとえば、ＳＤＰｎｇにおける＜ｃｆｇ＞タグおよび＜ａｌｔ＞タグを用いて表現されてもよい。
メディア適応確保済みオブジェクト
第３のオブジェクトは、メディア適応確保済みオブジェクトであり、Ｏｂｊｅｃｔ ＩＤ＝３によって識別されてもよい。このオブジェクトは、メディア適応所望オブジェクトと類似のフォーマットを有し、確保メッセージに対する応答において送信される応答メッセージにおいて実現される。その機能性は、メディアセッションに関して確保されたそれぞれのＮＳＩＳルータにおけるリソースのメディア適応記述（パラメータＩＤ＝４）を含むことによって、確保されたリソースを確認することである。
ＭｅｄｉａＳｐｅｃオブジェクトおよびパラメータ記述
以下の節は、本発明の異なる実施形態によるＭｅｄｉａＳｐｅｃ記述フィールドに含まれる異なるオブジェクトのさらに詳細な定義を提供する。
制御情報オブジェクト
ＭｅｄｉａＳｐｅｃ制御情報オブジェクトは、オブジェクトＩＤ（Ｏｂｊｅｃｔ ＩＤ）（たとえば、Ｏｂｊｅｃｔ ＩＤ＝０）によって識別され、この実施形態によれば、各ＮＳＬＰメッセージに関して必須である。
本発明の実施形態によれば、制御情報オブジェクトの異なるフォーマットが提供され、それらのパラメータＩＤに基づいて識別されてもよい。
第１のフォーマットは、＜ＭｅｄｉａＳｐｅｃ Ｈｏｐｓ＞フォーマット（パラメータＩＤ＝１）と呼ばれる。この制御情報オブジェクトに含まれるデータは、本願明細書に定義されるＮＳＩＳメディアフォーマット適応ＮＳＬＰメッセージを理解するＮＳＩＳエンティティ、本願明細書の用語によればＮＳＩＳルータの数を示す。この数は、ＭｅｄｉａＳｐｅｃ Ｈｏｐｓフィールドに含まれる。各メディア適応可能ＮＳＩＳルータは、このカウンタを１つずつ増大する。
＜ＭｅｄｉａＳｐｅｃ Ｈｏｐｓ＞フォーマットは、以下のように定義されてもよい。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=0 | Parameter ID=1| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// MediaSpec Hops //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
別のフォーマットは、＜Ｉｎｓｐｅｃｔ Ｎｅｉｇｈｂｏｒｈｏｏｄ＞フォーマット（パラメータＩＤ＝２）であり、ＮＳＩＳルータが制御情報オブジェクトを含むメッセージをオンパスでない（たとえば、「探索するためのホップ距離」が（“０”）に等しい場合にはいいえであり、他の場合には、はいである）他のＮＳＩＳルータに転送するべきかどうかを指定する。このパラメータを含む照会メッセージは、“Ｄｅｃｒｅａｓｉｎｇ ｃｏｕｎｔ ｏｆ ｈｏｐｓ”カウンタが訪れたＮＳＩＳルータごとに１ずつ減少される点を除き、ＮＳＩＳルータのすべてのインターフェイスで（それを受信する１つを除き）複製可能であってもよく、変更されないまま送信されてもよい。このメッセージは、以下のフォーマットを有する。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=0 | Parameter ID=2| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Hop distance to explore //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Decreasing count of hops //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
さらに具体的に言えば、＜Ｌｅｎｇｔｈ＞フィールドは、上記の両方の例において、このフィールドの後に、ペイロードのバイトで、パラメータの長さを示す。＜Ｈｏｐ Ｄｉｓｔａｎｃｅ ｔｏ ｅｘｐｌｏｒｅ＞フィールドは、メッセージを受信するホップまたはＮＳＩＳエンティティの数を示し、別のメディア適応機能を検査するものとする。この数は、減少されない。
さらに、ホップの数を制限するために、メッセージは、「オフパス」で伝搬され、減少される＜Ｄｅｃｒｅａｓｉｎｇ ｃｏｕｎｔ ｏｆ ｈｏｐｓ＞フィールドが含まれる。２つのカウンタに関する理由は、制御情報オブジェクトを含むメッセージを受信するＮＳＩＳルータの転送挙動の制御である。両方のカウンタ値が同一である（０とは異なる）場合には、ＮＳＩＳルータは、２つのインターフェイス、すなわちメッセージが受信されたインターフェイスと、他の端末に対してオンパスであるインターフェイス以外のすべてにメッセージを転送する。そうでない場合には、ＮＳＩＳルータは、メッセージを受信したインターフェイス以外のＮＳＩＳルータのすべてのインターフェイスにメッセージを転送する。
メディア適応所望オブジェクト
メディア適応所望オブジェクト（ＩＤ＝３または４を有するパラメータの少なくとも１つを含む）は、（照会または確保のために）所望のメディア適応機能の記述を含む。各ＮＳＩＳルータは、オブジェクトを検証し、メディア適応利用可能オブジェクトにおいて適合する機能を含む。このオブジェクトに含まれる少なくとも２つのパラメータがある。照会メッセージにおいてメディア適応機能を照会するためのＩＤ＝３を有するパラメータと確保メッセージにおけるオブジェクトを含む場合に、リソースを確保するためのＩＤ＝４を有するパラメータである。
フォーマットは、たとえば、以下のようであってもよい。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=1 | Parameter ID=3| Length (bytes) | MAID=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Description //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter ID=3| Length (bytes)| MAID=2 | //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+- //
// Media Adaptation Description //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
このパラメータ（ＩＤ＝３）を含むメディア適応所望オブジェクトは、オブジェクトを含むメッセージを受信する各ＮＳＩＳルータによって解析され、照会メッセージにおけるメディア適応利用可能オブジェクトの含有を始動してもよく、メディア適応利用可能オブジェクトは、応答メッセージにおいて照会メッセージの開始プログラムに返す。
パラメータＩＤ＝４を有するメディア適応所望オブジェクトは、以下の例示のフォーマットを有してもよい。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=1 | Parameter ID=4| Length (bytes) | MAID=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource Session ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation E2E Session Footprint //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Description //
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Parameter ID=4| Length (bytes)| MAID=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource Session ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation E2E Session Footprint //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Description //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
上述したように、ＩＤ＝４を有するパラメータを含むメディア適応所望オブジェクトは、Ｍｅｄｉａ Ａｄａｐｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎフィールドに記載されているように、端末（またはそれらのプロキシ）が要求されたメディア適応リソースを確保することを可能にする。確保が成功した場合には、確保の詳細（すなわち、いずれのリソースが確保されたかに関するメディア適応の正確な記述）を含むＩＤ＝４を有するパラメータが、以下のメディア適応確保済みオブジェクトの中で、応答メッセージに返される。そうでない場合には、パラメータＩＤ＝６を含むメディア適応所望オブジェクトが、返され、リソースの確保の失敗の原因を示してもよい。
確保メッセージにおいて、メディア適応所望オブジェクトに含まれるＩＤ＝４を有するパラメータは、「ポップオフ」される、すなわち、一旦、確保が成功すると、オブジェクトから除去される。メディア適応に関して順が重要であるため、ＩＤ＝４を有するパラメータは、確保メッセージにおいてメディア適応所望オブジェクトの中で順序付けがなされる。
上記で定義したフィールドの意味は、以下の通りである。＜ＭＡＩＤ＞フィールドは、メディア適応ＩＤを示す。ＭＡＩＤは、いずれのメディア適応記述が言及されるかを識別する。照会メッセージに対する応答のために、照会に適合し、自発的にリソースを許可する２つ以上のメディア適応リソースがあってもよい。すなわち、メディア適応利用可能オブジェクトにおいて、同じＭＡＩＤを有し、ＩＤ＝５を有する複数のパラメータが存在してもよい。しかし、確保メッセージにおいて、ＭＡＩＤ値ごとにＩＤ＝４を有するパラメータは１つのみであってもよい。
＜Ｎｅｔｗｏｒｋ ＩＤ＞フィールドは、メディア適応リソースがアドレス指定可能であるノードを識別する全体にわたって一意のネットワークＩＤを含む。これは、たとえば、一連のメディア適応リソースの集合のホストであるノード（たとえば、ＮＳＩＳルータ）に対する識別子であってもよい。含まれるネットワークＩＤは、必ずしもリソース自体のＩＤでなければならないわけではなく、それを管理するＮＳＩＳルータのネットワークＩＤであってもよい。たとえば、ＩＰｖ６アドレスまたは他の種類のグローバル識別子、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇで利用可能なＩＥＴＦインターネットドラフト「Ｈｏｓｔ Ｉｄｅｎｔｉｔｙ Ｐｒｏｔｏｃｏｌ Ａｒｃｈｉｔｅｃｔｕｒｅ」（ｄｒａｆｔ−ｉｅｔｆ−ｈｉｐ−ａｒｃｈ−０３．ｔｘｔ）に基づくＨＩＴタグなどが、ネットワークＩＤとして用いられてもよい。いくつかの場合には、たとえば、現在開発中のＶＰＮ（仮想プライベートネットワーク）技術などのＩＰ−ｉｎ−ＩＰトンネルを介して仮想化の場合には、このＩＤはグローバルな一意性を必ずしも有していなくてもよい。これらの場合には、ネットワークＩＤ（たとえば、ＩＰアドレス）はトンネリングを介して形成された「仮想ネットワーク」内で一意であれば十分である。リソースがオンパスで見つけられず、他の手段、ＩＰトンネルまたは他の手段などの可能なオフパス通信を介して達しなければならない場合には、ネットワークＩＤもまた、有用であってもよい。
＜Ｍｅｄｉａ Ａｄａｐｔａｔｉｏｎ Ｒｅｓｏｕｒｃｅ ＩＤ＞フィールドは、アプリケーションＩＤを含む。アプリケーションＩＤは、たとえばトランスコーダ、フロースプリッタなどのネットワークＩＤによって識別されるノードにおけるメディア適応リソースを識別する。メディア適応リソースＩＤは、たとえば、ＳＩＰ ＵＲＩであってもよい。
さらに、＜Ｍｅｄｉａ Ａｄａｐｔａｔｉｏｎ Ｒｅｓｏｕｒｃｅ Ｓｅｓｓｉｏｎ ＩＤ＞フィールドは、現在のメディア適応パスにおけるリソースによって用いられるすべてのセッション識別子の中で一意のセッション識別子を含む。この識別子は、メディア適応ノード（ＮＳＩＳルータ）が提示するリソース、たとえば、一定の入力／出力パラメータを有するトランスコーディングアプリケーションの特定のセッションをアドレス指定するために用いられる。要求時に、メディア適応リソースは、この識別子を発行し、この識別子は、セッションの構造が変更または調整されなければならない場合には常に用いられる。これは、複数のメディアデータパスが同一のメディア適応リソースを同時に用いることを可能にする。Ｍｅｄｉａ Ａｄａｐｔａｔｉｏｎ Ｒｅｓｏｕｒｃｅ Ｓｅｓｓｉｏｎ ＩＤは、メディア適応リソースがサービス中であるすべてのセッションの中で一意であってもよい。Ｍｅｄｉａ Ａｄａｐｔａｔｉｏｎ Ｒｅｓｏｕｒｃｅ Ｓｅｓｓｉｏｎ ＩＤフィールドは、その利用可能なメディア適応機能が照会の機能に適合し、セッションに自発的に割り当てられる訪れたＮＳＩＳルータにおいて、メディア適応リソースによって発行される。
＜Ｍｅｄｉａ Ａｄａｐｔａｔｉｏｎ Ｅ２Ｅ Ｓｅｓｓｉｏｎ Ｆｏｏｔｐｒｉｎｔ＞フィールドは、任意に含まれてもよく、パケットを実際に処理するエンドポイントノードを貸すためにメディア適応リソースによって挿入される識別子を含む。たとえば、この“ｆｏｏｔｐｒｉｎｔ”は、識別されるＣｏｎｔｒｉｂｕｔｉｎｇ Ｓｙｎｃｈｒｏｎｉｚｉｎｇ Ｓｏｕｒｃｅまたはｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇで利用可能なＣＳＲＣ ｏｆ ｔｈｅ Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ、ＲＦＣ３５５０であってもよい。
ＲＴＣＰパケットは、この場合には確保されるメディア適応リソースである寄与ソースを含む各同期ソースから受信されるパケットの数を記録するため、この情報は、経路指定またはメディア適応ノードの失敗を検出するために有用である。確保される異なるメディア適応リソースによって用いられるフットプリントは、いずれのノードが受信されるデータを処理するかをエンドポイントに明示的に通知するために、エンドポイントに通信されてもよい。このフットプリントの通信は、前提条件フレームワークに対する提案された拡張、“ａ＝ｉｎｔｅｒｍｅｄｉａｔｅ：”を用いて、ＳＩＰにおいて更新メッセージを介して行われる。
＜Ｍｅｄｉａ Ａｄａｐｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ＞フィールドは、探索される機能性の記述を含む。
説明の目的のために、トランスコーディング処理のために所望の必要な構成は、以下のようにＳＤＰｎｇにおいて表現されることができる。
<sdpng xmlns="http://www.iana.org/sdpng"
xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:rtp="http://www.iana.org/sdpng/rtp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iana.org/\
sdpng sdpng-base.xsd
http://www.iana.org/sdpng/rtp/sdpng-rtp-pkg.xsd
http://www.iana.org/sdpng/video/sdpng-rtp-video-\
txcodec-pkg.xsd"

owner="txcoding-service@example.com" id="98765432" \
version="1">
<cap>
<rtp:udp name="rtpudpip6">[...]</rtp:udp>
</cap>
<def>
<rtp:udp name="rtp-def" ref="rtp:rtpudpip6">
<rtp:pt-in>31</rtp:pt-in>
<rtp:pt-out>32</rtp:pt-out>
</rtp:udp>
</def>
<cfg>
<video:txcodec name="h263plus-mpg-txcodec">
<video:input-encoding>H.263+</video:encoding>
<video:input-resolution>QCIF</video:resolution>
<video:input-framerate max="30"/>
<video:ouput-encoding>MPEG-4</video:output-format>
<video:output-resolution>QCIF</video:resolution>
<video:output-framerate max="30"/>
</video:txcodec>
</cfg>
<constraints>
[...where applicable...]
</constraints>
</sdpng>
複数のリソースの確保が必要である場合には、メディア適応は順番が必要である場合があるため、オブジェクトは、確保順にＩＤ＝４を有する複数のパラメータを含む。たとえば、最初に、ビデオおよびオーディオを分離することなく、ビデオをトランスコードすることを可能ではないと思われる。
メディア適応リソースが、１つの端末から別の端末へのメディアデータパス上にない場合には、「デフォルトのメディアデータパス」からのずれが必要とされることを暗示する所望のメディアフォーマット適応に関して必要なリソースを管理する「オフパス」のＮＳＩＳルータに対するトンネルを確立するために、Ｎｅｔｗｏｒｋ ＩＤが用いられる。ＮＳＩＳルータが、要求されたメディア適応リソースがそれ（Ｎｅｔｗｏｒｋ ＩＤアドレスは、自身のアドレスとは異なる）によってホストとならないことを検出する場合には、示されたＮＳＩＳルータに対するトンネルを確立されてもよく、Ｍｅｄｉａ Ａｄａｐｔａｔｉｏｎ Ｒｅｓｏｕｒｃｅ ＩＤおよびＭｅｄｉａ Ａｄａｐｔａｔｉｏｎ Ｓｅｓｓｉｏｎ ＩＤを用いて、メディア適応処理を要求してもよい。
メディア適応利用可能オブジェクト
上記で示したように、このオブジェクトは、照会メッセージおよび確保メッセージに対する応答に含まれてもよい。このオブジェクトは、照会メッセージに含まれ、また開始プログラムに返される応答メッセージにも含まれる。メディア適応利用可能オブジェクトは、以下の構造を有してもよい。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=2 | Parameter ID=5 | Length (bytes)| MAID=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nr hops | Nr hops | |
| to source | away from path| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource Session ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource Cost //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation E2E Session Footprint //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Description //
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Parameter ID=5 | Length (bytes)|MAID=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nr hops | Nr hops | |
| to source | away from path| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
// Network ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource Session ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource Cost //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation E2E Session Footprint //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Description //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
上記で分かるように、オブジェクトは、特定のＮＳＩＳルータまたは一連のルータで確保のために利用可能である１つまたは複数の利用可能なメディア適応アプリケーションセッション、たとえばＩＤ＝５を有する複数のパラメータを含む。これらのリソースの利用可能性は、一過性の状態を有する。リソースが所与の時間後に確保されない場合には、割り当てられたリソースおよび特別に作成された識別子であるＭｅｄｉａ Ｓｅｓｓｉｏｎ ＩＤおよびＥ２Ｅ Ｓｅｓｓｉｏｎ Ｆｏｏｔｐｒｉｎｔが期限切れとなる。これは、不必要な確保を回避することである。
このような態様で、＜Ｍｅｄｉａ Ａｄａｐｔａｔｉｏｎ ＩＤ＞は、メディア適応所望オブジェクトにおいて適合するパラメータ（ＩＤ＝４）を識別するために必要とされ、メディア適応利用可能オブジェクトにおけるこの（これらの）パラメータ（ＩＤ＝５）が応答する。同一のＭｅｄｉａ Ａｄａｐｔａｔｉｏｎ ＩＤを有するそのようなパラメータは、代替である。
以下のフィールドは、訪れたノード、すなわちそれらの機能が照会の機能と適合し、自発的にリソースに割り当てられるとき、オブジェクトを含むメッセージが通過するそれらのＮＳＩＳルータによって満たされている。＜Ｎｒ ｈｏｐｓ ｔｏ ｓｏｕｒｃｅ Ｃｏｕｎｔ＞フィールドは、メッセージが開始ＮＳＩＳエンティティ（たとえば、端末１１０または１２２またはそれぞれにそれらのプロキシ）から転送されるホップの数を指定する。＜Ｎｏ Ｈｏｐｓ ａｗａｙ ｆｒｏｍ ｐａｔｈ＞フィールドは、リソースがデフォルトのメディアデータパスで見つからない場合に用いられ、メディア適応リソースがデフォルトのメディアパスから離れるホップの数を記述する。
＜Ｍｅｄｉａ Ａｄａｐｔａｔｉｏｎ Ｒｅｓｏｕｒｃｅ Ｃｏｓｔ＞フィールドは、このノードでこの処理を確保するコストを示す。コストは、任意の種類のコスト距離であってもよい。別のパラメータが定義されてもよく、それぞれが異なるコストモデルを含む。
＜Ｎｅｔｗｏｒｋ ＩＤ＞フィールド、＜Ｍｅｄｉａ Ａｄａｐｔａｔｉｏｎ Ｒｅｓｏｕｒｃｅ ＩＤ＞フィールド、＜Ｍｅｄｉａ Ａｄａｐｔａｔｉｏｎ Ｒｅｓｏｕｒｃｅ Ｓｅｓｓｉｏｎ ＩＤ＞フィールドおよび＜Ｍｅｄｉａ Ａｄａｐｔａｔｉｏｎ Ｅ２Ｅ Ｓｅｓｓｉｏｎ Ｆｏｏｔｐｒｉｎｔ＞フィールドは、上述したように、類似の機能性を有する。
＜Ｍｅｄｉａ Ａｄａｐｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ＞フィールドは、見つかったメディア適応リソースで利用可能な機能性の記述を含む。以下は、上記のＳＤＰｎｇの例を再使用する。
<sdpng xmlns="http://www.iana.org/sdpng"
xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:rtp="http://www.iana.org/sdpng/rtp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iana.org/\
sdpng sdpng-base.xsd
http://www.iana.org/sdpng/rtp/sdpng-rtp-pkg.xsd
http://www.iana.org/sdpng/video/sdpng-rtp-video-\
txcodec-pkg.xsd"

owner="txcoding-service@example.com" id="98765432" \
version="1">
<cap>
<rtp:udp name="rtpudpip6">
<rtp:pt-in>31 34</rtp:pt-in>
<rtp:pt-out>32 35</rtp:pt-out>
</rtp:udp>
</cap>
<cfg>
<video:txcodec name="h263plus-mpg-txcodec">
<video:input-encoding>H.263+</video:encoding>
<video:input-resolution>QCIF</video:resolution>
<video:input-framerate max="30"/>
<video:ouput-encoding>MPEG-4</video:output-format>
<video:output-resolution>QCIF</video:resolution>
<video:output-framerate max="30"/>
</video:txcodec>
</cfg>
<constraints>
[...where applicable...]
</constraints>
</sdpng>
上記の記述は、この記述を作成したメディア適応リソースが、Ｈ２６３、同一の解像度およびフレーム速度でＭＰＥＧ−４ビデオに対して最大毎秒３０フレームのＱＣＩＦ解像度に基づくトランスコーディングをサポートすることを示す。また、コーデックのコーデック特有のパラメータを理解するために、別のパッケージが必要とされることを留意されたい。これは、ｈｔｔｐ：／／ｗｗｗ．ｉａｎａ．ｏｒｇ／ｓｄｐｎｇ／ｖｉｄｅｏ／ｓｄｐｎｇ−ｒｔｐ−ｖｉｄｅｏ−ｔｘｃｏｄｅｃ−ｐｋｇ．ｘｓｄから検索されることができる。
類似の態様において、ＳＤＰｎｇ規則に基づいて、他のトランスコーディングパラメータが表現されてもよい。記述のみが機能および１つの構成について言及することを留意されたい。また、いくつかの代替構成と、適用可能であれば制約条件とがあってもよい。しかし、これは、単なるメディア適応利用可能オブジェクトであるため、定義はなく、確保が行われないため、構成タグ（または要素）もない。ＳＤＰｎｇが＜ｃｆｇ＞タグおよび＜ａｌｔ＞タグの下での代替構成を列挙する可能性があることもまた、留意されたい。また、範囲およびパラメータリストも可能であることを留意されたい（ＲＴＰペイロードタイプの範囲は、ｒｔｐ：ｐｔで明示的に列挙されてもよい）。
メディア適応確保済みオブジェクト
このオブジェクトは、確保されたリソースを確認する。通常の動作において、そのパラメータは、確保メッセージにおいて送信されたパラメータＩＤ＝４を有するメディア適応所望オブジェクトと同一の情報を含む。しかし、ローカルポリシーのために、ＮＳＩＳルータまたはそのリソースは、リソースが利用可能であるポートなど、セッションの詳細を変更することが可能であってもよい。
メディア適応確保済みオブジェクトは、メディア適応確保が失敗したことを示すために、新たなパラメータであるパラメータＩＤ＝６を必要とする。これは、エラーコードを用いて確保の失敗および十分な確保のための提案について知らせる。以下の実施例は、第１の確保が成功し、第２の確保が成功しなかったことを示す確保メッセージを発行した端末（またはそのプロキシ）を知らせるパケット構造を示す。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=3 | Parameter ID=4| Length (bytes) | MAID=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource Session ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation E2E Session Footprint //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Description //
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Parameter ID=6| Length (bytes)| MAID=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource Session ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation E2E Session Footprint //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Failed Media Adaptation Description //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Error Code (reason of failure //
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Proposed New Media Adaptation Description //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ＮＳＩＳルータにおけるメッセージ処理
任意に、上記で提案されたＮＳＩＳメディアフォーマット適応ＮＳＬＰのシグナリングメッセージは、認証手順が成功して達成された（通常、ＰＯＬＩＣＹ＿ＤＡＴＡオブジェクトがメッセージにおいて実行される）後、ＮＳＩＳルータで処理されるだけであってもよい。
照会メッセージの処理
メディア適応所望オブジェクトを含む照会メッセージが、照会が通過した各ＮＳＩＳルータによって解析される。要求される各メディア適応処理およびその関連パラメータが、解析される。ＩＤ＝１を有するパラメータのメディア適応記述に含まれる要求処理が利用可能である場合には、メディア適応利用可能オブジェクトは、それぞれのＮＳＩＳルータによって照会メッセージに含まれる。この照会メッセージは、メディア適応処理の機能、定義、構成および情報を反映するパラメータ（ＩＤ＝５）を含む。メディア適応利用可能オブジェクトおよびメディア適応所望オブジェクトに含まれるパラメータは、ＭＡＩＤによってリンクされる。同じＭＡＩＤを含む複数のパラメータは、等価な機能または類似の機能を提供する異なる代替のＮＳＩＳルータを表す。
確保の照会端末は、一方または他方の利用可能な処理を選んでもよい。利用可能な代替がある場合には、いずれのメディア適応リソースを利用するかに関する端末の決定は、たとえば、利用可能なリソースのそれぞれの１つへのホップの数、それぞれのリソースを利用するために必要なコスト（たとえば、待ち時間）または他の測定基準に左右されてもよい。トランスコーダ（および一般に任意の適応）は、ＲＴＰペイロードタイプなどのパケットペイロードにおけるいくつかの属性を変更する可能性があるため、利用可能なメディア適応リソースに関する詳細の情報が必要である場合もある。たとえば、フォーマットＸからＹへの変化のために必要な２つの適応処理ステップ（Ｘ→Ｙ’→Ｙ”→Ｙ）がある場合には、確保が各メディアストリーム（“ｍ＝”の行）における“ａ＝”の行に関する正確な入力および出力ペイロードタイプ数を含むように、Ｙ’およびＹ”は、記述において利用可能なペイロードタイプの範囲を含む必要がある。処理機能の正確な仕様は、確保状態をメディアストリームに関連付けることができるように拡張するために重要である。処理機能の正確な仕様はさらに、確保メッセージ要求の送信者側の場合には、後に与えられたリソースの確保を可能にしてもよい。
リソースが要求中の端末によって確保されることができないか、または要求されたメディア適応処理がサポートされない場合には、メッセージは、ＮＴＬＰ経路指定によって決定されるように、変更することなく、次のオンパスＮＳＩＳルータに転送される。
確保メッセージの処理
確保メッセージは、照会メッセージとして処理される。照会メッセージとは対照的に、確保メッセージは実際に、各ＭＡＩＤに関するメディア適応リソースを確保する。さらに、確保メッセージにおいて、ＩＤ＝４を有するパラメータにおけるメディア適応記述は、任意の値範囲を含むではなく、リソース確保に関する一定値のみが明示される必要がある。各ＮＳＩＳルータで、１入力および１出力のパラメータが、各メディア適応処理に関してインスタンスを作成されなければならない。確保メッセージは、一連の順番で並べられたメディア適応ステップを含むため、確保メッセージにおいて、確保されるメディア適応処理を表すパラメータＩＤ＝４を有するメディア適応所望オブジェクトの各パラメータは、一旦処理されると除去される。
たとえば、フォーマットＹ’への変換の出力ペイロードタイプおよびフォーマットＹ” への変換の入力ペイロードタイプが同一の値をとるように、続くＮＳＩＳルータにおけるメディア適応確保に関するパラメータ設定が適合される。この適合は、次の確保の設定（パラメータＩＤ５または６）を搬送する応答メッセージによって確認（または拒否）される。
応答メッセージの処理
応答メッセージは、２つの主な用途を有し、
・照会メッセージへの応答として作用する場合には、開始プログラムに戻す利用可能なメディア適応リソースに関する情報を搬送し、
・確保メッセージへの応答として作用する場合には、次のＮＳＩＳルータにおける確保の成功を確認する。
メディア適応機能探索
前述したように、オーバレイネットワークにおいてメディア適応機能を探索するための２つの可能性が可能である。
・オンパス探索‐この探索オプションは、所望のメディア適応機能を提供するメディアデータパスにおけるＮＳＩＳルータを検出するために、ＮＳＩＳシグナリングのためのオンパスオプションを利用する。照会メッセージを受信するメディアデータパスにおける各ＮＳＩＳルータは、メディア適応所望オブジェクトおよびメディア適応利用可能オブジェクトを検査し、それらの利用可能性に基づいて、それらのオブジェクトを修正する。この単純化した手法の欠点は、メディアデータパスにおけるすべてのリソースがピアに遭遇する確率がきわめて低い恐れがあることである。
・オフパス探索（近接探索）‐この探索オプションによれば、各ＮＳＩＳルータは、その機能に関してメディアデータパス上以外にある隣接する「近隣の」ＮＳＩＳルータにも照会する。
オンパス探索
オンパス探索は、既に上述しており、そのメッセージの流れもまた、図５において示されたものと類似である。照会端末は、セッションを確立するために、ピア端末にメディアデータパスに沿って照会メッセージを送信する。オンパス上のＮＳＩＳルータは、照会を処理し、照会が適合する場合にはメディア適応機能に関する記述に照会を追加する。次に、記述は、照会端末に送り返され、選択されたＮＳＩＳルータにおける照会リソースおよび確保リソースのメディア適応必要条件を満たすＮＳＩＳルータを選択する。
近接探索
オフパス探索の場合には、異なる実現が、以下で提案される。
基本動作Ｍｏｄｕｓ−Ｐｕｌｌ動作
基本動作モーダス（ｍｏｄｕｓ）において、近接探索のための挙動は、オンパスにあるＮＳＩＳルータに対して「近隣の」ＮＳＩＳルータの利用可能な機能を照合することである。近隣のＮＳＩＳエンティティ（ＮＥ）またはＮＳＩＳルータは、ＮＳＩＳメッセージを現在処理中であるＮＳＩＳルータから１つまたは複数のホップであるＮＳＩＳエンティティとして定義される。たとえばＧＩＭＰＳにおけるように標準的なＮＴＬＰプロトコルにおいて、各ＮＥは、いわゆる近隣のＧＩＭＰＳノードから１回のホップで他のＮＥを認識している。ＧＩＭＰ経路指定状態維持のためのこの機構は、既に上述したＩＥＴＦインターネットドラフト「ＧＩＭＰＳ：Ｇｅｎｅｒａｌ Ｉｎｔｅｒｎｅｔ Ｍｅｓｓａｇｉｎｇ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｓｉｇｎａｌｉｎｇ」において、ＧＩＭＰＳピア発見機構に記載されている。
基本モーダスにおいて、新たに提案されたＮＳＩＳメディアフォーマット適応ＮＳＬＰの近接探索のために、動作は、「プル（ｐｕｌｌ）」モデルに基づいて行う。すなわち、ＮＳＩＳルータ（またはＮＥ）は、要求に応じて、近隣のＮＳＩＳルータから情報を検索する。
本発明の実施形態によれば、この機構は、以下のように実現されてもよい。
・照会メッセージの局所処理：照会が適合され、ＮＳＩＳルータが自発的にリソースを割り当てられる場合には、訪れた各ＮＳＩＳルータは、メディア適応利用可能オブジェクトに機能記述（ＩＤ＝５を有するパラメータ）を含む。
・各オンパスＮＳＩＳルータは、制御情報オブジェクトにおけるパラメータ“Ｈｏｐ ｄｉｓｔａｎｃｅ ｔｏ ｅｘｐｌｏｒｅ”が０でないことを示す照会メッセージを受信したときには、メッセージをメディアデータパスにはない（オフパスの）近隣ＮＳＩＳルータに転送する。
・さらに、照会メッセージが通過される各オフパスＮＳＩＳルータは、メッセージの転送時に“Ｄｅｃｒｅａｓｉｎｇ ｃｏｕｎｔ ｏｆ ｈｏｐｓ”を１つずつ減少させる。
・照会メッセージを受信する各オフパスＮＳＩＳルータは、照会を照会メッセージが受信されたインターフェイスを除くそのインターフェイスに転送する。
・オフパスＮＳＩＳルータに照会した各ＮＳＩＳルータは、オンパスＮＳＩＳルータにさらに照会メッセージを転送する前に、各照会メッセージに関して利用可能なメディア適応機能を含む応答メッセージが到着するまで待機する。
オフパスで次の近隣のＮＳＩＳルータからの応答メッセージの到着時には、オフパスＮＳＩＳルータは、１つの応答メッセージにおけるメディア適応利用可能オブジェクトのすべてのパラメータをコンパイルする。
・このコンパイルされた応答メッセージを受信する各オンパスＮＳＩＳルータは、メディア適応利用可能オブジェクトを抽出し、そのオブジェクトを照会メッセージに含み、「更新された」照会メッセージをメディアデータオンパスに位置する次のＮＳＩＳルータに向かって転送する。
・最終的には、所与の“ｈｏｐ ｄｉｓｔａｎｃｅ ｔｏ ｅｘｐｌｏｒｅ”のオンパスルータおよびオフパスルータの利用可能なすべての機能に関する応答メッセージは、探索の開始プログラムに到着する。
この基本アルゴリズムループにおいて、照会メッセージの伝搬パスにおけるループが回避されるのではなく、カウンタが０の値に達するか、または他のＮＳＩＳルータが配されないとき、応答メッセージが始動され、それによって、照会メッセージの伝搬を終了することからループは有害ではないと思われることを留意されたい。
本発明の説明のための実施形態によれば、照会メッセージを転送し、それに対する応答メッセージを受信するこの動作は、セッションが、端末１１０と１２２との間で確立されると仮定する図１０〜図１２において示される。パケット交換型ネットワークにおけるメディア適応リソースの検出は、端末１１０から端末１２２へのメディアパスに関して示される。図１０において、端末１１０のＳＩＰユーザエージェントは、プロキシ１０８とインターフェイスをとり、それぞれのネットワークノードを接続する太線によって示される端末１１０から端末１２２へのデフォルトのメディアパスから３回以上のホップを行う（Ｈｏｐ ｄｉｓｔａｎｃｅ ｔｏ ｅｘｐｌｏｒｅフィールドは、値２に設定）メディア適応リソースに関する近接探索をプロキシ１０８に開始させる。
プロキシ／ＮＳＩＳルータ１０８は、オンパスで唯一の隣接するＮＳＩＳルータ１０５を有し、照会が適合され、ＮＳＩＳルータがリソースに自発的に割り当たられる場合には、プロキシ／ＮＳＩＳルータ１０８は、そのメディア適応機能の記述を照会メッセージに追加し（たとえば、メディア適応利用可能オブジェクトを追加する）、「更新された」照会メッセージをＮＳＩＳルータ１０５に転送する。ＮＳＩＳルータ１０５はまた、オフパスの近隣ルータに隣接していないため、そのメディア適応機能の記述を照会メッセージに追加し、照会メッセージを次のオンパスＮＳＩＳルータ１０４に転送する。
ＮＳＩＳルータ１０４は、２つの近隣オフルータ、すなわちＮＳＩＳルータ１０６および１０２を有する。照会メッセージを次のオンパスＮＩＳルータ１０３にさらに送る前に、ＮＳＩＳルータ１０４はそのオフパス近隣ＮＳＩＳルータ１０６および１０２に照会し、照会に対するそれらの応答メッセージを待ち受ける。ＮＳＩＳルータ１０２は、（Ｈｏｐ ｄｉｓｔａｎｃｅ ｔｏ ｅｘｐｌｏｒｅフィールドにおいて）ホップカウンタを照合し、２から１に値を減算する。カウンタ値が０でないとき、ＮＳＩＳルータ１０２は、照会メッセージをＮＳＩＳルータ１０３だけであるその近隣のＮＳＩＳルータに転送する。ＮＳＩＳルータ１０３は、減算後、ホップカウンタが０に等しいことを検出すると、照会メッセージは、さらに伝搬される必要がなくなる。ＮＳＩＳルータ１０２は、ＮＳＩＳルータ１０３からの応答メッセージを待ちうけ、その応答メッセージを評価し、ＮＳＩＳルータ１０４への応答メッセージを形成するためにその中に情報を集める。
ＮＳＩＳルータ１０４は、ＮＳＩＳルータ１０２および１０６から受信された応答メッセージを評価する。ＮＳＩＳルータ１０３がそのメディア適応機能の記述を追加した場合には、ＮＳＩＳルータ１０４は、ＮＳＩＳルータ１０２から受信された応答メッセージにおける情報およびＮＳＩＳルータ１０３が次のオンパスＮＳＩＳ使用可能ノードであるという知識のために、オーバレイネットワークにおけるループを検出してもよい。さらに、ＮＳＩＳルータ１０４は、受信された応答メッセージにおいてメディア適応機能を解析し、したがって、そのメディア適応機能もまた考慮する照会メッセージを更新する。続いて、更新された照会メッセージをメディアデータパス（図示せず）における次のＮＳＩＳルータ１０３に転送する。
今度は図１１に目を向けると、動作は、ＮＳＩＳルータ１０４の１つに本質的に類似しているため、ＮＳＩＳルータ１０３の動作が簡単に説明される。また、ＮＳＩＳルータ１０３は、近接探索が行われることを検出し、したがって、照会メッセージを最初にＮＳＩＳルータ１０１および１０２に転送する。ＮＳＩＳルータ１０１および１０２は、ホップカウンタを２から１に減算し、照会メッセージに対する応答メッセージを作成する前に、更新された照会メッセージをＮＳＩＳルータ１０４および１０７にさらに転送する。ＮＳＩＳルータ１０４および１０７にはいずれも応答メッセージを返す。それぞれ、ＮＳＩＳルータ１０１および１０２におけるこれらの応答メッセージの受信時に、これらのＮＳＩＳルータ１０１および１０２は、ＮＳＩＳルータ１０３に返される応答メッセージに対して、その中の情報と、自身のそれぞれのメディア適応機能の知識と、を集める。ＮＳＩＳルータ１０３はまた、ＮＳＩＳルータ１０１および１０２からの応答メッセージを評価し、続いて（この実施例では）ＮＳＩＳメディアフォーマット適応ＮＳＬＰ使用可能な端末１２２に送信される更新された照会メッセージに情報を集める。図１２に示されているように、端末１２２は、照会メッセージにおいて検出され、示されたメディア適応機能に関する情報を抽出し、ホップバイホップ方式で応答メッセージにおいて端末１１０に返される情報を提供する。
基本動作‐オフパスメディア適応リソースの利用
既に上述したように、たとえば、メディアデータパスで利用可能に位置していない要求されるメディア適応リソースのために、デフォルトのメディアデータパスからのずれが必要である場合において、Ｎｅｔｗｏｒｋ ＩＤがそれらのリソースを管理するそれらのＮＳＩＳルータへのトンネルを確立するために用いられてもよい。
それ（たとえば、Ｎｅｔｗｏｒｋ ＩＤはそれ自体のＩＤとは異なること）によって、確保されるメディア適応リソースがホストになっていないことをＮＳＩＳルータが検出すると、ＮＳＩＳルータは、そのＮＳＩＳルータへオフパスにおけるトンネルを確立し、Ｍｅｄｉａ Ａｄａｐｔａｔｉｏｎ Ｒｅｓｏｕｒｃｅ ＩＤおよびＭｅｄｉａ Ａｄａｐｔａｔｉｏｎ Ｓｅｓｓｉｏｎ ＩＤを用いて、その処理を要求してもよい。たとえば、いくつかのメディア適応リソースが、最も近いオンパスＮＳＩＳルータから遠くに配置されている場合には、デフォルトのメディアデータパスから離れたＮＳＩＳルータのメディア適応リソースをどのように利用するかについて、一般に２つのオプションがある。メディアデータパスがメディア適応リソースが利用される必要がある元来はオフパスのＮＳＩＳルータも組み込むように変更されるか、または、オフパスＮＳＩＳルータの機能を利用するために、少なくとも１つのトンネルがデフォルトのメディアデータパスにおける１つまたは複数のＮＳＩＳルータから確立されることができるかのいずれかである。後者のオプションを用いると、デフォルトのメディアデータパスは、変更されなくても済む。
図１３に目を向けると、ＮＳＩＳルータ１０２におけるメディア適応リソースの例示の確保が、示される。上記の図１０〜図１２に対して説明したように、端末１１０は、オンパスおよびオフパスで用いられることができるメディア適応リソースを記述する応答メッセージを受信した。ＮＳＩＳルータ１０２のみが、端末１２２とのセッションに必要とされるメディア適応を提供することができると仮定すると、端末１１０は、ＮＳＩＳルータ１０２にメディア適応リソースを確保しようとする。したがって、端末１２２は、ＮＳＩＳルータ１０２への確保メッセージの送信を開始する。確保メッセージが中間ＮＳＩＳルータ１０３で処理されると、中間ＮＳＩＳルータ１０３は、確保メッセージをＮＳＩＳルータ１０２に転送し、利用されるメディア適応リソースがデフォルトのメディアパスから離れることを検出する。したがって、この例示の実施形態によれば、ＮＳＩＳルータ１０３は、それ自体とＮＳＩＳルータ１０２との間のトンネルを設定する。セッション中に適応されるメディアデータストリームの受信時に、ＮＳＩＳルータ１０３は、確立トンネルによる変換のために、ストリームをフィルタリングし、そのメディアデータをＮＳＩＳルータ１０２に通過させる。ＮＳＩＳルータ１０２は、端末１２２に対してメディアパスに沿って次に転送される変換されたメディアストリームを戻す。
トンネリングを用いて、確保において、オフパスのリソースを含むことができるようにするために、ＮＳＩＳルータはトンネリング機能を実現することが必要であり、経路を記録し、トンネル確保を要求するために、以下で２つの別のパラメータをさらに実現してもよい。
確保を開始する端末（たとえば、端末１１０または１２２）は、それ自体と宛先端末との間の経路指定パスの周囲に、“ｎｅｔｗｏｒｋ ｇｒａｐｈ”を構築する。したがって、端末は、それが照会メッセージによってネットワークを既に探った範囲（Ｈｏｐ ｄｉｓｔａｎｃｅ ｔｏ ｅｘｐｌｏｒｅフィールド）に対するＮＳＩＳルータによって形成されるオーバレイネットワークのトポロジを認識する。したがって、端末は、ネットワークトポロジにおいて、オンパスおよびオフパスでＮＳＩＳルータのそれぞれまでの距離の知識（ホップにおいて測定される）もまた有する。
本発明の実施形態によれば、パスの周囲のトポロジを求めるために、ＮＳＬＰの意味論をさらに強化することが提案される。必要なメディア適応に関する照会のほかに、照会メッセージを受信した（オンパスおよびオフパスの両方における）すべてのＮＳＩＳルータの少なくともＮｅｔｗｏｒｋ ＩＤが、照会されたメディア適応機能に適合するかどうかに関係なく、記録される。
したがって、新たなパラメータが、照会メッセージ、たとえば上記で指定したメディア適応所望オブジェクトの中に含まれ、応答メッセージにおいて照会メッセージを受信したそのようなＮＳＩＳルータのネットワークＩＤを含めることを始動してもよい。したがって、ネットワークＩＤを搬送する別のパラメータが、応答メッセージ、たとえば上記で指定したメディア適応利用可能オブジェクトの中で提供されてもよい。
照会メッセージに関して、新たなパラメータ（たとえばＩＤ＝７を有する）は、例示の以下のフォーマットを有してもよい。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=1 | Parameter ID=7| Length (bytes) | MAID=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
０に設定されたＭＡＩＤは、照会メッセージを処理中であるＮＳＩＳルータに対して、メディア適応記述がメッセージに含まれないことを示す。照会メッセージにおいてこのパラメータを受信する各ＮＳＩＳルータは、メディア適応利用可能オブジェクトにおいて以下の例示のパラメータ（たとえば、ＩＤ＝８を有する）を含む。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=2 | Parameter ID=8 | Length (bytes)| MAID=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nr hops | Nr hops | |
| to source | away from path| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Record Route //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
“Ｒｅｃｏｒｄ Ｒｏｕｔｅ”フィールドは、探索方向において、訪れたノードのＮｅｔｗｏｒｋ ＩＤを含んでもよく、メッセージを処理した最も新しいＮＳＩＳルータは、そのネットワークＩＤを、たとえば、リストの最後に追加する。経路の設定および照会メッセージを開始する端末へのホップの数を相関させることによって、端末は、照会されたネットワークノードのネットワークトポロジを構築することができる。任意に、このネットワークトポロジは、必要なメディア変換のほか、最適な全体的ＱｏＳ性能をも提供するメディア適応リソースを選択するために、端末に用いられてもよい帯域幅または遅延などのＱｏＳ測定基準（単なるホップの数ではなく）を用いて、強化されてもよい。
一旦、ネットワークトポロジが周知となると、端末は、所望のメディア適応機能を提供するオフパスＮＳＩＳルータへの必要なトンネルのためにトンネルエンドポイントをアサートしてもよい。上述したように、トンネリングは、メディア適応パスにおいてオフパスノードを「含む」ために用いられる。
オフパスＮＳＩＳルータを含むために確立されるトンネルを示すために、新たなパラメータが、確保メッセージに追加される。パラメータは、カスケードおよび順序付き形式で、確立すべきトンネリングおよび必要な適応を記述する。
図１３に示される実施例に戻ると、ＮＳＩＳルータ１０２は、デフォルトのメディアデータパス（太い実線で示される）の外側に配置されるが、必要なメディア適応機能を提供する。ＮＳＩＳルータ１０２（トンネル宛先／ソースＡ’）を含めるために、ＮＳＩＳルータ１０４→ＮＳＩＳルータ１０２→ＮＳＩＳルータ１０３という三角形の経路指定が所望であると考えられ、その結果、メディアデータはＮＳＩＳルータ１０４の間でパスから離れ、ＮＳＩＳルータ１０３へのパスに再び組み込まれる。この目的のために、２つのトンネル（ＮＳＩＳルータ１０４→ＮＳＩＳルータ１０２とＮＳＩＳルータ１０２→ＮＳＩＳルータ１０３）が、確立される。
したがって、確保メッセージは、必要なメディアフォーマット適応（通常通り、前の照会において収集する）を示すＮＳＩＳルータ１０２に関して、メディアフォーマット適応記述（パラメータＩＤ＝４）と、確立すべきトンネルの記述と、を含む。ＮＳＩＳルータ１０４、１０２および１０３（それぞれ）の中で確立するためのトンネルを記述し、ＮＳＩＳルータ１０２におけるメディアフォーマット適応記述（パラメータＩＤ＝４）を含む新たなパラメータ、たとえば、ＩＤ＝９を有するパラメータが、定義されてもよい。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=3 | Parameter ID=9| Length (bytes) | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID of 1st Tunnel Source = NSIS router 104) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID of 1st Tunnel Destination= NSIS router 102 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
## media format adaptation description (parameter ID=4) for ##
## the necessary Media Adaptation to be reserved at A’ ##
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=3 | Parameter ID=8| Length (bytes) | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID of 2nd Tunnel Source = NSIS router 102) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID of 2nd Tunnel Destination= NSIS router 103 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
任意に、トンネリングは、ＮＳＩＳルータ１０３からＮＳＩＳルータ１０２に確立され、所望であるようなメディアフォーマットに適切に適合された後で、同様に、ＮＳＩＳルータ１０２からＮＳＩＳルータ１０３に戻るように確立されることができる。これは、第１および第２のトンネルのＴｕｎｎｅｌ ＤｅｓｔｉｎａｔｉｏｎおよびＴｕｎｎｅｌ Ｓｏｕｒｃｅを同一であるように、すなわちＮＳＩＳルータ１０２に変更することであろう。
任意に、複数のオフパスＮＳＩＳルータは、確保メッセージのペイロードにおいて、カスケードの形態で含まれることが可能である。
拡張動作‐Ｐｕｓｈ動作
本発明の別の実施形態において提案されたオフパスメディア適応リソースを検出して確保するための別の手法が、この節に記載される。実施形態によれば、オーバレイネットワークにおけるＮＳＩＳルータは、隣接するＮＳＩＳルータのほか、２回以上のホップで進むＮＳＩＳルータのローカルデータベースを維持する。ＮＳＩＳルータにおけるデータベース内容の作成は、ＮＳＩＳルータが他のＮＳＩＳルータに加入し、加入するＮＳＩＳルータの機能について知らせるいわゆる「プッシュ（ｐｕｓｈ）」通信モデルに基づいていてもよい。この動作は、ＲＦＣ１０５８、ヘドリック（Ｈｅｄｒｉｃｋ）による「Ｒｏｕｔｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｒｏｔｃｏｌ」（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇにおいて利用可能）に記載されたようなベクトル経路指定アルゴリズムに若干類似しており、このアルゴリズムによれば、各ノードは、その周知の経路を近隣のノードに送信し、全体的な経路指定ベクトル（この場合には、ＮＳＩＳルータおよびそれらの機能の全体マップ）が、ある期間の時間の後、いわゆる収束時間後に獲得される。
本発明のこの実施形態によって提案された機構は、以下のように作用する。本願明細書に記載されるＮＳＩＳメディアフォーマット適応ＮＳＬＰをサポートするピアＮＳＩＳルータの設定を求めた後、各ＮＳＩＳルータは、各ＮＳＩＳルータの機能および現在のリソース状態（たとえば、負荷、利用可能な格納機能など）の定期的な更新を受信するために加入するかどうかを決定する。加入は、加入メッセージをそれぞれのＮＳＩＳルータに送信することによって、実行されてもよい。加入メッセージは、照会メッセージと本質的に同一の構造を有してもよく、加入メッセージを受信したＮＳＩＳルータから通知メッセージの形で定期的な応答を始動する。
通知メッセージは、ＮＳＩＳルータによって定期的に送信され、それらの機能および任意に他のパラメータ、現在の負荷特性、利用可能なＣＰＵ性能または格納機能などを反映する。通知メッセージは、ＮＳＩＳルータが利用可能なメディア適応リソースに関する情報および任意に、他のＮＳＩＳルータにおけるＱｏＳリソースを収集し、ローカルデータベースにおいてこの情報を維持することを可能にする。ローカルデータベースにおいて維持される情報のタイプおよび量は、通知周期に著しく左右されてもよい。「リフレッシュ」時間が長い場合には、格納能力または利用可能なＣＰＵ性能のように、次の「リフレッシュ」までに期限切れになる迅速に変化する情報を格納するために用いられることはできない。
「収束時間」後に、時間におけるいくつかの時点で、各ＮＳＩＳルータは、そのネットワークにおいて、利用可能なＮＳＩＳルータおよび利用可能なその機能のリストを有する。メディアフォーマット適応ＮＳＬＰ照会メッセージがメディアデータパスにおけるＮＳＩＳルータによって受信される場合には、ＮＳＩＳルータは、メディア適応機能を探るために、オフパスで照会を転送する必要はないが、今度は、そのデータベースを考慮することができ、それによって、近隣のＮＳＩＳルータおよびそれを超えるルータで利用可能なメディア適応リソースを直ちに認識される。
以下は、通知メッセージが含みうる一連の機能および識別子を表す。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource Cost //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Description //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ｍｅｄｉａ Ａｄａｐｔａｔｉｏｎ Ｓｅｓｓｉｏｎ ＩＤもＦｏｏｔｐｒｉｎｔも含まれる必要がないことを留意されたい。これは、確保の意図を反映する照会メッセージの受信時にインスタンスを作成されるだけに過ぎないためである。
メディア適応処理の検出および確保とＱｏＳの検出および確保との組み合わせ
上述したものと類似の機構が、必要に応じて、ネットワークＱｏＳリソースの照会（検出）および確保を行うために用いられてもよい。端末１１０と端末１２２との間のメディアデータパスで、ＮＳＩＳルータによって提供されることができる利用可能なＱｏＳは、たとえば、その構造が本質的に類似であるＱｏＳ所望オブジェクトをメディア適応所望オブジェクトに追加することによって、上記の照会メッセージを拡張して照会されてもよく、満たさなければならないＱｏＳ制約条件の記述を含む。照会を処理中のＮＳＩＳノードはそれぞれ、メディア適応利用可能オブジェクトと本質的に同一の機能を有し、メディアパスに沿った各ＮＳＩＳルータまたは提供されることができる全体的な最小のＱｏＳのいずれかの機能を指定するＱｏＳ利用可能オブジェクトを追加してもよく、更新してもよく、照会に追加されるＱｏＳ利用可能オブジェクトは、照会中の端末１１０に戻すように伝搬される。端末１１０は、ＮＳＩＳルータにおいて適切なＱｏＳおよびメディア適応リソースを選択してもよく、メディアデータパスに沿ってＱｏＳリソースの確保を要求し、選択されたＮＳＩＳルータでメディア適応処理の確保を要求する。いずれの確保も拡張される確保メッセージに組み合わせられてもよく、確保されるメディア適応リソースの記述に加えて、オンパスＮＳＩＳルータにおいて確保されるＱｏＳ制約条件の正確な仕様を含む。
すべてのメディア適応がメディア適応オブジェクトから取り除かれた後、確保メッセージは、さらに処理する必要がないことから、確保の端末に返送されてもよい。
したがって、端末１２２から端末１１０へのパスでメディア適応リソース および／またはＱｏＳリソースを確保するために、前の節で概略を述べたものと同一の手順が用いられてもよい。
一般的な課題および変形
異なる機構およびメッセージの提案された実現の主な利点の１つは、基礎となる経路指定（ＯＳＰＦ、ＲＩＰ、．．．）に依存することかもしれない。これは、既存の基盤で必要とされる変更が最小であることを意味している。しかし、この依存のために、プロトコルヘッダは、経路指定に影響を及ぼすＮＴＬＰによって検出され、ＭＲＩ（ＧＩＭＰＳドラフト参照）に反映されるように、ネットワークノードがデータを修正すると、受信器のためにアサートされることが困難となることから、修正されないものであることが望ましいと考えられる。
本発明の他の実施形態によって提案されたこの影響に対する解決策は、ＲＴＰミキサおよびトランスレータの原理の再使用、パケットを適合する中間ＲＴＰミキサおよびトランスレータによって含まれる同期ソース識別子（ＳＳＲＣ）または寄与ＳＳＲＣ（ＣＳＲＣ）の利用である。このＳＳＲＣまたは代替の識別子は、Ｍｅｄｉａ Ａｄａｐｔａｔｉｏｎ Ｓｅｓｓｉｏｎ ＩＤにリンクしてもよく、この関係は、たとえば、セッション記述における提案された“ａ＝ｉｎｔｅｒｍｅｄｉａｔｅ：”属性を用いることによって、メディア適応に合意するエンドポイントに知らせてもよい。
本願明細書に記載される機構の別の改良は、メディア適応リソースが用いられるために必要と考えられる順序およびメディアデータパスにおけるそれらの位置に関する。すべてのメディア適応リソースがオンパスにあるが、必要なメディア変換を獲得するために、異なる順序で、何度も訪れなければならないことが起こりうる。いくつかの変換は、メディアデータが適応のために、メディアデータパスを行ったり来たりして通過される（たとえば、端末１１０→ＮＳＩＳルータ１０８→ＮＳＩＳルータ０５→ＮＳＩＳルータ１０４→ＮＳＩＳルータ１０３（適応）→ＮＳＩＳルータ１０４（適応）→ＮＳＩＳルータ１０３→端末１２２）ことを必要とする場合もある。この問題はまた、必要なメディア適応リソースを用い、オフパスにあるメディア適応リソースを含むために用いられる同一のトンネリング機構を用いる正確な順序を保証するトンネルを確立することによって回避されてもよい。
さらに、これまで記載した実施例は、セッション開始および管理プロトコルとしてＳＩＰの使用に大面に基づいていた。たとえば、メディアストリーミングが関連している場合には、類似のシナリオが、ＲＴＳＰメッセージに関して仮定されることができる。ＳＩＰと同様に、ＲＴＳＰは、ＨＴＴＰのような構文を用いたプロトコルであり、セッションの詳細およびエンドホストの機能を搬送するために、ＳＤＰ（または他のセッション記述プロトコル）を用いてもよい。ＳＩＰとは異なり、ＲＴＳＰは、「遠隔制御」マルチメディアプレゼンテーションの機能性を満たす。
これまで記載した実施形態において、中心のエンティティ（確保の開始プログラム）は、本願明細書で指定したＭｅｄｉａＳｐｅｃメッセージのペイロードにおいて、メディア適応記述の形で必要とされる正確な処理を含む。したがって、必要とされるメディア適応ステップを決定するための論理は、中心に集められる。あるいは、本発明の別の実施形態によれば、分散手法も可能である。この変形において、ＮＳＩＳルータは、必要なメディア適応処理を複数のステップに分解することも可能であり、たとえば、２つのステップにおいてコーデックＹへのコーデックＸのトランスコーディングは、最初にＸ’にトランスコードし、次にＹにトランスコードする。この分解は、照会要求中に必要とされ、所与のメディア適応記述（所与のＩＤによって識別される）を照会開始プログラムに戻るように供給される複数の中間記述に分割する新たなパラメータの定義をほのめかしてもよい。中間トランスコーディングのほかに、他の処理は、フローを個別のメディア（オーディオおよびビデオなど）に分割するような挙動を必要とする場合がある。
いくつかの実施形態は、フローの経路指定がセッションの持続に関して変更されないままであると仮定している。しかし、たとえば、ポリシーまたは管理的決定のために、または所定の場所におけるトラフィック技術手順のために、経路指定が変更される場合に当てはまる場合もある。そのような場合には、「バックアップ確保」を可能にするために用いられてもよく、このことは、経路指定が変化する場合の便宜を図るために、より低い利用可能率の別のリソースの確保を意味する。Ｅ２Ｅ Ｓｅｓｓｉｏｎ Ｆｏｏｔｐｒｉｎｔｓを解析することによって、経路の変更前または変更後に、ＮＳＩＳルータまたはエンドポイントで、経路の変更を検出してもよい。
さらに、本発明は、マルチキャストメディアセッションにおいて用いられてもよいことを留意されたい。たとえば、ＮＳＩＳルータ１０３は、移動体通信システムを介してそれに付属させる移動体端末１１６〜１２３に関するプロキシであってもよい。マルチキャストサービスを確立するために、プロキシ１０３は、移動体通信ネットワークにおいて関与している移動体端末のために、セッションの設定および制御を処理してもよい。プロキシ１０３は、たとえば、サポートされるメディアフォーマットに関して、移動体端末のメディア機能を認識していてもよく、または認識させられてもよい。したがって、マルチキャストセッションが確立される場合には、プロキシ１０３は、セッション記述において指定されたメディアフォーマットのサポートの欠如を認識しているか、または認識させられてもよい。プロキシ１０３は、セッション記述において提示されたメディアフォーマットをサポートしない移動体端末のグループを形成してもよく、本願明細書に述べるように、ネットワークグループ方式で、メディア適応リソースを検出および確保してもよい。
本発明の別の実施形態は、ハードウェアおよびソフトウェアを用いた上述の実施形態の実現に関する。上記の本発明の実施形態は、計算デバイス（プロセッサ）、たとえば、汎用プロセッサ、ディジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブル論理デバイスなどを用いて、実現または実行されてもよいことは認識されたい。本発明の種々の実施形態はまた、これらのデバイスの組み合わせによって実行または具体化されてもよい。
さらに、本発明の実施形態はまた、プロセッサによって実行されるソフトウェアモジュールによって、またはハードウェアにおいて直接実現されてもよい。ソフトウェアモジュールまたはハードウェア実装の組み合わせもまた、可能であってもよい。ソフトウェアモジュールは、任意の種類のコンピュータ可読格納メディア、たとえば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに格納されてもよい。
前述に記載したように異なる実施形態および変形は、説明のための実施例として表されているに過ぎないことを認識すべきである。特定の実施形態において示されているように、広範囲に記載されているような本発明の精神または範囲を逸脱することなく、種々の変形および／または修正は、本発明に対して行われることができると当業者には認識されよう。したがって、本実施形態は、すべての点において説明のためであり、限定するわけではないと考えるべきである。
パケット交換型ネットワークの概略図を示し、この概略図に基づいて、本発明の例示の実施形態が説明される。 ＮＳＩＳ操作可能ルータおよびＮＳＩＳプロキシを含む図１のパケット交換型ネットワークに対するオーバレイネットワークを示す。 図１のパケット交換型ネットワークにおいて、エンドツーエンドメディアセッションを提供するために用いられることができる例示のプロトコルスタックを示す。 本発明の実施形態による２つの端末間のメディアセッションの例示の確立を示す。 メディアセッションの確立を可能にするために、所望のメディアフォーマット変換において、関与しうるＮＳＩＳルータを識別するために適切な本発明の実施形態によるオンパスＮＳＩＳルータ検出機構を示す。 本発明の例示の実施形態による２つの端末間で、図２のオーバレイネットワークを介した図５のオンパスＮＳＩＳルータ検出機構のメッセージの交換を示す。 本発明の例示の実施形態による２つの端末間で、図２のオーバレイネットワークを介した図５のオンパスＮＳＩＳルータ検出機構のメッセージの交換を示す。 本発明の例示の実施形態による２つの端末間で、図２のオーバレイネットワークを介した図５のオンパスＮＳＩＳルータ検出機構のメッセージの交換を示す。 本発明の例示の実施形態による２つの端末間で、図２のオーバレイネットワークを介した図５のオンパスＮＳＩＳルータ検出機構のメッセージの交換を示す。 ２つの端末間で、図２のオーバレイネットワークを介した本発明の別の実施形態によるオフパスＮＳＩＳルータ検出機構のメッセージの交換を示す。 ２つの端末間で、図２のオーバレイネットワークを介した本発明の別の実施形態によるオフパスＮＳＩＳルータ検出機構のメッセージの交換を示す。 ２つの端末間で、図２のオーバレイネットワークを介した本発明の別の実施形態によるオフパスＮＳＩＳルータ検出機構のメッセージの交換を示す。 ２つの端末間で、図２のオーバレイネットワークを介した本発明の別の実施形態によるオフパスＮＳＩＳルータ検出機構のメッセージの交換を示す。 ２つの端末間で、図２のオーバレイネットワークを介した本発明の別の実施形態によるオフパスＮＳＩＳルータ検出機構のメッセージの交換を示す。

Claims (36)

  1. パケット交換型通信ネットワークを介して第１の端末と第２の端末との間に少なくとも１つのメディアストリームを含むメディアセッションを確立するための方法であって、少なくとも１つのメディアストリームが、メディアトランスポートプロトコルを用いて通信され、第１の端末によって実行される以下のステップ、すなわち
    セッションを開始するために、セッション管理プロトコルを用いて、第２の端末にセットアップメッセージを送信するステップであって、メッセージは、メディアフォーマット［０］を提示するセッション記述と、メディアセッションにおいて通信される各メディアストリームに関する対応するパラメータおよび属性と、を含む、ステップと、
    セッション管理プロトコルを用いて、セットアップメッセージに対する応答を受信するステップであって、セットアップメッセージに対する応答は、修正セッション記述を含み、修正セッション記述は、メディアセッションの少なくとも１つのメディアストリームに関する代替メディアフォーマットを提示し、この場合には、第２の端末によってサポートされていないメディアフォーマットが、セットアップメッセージに含まれるセッション記述において提示されている、ステップと、
    セットアップメッセージに対する応答に含まれるセッション記述において各代替メディアフォーマットに関して、それぞれの代替メディアフォーマットが第１の端末によってサポートされているかどうかを決定するステップと、
    それぞれの代替メディアフォーマットが前記第１の端末によってサポートされていない場合には、第１の端末によってサポートされていない各代替メディアフォーマットに関して、ネクストステップインシグナリングＮＳＩＳフレームワークを用いて、少なくとも１つのＮＳＩＳルータを検出するステップであって、検出されたＮＳＩＳルータは、セットアップメッセージにおけるセッション記述において第１の端末によって提示されるメディアフォーマットから、セットアップメッセージにおける応答のセッション記述において第２の端末によって提示されるそれぞれの代替メディアフォーマットに、メディアストリームのパケットデータを変換する、ステップと、
    第１の端末によってサポートされていない各代替メディアフォーマットに関して、少なくとも１つのＮＳＩＳルータが、検出された場合には、第１の端末によってサポートされていないそれぞれの代替メディアフォーマットに関して検出された少なくとも１つのＮＳＩＳルータで、提示されたメディアフォーマットにおけるパケットデータをそれぞれの代替メディアフォーマットに変換するためのリソースを確保するステップと、
    メディアセッションを開始するメディアフォーマット変換のためのリソースが首尾よく確保されたときには、メディアセッションの少なくとも１つのメディアストリームのパケットデータが、メディアトランスポートプロトコルを用いて、第１の端末によってサポートされていない各代替メディアフォーマットに関して、メディアフォーマット変換のためのリソースが確保されている少なくとも１つのＮＳＩＳルータを介して、第１の端末から第２の端末に提供される、ステップと、
    を含む方法。
  2. ＮＳＩＳシグナリングフレームワークを用いて、少なくとも１つのＮＳＩＳルータを検出するステップは、
    パケット交換型ネットワークを介して第１の端末から第２の端末へのメディアセッションの少なくとも１つのストリームのパケットデータのパスに沿って、ＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、照会メッセージを送信するステップであって、照会メッセージが、第１の端末によってサポートされていない提示されたメディアフォーマットから、セットアップメッセージに対する応答におけるセッション記述において、第２の端末によって提示されたそれぞれの代替メディアフォーマットに、メディアセッションのストリームのパケットデータを変換するための機能に関する照会メッセージを受信する各ＮＳＩＳルータに照会する、ステップと、
    照会メッセージに対する応答において、ＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、提示されたメディアフォーマットからそれぞれの代替のメディアフォーマットにメディアセッションのストリームのパケットデータを変換することができる第１の端末から第２の端末へのパケットデータのパスにおける少なくとも１つのＮＳＩＳルータを示す応答メッセージを受信するステップと、
    を含む、請求項１に記載の方法。
  3. 照会メッセージは、第１の端末によってサポートされていない提示されたメディアフォーマットから中間メディアフォーマットに、または中間メディアフォーマットから別の中間メディアフォーマットまたはメディアセッションのそれぞれのメディアストリームに関するそれぞれの代替メディアフォーマットに、メディアセッションのメディアストリームのパケットデータを変換するための機能に関する照会メッセージを受信する各ＮＳＩＳルータにさらに照会し、
    応答メッセージは、第１の端末から第２の端末へのパスにおける少なくとも１つのＮＳＩＳルータが、提示されたメディアフォーマットから中間メディアフォーマットに、中間メディアフォーマットから別の中間メディアフォーマットまたはそれぞれの代替メディアフォーマットに、メディアセッションのメディアストリームのパケットデータを変換することができるかについてさらに示す、請求項２に記載の方法。
  4. ＮＳＩＳルータでパケットデータを変換するためのリソースを確保するステップは、
    提示されたメディアフォーマットから第２の端末によってセットアップメッセージに対する応答におけるセッション記述によって提示される代替メディアフォーマットに、メディアセッションのストリームのパケットデータを変換するためのメディア適応リソースの確保を要求するリソース確保要求メッセージを、ＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、少なくとも１つのＮＳＩＳルータに送信するステップと、
    リソース確保要求メッセージに対応する応答において、ＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、ＮＳＩＳルータが変換のためのリソースを確保したかどうかを示す応答メッセージを受信するステップと、
    を含む、請求項２又は３に記載の方法。
  5. セットアップメッセージに含まれるセッション記述は、第２の端末がセッション記述においてメディアストリームの提示されたメディアフォーマットをサポートしない場合には、メディアセッションの少なくともメディアストリームに関して、第１の端末がメディアフォーマット変換を自発的に行うかどうかをさらに示す、請求項１から４のいずれか一項に記載の方法。
  6. セットアップメッセージに含まれて送信されるセッション記述は、さらに、第２の端末に対し、メディアセッションのそれぞれのメディアストリームの受信が、メディアセッションの確立のために必須であるかどうかを示す、請求項１から５のいずれか一項に記載の方法。
  7. セットアップメッセージに含まれて送信されたセッション記述はさらに、第２の端末が提示されたメディアフォーマットをサポートしていない場合には、メディアセッションのメディアストリームに関して、別のメディアフォーマットへの提示されたメディアフォーマットの変換が、メディアセッションの確立のために任意であるか、または必須であるかを示す、請求項６に記載の方法。
  8. それぞれのメディアストリームに関して提示されたフォーマットが、第２の端末によってサポートされていない場合には、修正セッション記述は、さらに、代替メディアフォーマットにおけるメディアストリームのパケットデータを提示されたメディアフォーマットにおけるメディアストリームのパケットデータに変換するために、少なくとも１つのＮＳＩＳルータにおいてリソースを自発的に検出して確保するかどうかを示し、
    そうである場合には、修正セッション記述はさらに、セットアップメッセージに対する応答の送信時に、第２の端末がメディアフォーマット変換リソースの検出および確保を開始したことを示す、請求項１から７のいずれか一項に記載の方法。
  9. 第１の端末によって送受信されるサービス記述は、さらに、セッションに関連するサービスの品質制約条件を含み、セットアップメッセージに対する応答における修正セッション記述は、セットアップメッセージのセッション記述に含まれるサービスの品質制約条件に対して、代替のサービスの品質制約条件を提示することを含む、請求項１から８のいずれか一項に記載の方法。
  10. 代替のサービスの品質制約条件が、第１の端末のユーザによって許容可能であるかどうかを決定するステップと、
    そうである場合には、第２の端末のセッション記述において示される代替のサービスの品質制約条件に基づき、パケット交換型通信ネットワークを介した第１の端末から第２の端末へのパスに沿ってリソースを確保するステップであって、メディアセッションの少なくとも１つのメディアストリームのパケットデータは、前記パスに沿って第１の端末から第２の端末に供給されるステップをさらに含む、請求項９に記載の方法。
  11. セットアップメッセージに対する応答において受信されたセッション記述において提示された各代替メディアフォーマットに関して、検出されるＮＳＩＳルータがない場合、それぞれのＮＳＩＳルータでメディアフォーマットを変換するために確保されることができるリソースが十分でない場合、またはパケット交換型通信ネットワークを介したパスに沿って、セットアップメッセージに対する応答において受信されたセッション記述において提示された代替のサービスの品質制約条件を満たすために確保されることができるリソースが十分でない場合には、セッションを中断するステップをさらに含む、請求項１から１０のいずれか一項に記載の方法。
  12. メディアセッションを開始するステップは、メディアセッションのそれぞれのストリームに関する適応ノードにおいてメディアフォーマット変換を記述する更新されたセッション記述を含む更新メッセージを第２の端末に送信するステップを含み、この場合には代替メディアフォーマットが、パケット交換型通信ネットワークを介して第１の端末から第２の端末にパスに沿って提示され、メディアセッションの少なくとも１つのメディアストリームのパケットデータは、前記パスに沿って第１の端末から第２の端末に供給される、請求項１から１１のいずれか一項に記載の方法。
  13. 送信された更新メッセージはさらに、第１の端末から第２の端末へのパスに沿って、第１の端末によって確保されるリソースに関する情報を含む、請求項１２に記載の方法。
  14. メディアセッションのそれぞれのストリームに関する適応ノードにおいてメディアフォーマット変換を記述する更新されたセッション記述を含む更新メッセージを第２の端末から受信するステップであって、この場合には代替メディアフォーマットが、パケット交換型通信ネットワークを介して第２の端末から第１の端末にパスに沿って提示され、メディアセッションの少なくとも１つのメディアストリームのパケットデータは、前記パスに沿って第２の端末から第１の端末に供給される、請求項１２または１３に記載の方法。
  15. 受信された更新メッセージはさらに、第２の端末から第１の端末へのパスに沿って、第１の端末によって確保されるリソースに関する情報をさらに含む、請求項１４に記載の方法。
  16. メディアトランスポートプロトコルは、リアルタイムトランスポートプロトコルＲＴＰである、請求項１から１５のいずれか一項に記載の方法。
  17. セッション記述は、セッション記述プロトコルＳＤＰフォーマットまたはリアルタイムストリーミングプロトコルＲＴＳＰフォーマットで提供される、請求項１から１６のいずれか一項に記載の方法。
  18. セッション管理プロトコルは、セッション開始プロトコルＳＩＰであり、セットアップメッセージは、ＳＩＰプロトコルの招待メッセージであり、セットアップメッセージに対する応答は、第２の端末がメディアフォーマット変換リソースの検出および確保のための第１の端末の意思を承認することと、第２の端末が第１の端末によってサポートされていない代替メディアフォーマットにおけるメディアセッションのメディアストリームを第１の端末によってサポートされるそれぞれの提示されたメディアフォーマットに変換するために、少なくともＮＳＩＳルータでメディアフォーマット変換のためのリソースの検出および確保を開始したことを第１の端末に示すＳＩＰプロトコルのセッション進行メッセージであって、前記方法は、
    セッション進行メッセージに含まれるセッション記述において提示された代替メディアフォーマットが、第１の端末によってサポートされていない場合には、第１の端末が、セッション記述において提示された各代替メディアフォーマットに関して、ＮＳＩＳルータでメディアフォーマット変換のためのリソースの検出および確保を開始したことを第２の端末に示す暫定応答承認メッセージを送信するステップであって、メディアフォーマット変換のためのリソースが第２の端末によって確保された適応ノードが検出され、代替メディアフォーマットから第１の端末によって提示されたメディアフォーマットに、メディアセッションのメディアストリームのパケットデータを変換するように構成される、ステップと、
    暫定応答承認を受信するステップと、
    をさらに含む、請求項１から１７のいずれか一項に記載の方法。
  19. 要求中の端末に対してパケット交換型通信ネットワークを介して端末間で確立されるメディアセッションのメディアストリームのメディアフォーマットを変換するためのメディアフォーマット適応リソースを記録するための方法であって、メディアトランスポートプロトコルによってカプセル化されたセッションのメディアストリームのパケットデータが、要求中の端末から確立されるメディアセッションに関与している宛先端末にパケット交換型ネットワークを介して移送されるメディアデータパスにおけるＮＳＩＳルータによって行われる以下のステップ、すなわち、
    パケット交換型ネットワークを介してＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、照会メッセージを受信するステップであって、照会メッセージは、第１のメディアフォーマットから第２の異なるメディアフォーマットに、メディアセッションのストリームのパケットデータを変換するための機能に関する照会メッセージを受信するＮＳＩＳルータに照会する、ステップと、
    受信された照会メッセージに対する応答において、ＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、要求中の端末に対して、ＮＳＩＳルータが、第１のメディアフォーマットから第２のメディアフォーマットにメディアセッションのストリームのパケットデータを変換する機能を有するかどうかを示す応答メッセージを送信するステップと、
    を含む方法。
  20. 照会メッセージはさらに、第１のメディアフォーマットから中間メディアフォーマットに、または中間メディアフォーマットから別の中間メディアフォーマットまたは第２の代替のメディアフォーマットに、メディアセッションのメディアストリームのパケットデータを変換するための機能について照会し、
    応答メッセージはさらに、ＮＳＩＳルータが、照会されたメディアフォーマット変換の少なくとも１つを提供することができるかどうかを示す、請求項１９に記載の方法。
  21. 照会メッセージは、適応機能が照会される１つまたは複数のメディアフォーマット変換を示すメディアフォーマット適応記述を含む、請求項１９または２０に記載の方法。
  22. ＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、リソース確保要求メッセージを受信するステップであって、メッセージは、リソースが割り当てられるように要求されるＮＳＩＳルータによって行われるメディアフォーマット変換の記述を含む、ステップと、
    前記記述によって示されるメディアフォーマット変換のためのリソースが、ＮＳＩＳルータで割り当てられることができるかどうかを決定するステップと、
    割当可能である場合には、ＮＳＩＳルータで、変換のためのリソースを確保するステップと、
    をさらに含み、
    応答メッセージは、ＮＳＩＳルータが変換のためにリソースを確保したかどうかを示す、請求項１９から２１のいずれか一項に記載の方法。
  23. ＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、リソース確保要求メッセージを受信するステップであって、メッセージは、メディアデータパスに位置する別のＮＳＩＳルータで確保されるメディアフォーマット変換の記述を含む、ステップと、
    メディアデータパスに位置する他のＮＳＩＳルータへのトンネルを確立するステップと、
    メディアセッションの開始時に、変換のためにメディアデータパスに位置するＮＳＩＳルータに変換されるメディアストリームのパケットデータを転送するステップと、
    をさらに含む、請求項１９から２３のいずれか一項に記載の方法。
  24. ＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、リソース確保要求メッセージを受信するステップであって、メッセージは、メディアデータパスに位置しないＮＳＩＳルータで、確保されるメディアフォーマット変換の記述を含む、ステップと、
    リソース確保要求メッセージをメディアデータパスに位置しないＮＳＩＳルータに転送するステップと、
    メディアデータパスに位置しないＮＳＩＳルータへのトンネルを確立するステップと、
    メディアセッションの開始時に、変換のためにメディアデータパスに位置しないＮＳＩＳルータに変換されるメディアストリームのパケットデータを転送するステップと、
    をさらに含む、請求項１９から２３のいずれか一項に記載の方法。
  25. ＮＳＩＳルータで利用可能なメディアフォーマット適応機能の記述を照会メッセージに追加するステップと、
    追加した記述を含む受信した照会メッセージをメディアデータパスにおける次のＮＳＩＳルータまたは宛先端末に転送するステップと、
    転送された照会メッセージに対する応答において、メディアデータパスにおける次のＮＳＩＳルータまたは宛先端末から応答メッセージを受信するステップであって、照会されたメディアフォーマット適応機能が利用可能である場合には、応答メッセージは、メディアデータパスに位置するＮＳＩＳルータで利用可能であるメディアフォーマット適応機能の少なくとも１つの記述を含む、ステップと、
    をさらに含み、
    照会されたメディアフォーマット適応機能が利用可能である場合には、送信された応答メッセージは、メディアデータパスに位置するＮＳＩＳルータで利用可能であるメディアフォーマット適応機能の少なくとも１つの記述を含む、請求項１９から２４のいずれか一項に記載の方法。
  26. 少なくとも１つのメディアデータパスに位置しないＮＳＩＳルータに照会メッセージを転送するステップと、
    少なくとも１つのメディアデータパスに位置しないＮＳＩＳルータから、メディアパスに位置しない少なくとも１つのＮＳＩＳルータで利用可能であるメディアデータ適応機能の記述を含む応答メッセージを受信するステップと、
    をさらに含む、請求項２５に記載の方法。
  27. 受信された照会メッセージをメディアデータパスにおける次のＮＳＩＳルータに転送する前に、メディアパスに位置しない少なくとも１つのＮＳＩＳルータで利用可能なメディアデータ適応機能の記述を、上記の受信された照会メッセージに追加するステップをさらに含む、請求項２６に記載の方法。
  28. 要求中の端末に対して送信される応答メッセージは、さらに、メディアパスに位置するか、または位置しない少なくとも１つのＮＳＩＳルータで利用可能なメディアデータ適応機能の記述を含む、請求項２３または２７に記載の方法。
  29. パケット交換型通信ネットワークを介して端末と第２の端末との間で、少なくとも１つのメディアストリームを含むメディアセッションを確立する端末であって、少なくとも１つのメディアストリームは、メディアトランスポートプロトコルを用いて通信される、端末であって、前記端末は、
    セッションを開始するために、セッション管理プロトコルを用いて、セットアップメッセージを第２の端末に送信するための送信器であって、メッセージは、メディアセッションにおいて送信されるメディアフォーマットと、各メディアストリームに関する対応するパラメータおよび属性と、を提示するセッション記述を含む、送信器を備え、
    セッション管理プロトコルを用いて、セットアップメッセージに対する応答を受信するための受信器を備え、セットアップメッセージに対する応答は、修正セッション記述を含み、修正セッション記述は、メディアセッションの少なくとも１つのメディアストリームに関する代替メディアフォーマットを提示し、この場合には第２の端末によってサポートされていないメディアフォーマットがセットアップメッセージに含まれるセッション記述において提示され、
    セットアップメッセージに対する応答に含まれるセッション記述において、各代替メディアフォーマットに関してそれぞれの代替メディアフォーマットが端末によってサポートされるかどうかを決定するための処理装置を備え、
    前記処理装置はさらに、それぞれの代替メディアフォーマットが端末によってサポートされていない場合には、ネクストステップインシグナリングＮＳＩＳフレームワークを用いて、端末によってサポートされていない各代替メディアフォーマットに関して、少なくとも１つのＮＳＩＳルータを検出するように構成され、
    検出されたＮＳＩＳルータは、セットアップメッセージにおけるセッション記述において、第１の端末によって提示されるメディアフォーマットから、セットアップメッセージにおける応答のセッション記述において、第２の端末によって提示されたそれぞれの代替メディアフォーマットに、メディアストリームのパケットデータを変換することができ、
    第１の端末によってサポートされていない各代替メディアフォーマットに関して、少なくとも１つのＮＳＩＳルータが検出されている場合には、第１の端末によってサポートされていないそれぞれの代替メディアフォーマットに関して検出される少なくとも１つのＮＳＩＳルータで、提示されたメディアフォーマットにおけるパケットデータをそれぞれの代替メディアフォーマットに変換するためのリソースを確保するための確保ユニットを備え、
    前記端末は、メディアフォーマット変換のためのリソースを確保したときに、メディアセッションを開始するように適合され、メディアセッションの少なくとも１つのメディアストリームのパケットデータは、メディアトランスポートプロトコルを用いて、メディアフォーマット変換のためのリソースが、端末によってサポートされていない各代替メディアフォーマットに関して確保されている少なくとも１つのＮＳＩＳルータを介して端末から第２の端末に提供される、端末。
  30. 請求項１から１８のいずれか一項に記載の方法を行うように適合された手段をさらに備えた、請求項２９に記載の端末。
  31. 要求中の端末に対してパケット交換型通信ネットワークを介して端末間で確立されるメディアセッションのメディアストリームのメディアフォーマットを変換するためのメディアフォーマット適応リソースを記録するためのＮＳＩＳルータであって、
    ＮＳＩＳルータは、メディアトランスポートプロトコルによってカプセル化されたセッションのメディアストリームのパケットデータが、要求中の端末から確立されるメディアセッションに関与している宛先端末まで、パケット交換型ネットワークを介して移送されるメディアデータパスに位置し、
    パケット交換型ネットワークを介して、ＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、照会メッセージを受信するための受信器を備え、照会メッセージは、第１のメディアフォーマットから第２の異なるメディアフォーマットに、メディアセッションのストリームのパケットデータを変換するための機能に関する照会メッセージを受信するＮＳＩＳルータに照会し、
    受信された照会メッセージに対する応答において、要求中の端末に対してＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、ＮＳＩＳルータが、第１のメディアフォーマットから第２のメディアフォーマットに、メディアセッションのストリームのパケットデータを変換する機能を有するかどうかを示す応答メッセージを送信するための送信器を備える、ＮＳＩＳルータ。
  32. 請求項１９から２８のいずれか一項に記載の方法を行うように適合された手段をさらに備えた、請求項３１に記載のＮＳＩＳルータ。
  33. 端末のプロセッサによって実行されるときに、パケット交換型通信ネットワークを介して端末と第２の端末との間で、少なくとも１つのメディアストリームを含むメディアセッションを端末に確立させる命令を格納するコンピュータ読み出し可能メディアであって、少なくとも１つのメディアストリームは、メディアトランスポートプロトコルを用いて、
    セッションを開始するために、セッション管理プロトコルを用いて、セットアップメッセージを第２の端末に送信するステップであって、メッセージは、メディアセッションにおいて送信されるメディアフォーマット［０］と、各メディアストリームに関する対応するパラメータおよび属性と、を提示するセッション記述を含む、ステップと、
    セッション管理プロトコルを用いて、セットアップメッセージに対する応答を受信するステップであって、セットアップメッセージに対する応答は、修正セッション記述を含み、修正セッション記述は、メディアセッションの少なくとも１つのメディアストリームに関する代替メディアフォーマットを提示し、この場合には第２の端末によってサポートされていないメディアフォーマットがセットアップメッセージに含まれるセッション記述において提示される、ステップと、
    セットアップメッセージに対する応答に含まれるセッション記述において、各代替メディアフォーマットに関して、それぞれの代替メディアフォーマットが第１の端末によってサポートされるかどうかを決定するステップと、
    そうでない場合には、第１の端末によってサポートされていない各代替メディアフォーマットに関して、ネクストステップインシグナリングＮＳＩＳフレームワークを用いて、少なくとも１つのＮＳＩＳルータを検出するステップであって、検出されたＮＳＩＳルータは、セットアップメッセージにおけるセッション記述において第１の端末によって提示されるメディアフォーマットから、セットアップメッセージにおける応答のセッション記述において第２の端末によって提示されるそれぞれの代替メディアフォーマットに、メディアストリームのパケットデータを変換することができる、ステップと、
    第１の端末によってサポートされていない各代替メディアフォーマットに関して、少なくとも１つのＮＳＩＳルータが、検出された場合には、第１の端末によってサポートされていないそれぞれの代替メディアフォーマットに関して検出された少なくとも１つのＮＳＩＳルータで、提示されたメディアフォーマットにおけるパケットデータをそれぞれの代替メディアフォーマットに変換するためのリソースを確保するステップと、
    を含み、
    メディアセッションを開始するメディアフォーマット変換のためのリソースが確保されたときには、メディアセッションの少なくとも１つのメディアストリームのパケットデータが、メディアトランスポートプロトコルを用いて、第１の端末によってサポートされていない各代替メディアフォーマットに関して、メディアフォーマット変換のためのリソースが確保されている少なくとも１つのＮＳＩＳルータを介して、第１の端末から第２の端末に提供されることによって、通信されるコンピュータ読み出し可能メディア。
  34. 端末のプロセッサによって実行されるときに、請求項１から１８のいずれか一項に記載の方法のステップを端末に実行させる命令をさらに格納する、請求項３３に記載のコンピュータ読み出し可能メディア。
  35. メディアトランスポートプロトコルによってカプセル化されたセッションのメディアストリームのパケットデータが、要求中の端末から確立されるメディアセッションに関与している宛先端末に、パケット交換型通信ネットワークを介して移送されるメディアデータパスにおけるＮＳＩＳルータのプロセッサによって実行されるとき、要求中の端末に対してメディアセッションのメディアストリームのメディアフォーマットを変換するためのメディアフォーマット適応リソースをＮＳＩＳルータに記録させる命令を格納するコンピュータ読み出し可能メディアであって、ＮＳＩＳルータによって、
    パケット交換型ネットワークを介してＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、照会メッセージを受信し、照会メッセージは、第１のメディアフォーマットから第２の異なるメディアフォーマットにメディアセッションのストリームのパケットデータを変換するための機能に関する照会メッセージを受信するＮＳＩＳルータに照会し、
    受信された照会メッセージに対する応答において、ＮＳＩＳトランスポートレベルプロトコルＮＴＬＰを用いて、要求中の端末に対して、ＮＳＩＳルータが、第１のメディアフォーマットから第２のメディアフォーマットにメディアセッションのストリームのパケットデータを変換する機能を有するかどうかを示す応答メッセージを送信するコンピュータ読み出しメディア。
  36. ＮＳＩＳルータのプロセッサによって実行されるときに、請求項１９から２８のいずれか一項に記載の方法をＮＳＩＳルータに行わせる命令をさらに格納する、請求項３５に記載のコンピュータ読み出し可能メディア。
JP2008527340A 2005-08-26 2006-08-10 メディア適応を備えたメディアセッションの確立 Expired - Fee Related JP4746102B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP05018623.8 2005-08-26
EP05018623A EP1758334A1 (en) 2005-08-26 2005-08-26 Establishment of media sessions with media adaptation
PCT/EP2006/007937 WO2007022875A1 (en) 2005-08-26 2006-08-10 Establishment of media sessions with media adaptation

Publications (2)

Publication Number Publication Date
JP2009506601A true JP2009506601A (ja) 2009-02-12
JP4746102B2 JP4746102B2 (ja) 2011-08-10

Family

ID=35589597

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008527340A Expired - Fee Related JP4746102B2 (ja) 2005-08-26 2006-08-10 メディア適応を備えたメディアセッションの確立

Country Status (5)

Country Link
US (1) US7958242B2 (ja)
EP (1) EP1758334A1 (ja)
JP (1) JP4746102B2 (ja)
CN (1) CN101273607A (ja)
WO (1) WO2007022875A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013179654A (ja) * 2007-08-23 2013-09-09 Samsung Electronics Co Ltd モバイルビデオ電話間の選好画像フォーマットを決定する方法及び装置

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2363111C2 (ru) * 2003-09-02 2009-07-27 Нокиа Корпорейшн Передача информации, относящейся к качеству обслуживания
JP4598859B2 (ja) * 2006-06-05 2010-12-15 株式会社日立製作所 中継ネットワークシステム及び端末アダプタ装置
US8520687B2 (en) * 2007-07-06 2013-08-27 Alcatel Lucent Method and apparatus for internet protocol multimedia bearer path optimization through a succession of border gateways
CN101690076B (zh) * 2007-07-10 2014-02-26 艾利森电话股份有限公司 使用ims来发现运营商提供的网络服务的方法
GB2452535A (en) * 2007-09-07 2009-03-11 Ericsson Telefon Ab L M Optimising packet switched networks
US8201188B2 (en) 2007-09-20 2012-06-12 Microsoft Corporation Device-hosted services over media transfer protocol
US9479967B1 (en) * 2007-10-26 2016-10-25 Genband Us Llc Enhanced media gateway
US20090136016A1 (en) * 2007-11-08 2009-05-28 Meelik Gornoi Transferring a communication event
KR100940183B1 (ko) * 2007-12-11 2010-02-04 한국전자통신연구원 저전력 센서망에서 다중 라우팅 기법에 적용 가능한 공용 패킷 블록 구성 장치 및 그 제공 방법
KR100928998B1 (ko) * 2007-12-12 2009-11-26 한국전자통신연구원 사용자 단말기에 멀티미디어 컨텐츠와 코덱을 제공하는적응적 멀티미디어 시스템 및 그 방법
JP5006452B2 (ja) * 2007-12-19 2012-08-22 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Ｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅネットワーク
ES2709177T3 (es) 2008-01-11 2019-04-15 Ericsson Telefon Ab L M Método y aparato para establecer una sesión de medios transmitidos en flujo continuo y tiempo real (streaming)
CN101540970B (zh) * 2008-03-19 2013-08-28 华为技术有限公司 一种终端处理主叫信息的方法和装置
JP5199719B2 (ja) * 2008-04-07 2013-05-15 キヤノン株式会社 ネットワークシステム
JP5336920B2 (ja) * 2008-05-08 2013-11-06 パナソニック株式会社 記録装置
US20100017516A1 (en) * 2008-07-16 2010-01-21 General Instrument Corporation Demand-driven optimization and balancing of transcoding resources
US8713627B2 (en) 2008-08-14 2014-04-29 Juniper Networks, Inc. Scalable security services for multicast in a router having integrated zone-based firewall
US8307422B2 (en) * 2008-08-14 2012-11-06 Juniper Networks, Inc. Routing device having integrated MPLS-aware firewall
US9392437B2 (en) * 2008-10-17 2016-07-12 Alcatel Lucent Method and system for IP multimedia bearer path optimization through a succession of border gateways
US20100149301A1 (en) * 2008-12-15 2010-06-17 Microsoft Corporation Video Conferencing Subscription Using Multiple Bit Rate Streams
KR101669064B1 (ko) * 2009-02-05 2016-10-25 삼성전자주식회사 통신 시스템 및 그의 미디어 적응 방법
US8488632B2 (en) * 2009-03-11 2013-07-16 Xcast Labs, Inc. Optimizing VoIP for satellite connection
CN102428728B (zh) 2009-05-18 2015-05-06 瑞典爱立信有限公司 用于动态资源保留的方法和布置
US8291107B1 (en) * 2009-06-08 2012-10-16 Sprint Spectrum L.P. Dynamic multimedia content change based on sector loading
JP5675807B2 (ja) * 2009-08-12 2015-02-25 コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ 動的なｒｔｃｐリレー
CN102055741B (zh) * 2009-11-06 2013-08-14 华为终端有限公司 媒体会话协商的方法、设备及系统
GB2479180B (en) 2010-03-31 2016-06-01 Skype System of user devices
GB201005454D0 (en) 2010-03-31 2010-05-19 Skype Ltd Television apparatus
US9077774B2 (en) 2010-06-04 2015-07-07 Skype Ireland Technologies Holdings Server-assisted video conversation
US8947492B2 (en) 2010-06-18 2015-02-03 Microsoft Corporation Combining multiple bit rate and scalable video coding
US20130191535A1 (en) * 2010-06-29 2013-07-25 Zte (Usa) Inc Method and system for cloud-based media adaptation and transcoding service
FR2963861B1 (fr) * 2010-08-10 2014-09-12 Thales Sa Procede et architecture de systeme d'ouverture de canaux sur etablissement de communication volp en mode clair p bgan, swiftbroad et fleetbroadband
US10404762B2 (en) 2010-12-31 2019-09-03 Skype Communication system and method
US9717090B2 (en) 2010-12-31 2017-07-25 Microsoft Technology Licensing, Llc Providing notifications of call-related services
US8963982B2 (en) 2010-12-31 2015-02-24 Skype Communication system and method
US10291660B2 (en) 2010-12-31 2019-05-14 Skype Communication system and method
WO2012175227A1 (en) * 2011-06-23 2012-12-27 Telefonaktiebolaget L M Ericsson (Publ) Methods and apparatus for identifying rtp media streams containing related media data
CN103636179B (zh) * 2011-07-07 2017-07-07 瑞典爱立信有限公司 用于多媒体通信网络中的媒体流编组的方法和设备
US9712891B2 (en) * 2011-11-01 2017-07-18 Nokia Technologies Oy Method and apparatus for selecting an access method for delivery of media
US9019336B2 (en) * 2011-12-30 2015-04-28 Skype Making calls using an additional terminal
WO2013117211A1 (en) * 2012-02-06 2013-08-15 Nokia Siemens Networks Oy Customer experience management interaction with caching
GB2501080A (en) * 2012-04-11 2013-10-16 Sca Ipla Holdings Inc Telecommunication apparatus and methods
CN103841086B (zh) * 2012-11-23 2018-03-27 中兴通讯股份有限公司 一种数据传输方法、装置及终端
CN103856397B (zh) * 2012-12-07 2018-08-14 中兴通讯股份有限公司 多链路透明互连网络中组播转发方法及装置、路由桥
US9166912B2 (en) 2013-02-25 2015-10-20 Google Inc. Translating network forwarding plane models into target implementation using sub models and hints
US9172604B1 (en) 2013-02-25 2015-10-27 Google Inc. Target mapping and implementation of abstract device model
US9912623B2 (en) * 2015-01-16 2018-03-06 General Electric Company Systems and methods for adaptive context-aware control of multimedia communication sessions
EP3318008B1 (en) * 2015-06-30 2022-09-07 British Telecommunications public limited company Negotiating quality of service for data flows
CN107423307B (zh) * 2016-05-24 2020-11-17 创新先进技术有限公司 一种互联网信息资源的分配方法及装置
CN108809921B (zh) * 2017-07-31 2021-08-06 视联动力信息技术股份有限公司 一种音频处理方法、视联网服务器和视联网终端
US11089078B2 (en) * 2019-09-13 2021-08-10 Microsoft Technology Licensing, Llc Model-based parameter selection for media sessions
CN111193941B (zh) * 2020-01-07 2021-09-17 北京东土科技股份有限公司 一种媒体数据的传输方法、装置、设备及存储介质
CN113473162B (zh) * 2021-04-06 2023-11-03 北京沃东天骏信息技术有限公司 一种媒体流的播放方法、装置、设备和计算机存储介质
CN115426335B (zh) * 2021-05-13 2023-10-27 中移(上海)信息通信科技有限公司 一种信息交互方法、装置、设备及系统
GB2619550A (en) * 2022-06-10 2023-12-13 Sony Interactive Entertainment Europe Ltd Systems and methods for contolling content streams

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001117809A (ja) * 1999-10-14 2001-04-27 Fujitsu Ltd メディア変換方法及び記憶媒体
JP2003152820A (ja) * 2001-11-19 2003-05-23 Nec Corp シグナリング中継システムおよびシグナリング中継方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1089517B1 (en) * 1999-10-01 2005-12-14 Nortel Networks Limited Establishing connections accross a communications network
US7191236B2 (en) * 2000-05-02 2007-03-13 Canon Kabushiki Kaisha Transparent telecommunications system and apparatus
ATE293863T1 (de) * 2002-01-23 2005-05-15 Sony Int Europe Gmbh Ein verfahren zur übertragung von end-to-end qos durch anwendung des end-to-end negotiation protocols (e2enp)
JP2003309664A (ja) * 2002-04-17 2003-10-31 Sony Corp 端末装置、データ送受信システム及びデータ送受信開始方法
US7451229B2 (en) * 2002-06-24 2008-11-11 Microsoft Corporation System and method for embedding a streaming media format header within a session description message
GB0230301D0 (en) * 2002-12-30 2003-02-05 Nokia Corp Streaming media
US6888821B2 (en) * 2003-02-10 2005-05-03 Nokia Corporation Dynamic media authorization in mobile networks
BR0302755A (pt) * 2003-08-25 2003-11-25 Eduardo Moreno Marques Sistema concentrador de acesso aos serviços de telefonia fixa e móvel
JP4343626B2 (ja) * 2003-09-02 2009-10-14 キヤノン株式会社 画像通信制御方法、画像通信制御プログラム、および画像通信装置
US20050060411A1 (en) * 2003-09-16 2005-03-17 Stephane Coulombe System and method for adaptation of peer-to-peer multimedia sessions

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001117809A (ja) * 1999-10-14 2001-04-27 Fujitsu Ltd メディア変換方法及び記憶媒体
JP2003152820A (ja) * 2001-11-19 2003-05-23 Nec Corp シグナリング中継システムおよびシグナリング中継方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013179654A (ja) * 2007-08-23 2013-09-09 Samsung Electronics Co Ltd モバイルビデオ電話間の選好画像フォーマットを決定する方法及び装置
US9549013B2 (en) 2007-08-23 2017-01-17 Samsung Electronics Co., Ltd. Method and apparatus for determining preferred image format between mobile video telephones

Also Published As

Publication number Publication date
JP4746102B2 (ja) 2011-08-10
CN101273607A (zh) 2008-09-24
WO2007022875A1 (en) 2007-03-01
US20090172170A1 (en) 2009-07-02
EP1758334A1 (en) 2007-02-28
US7958242B2 (en) 2011-06-07

Similar Documents

Publication Publication Date Title
JP4746102B2 (ja) メディア適応を備えたメディアセッションの確立
JP5312594B2 (ja) Ｒｆｃ３３１３に対する帯域内ｄｐｉメディア予約修正
EP2060077B1 (en) Indicating or remarking of a dscp
US8301744B2 (en) Systems and methods for QoS provisioning and assurance for point-to-point SIP sessions in DiffServ-enabled MPLS networks
US9277029B2 (en) Method and apparatus for providing relevant service levels
JP6262730B2 (ja) 複数のオーディオビデオブリッジングネットワークを介したストリームのためのサービス品質
US20080165787A1 (en) Method for negotiating about the media stream packet time length
Thomas et al. Enhancing MPEG DASH performance via server and network assistance
JP2006518948A (ja) マルチメディア・ストリーミングにおけるストリーミング品質適合と制御機構のシグナリング方法
US20180131672A1 (en) Method and system for enabling media optimization in a cloud conference
US20120166659A1 (en) Node and Method for Quality of Service (QoS) Control
CN104518908A (zh) 用于提供网络管理的方法和系统
WO2006093221A1 (ja) 伝送制御装置およびその方法
WO2007019777A1 (fr) Méthode d’établissement de session et nœud de contrôle de session
WO2009082908A1 (fr) Procédé, dispositif et système de traitement d&#39;un protocole de flux en temps réel
US20090241157A1 (en) Content distribution system, band control mediating apparatus, and band control method
JP2013510477A (ja) メディアセッションのネゴシエーションのための方法、機器およびシステム
Volkert et al. Hierarchical routing management for improving multimedia transmissions and QoE
Lee et al. A survey of session initiation protocol in Wireless Mesh Network
US20120144013A1 (en) Discovery of on-path services for media flows
US20110158102A1 (en) Method and system for routing data streams in an ip network by flooding of a subscriber search message
Ahsan et al. Multipath RTP (MPRTP) draft-ietf-avtcore-mprtp-03
Nandakumar RFC 8859 A Framework for Session Description Protocol (SDP) Attributes When Multiplexing
WO2009095069A1 (en) Methods, apparatuses, system, and related computer program product for session initiation
Braun et al. Signalling

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090610

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110118

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110318

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110412

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110512

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140520

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees