(57)【要約】【課題】マルチメディア・セッション管理に必要な情報以外の情報を配信する為の通信手段のインデックス化を可能とする。【解決手段】第一端末（Ｔ１）と第二端末（Ｔ２）とが通信を確立し、該通信確立においては、第一端末（Ｔ１）が両端末間のデータ交換チャネルを選択し、セッションを開いて第一端末（Ｔ１）が第二端末（Ｔ２）にリクエスト発信し（５３）、セッションを閉じるべく第二端末（Ｔ２）が使用不可を表す応答を送信する（５４）のだが、該セッションの開始、終了は所定のシグナリング・プロトコルに従い行われる。前記リクエスト発信及び応答送信において、前記シグナリング・プロトコルに加え、マルチメディア・セッション管理に必要でないアプリケーション情報に対応する追加情報を、選択されたデータ交換チャネルにより伝送（５５）する。該データ交換チャネルはセッションの特徴を専ら記述／説明するフィールドを介してアクセス可能である。【選択図】図１
2008148313.tif 000002
【特許請求の範囲】
【請求項１】
電気通信（ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ）ネットワーク（Ｎ）によって互いに接続された少なくとも二つの通信端末（Ｔ１、Ｔ２、４）の間でマルチメディア情報の伝送をするための、交換チャネルの確立の制御方法であって、
該方法が、第一の通信端末（Ｔ１）と第二の通信端末（Ｔ２）とが、セッションの開始を可能にする所定のシグナリング・プロトコルを管理するアプリケーションをそれぞれ用いて通信を確立する、通信確立過程（５１）を含んでおり、
第一端末（Ｔ１）が二つの端末（Ｔ１、Ｔ２）の間における少なくとも一つのデータ交換チャネルを選択する、データ交換チャネル選択過程（５２）を実行し、
前記データ交換チャネル選択過程（５２）はアプリケーション・レベルで行われるものであり、
前記通信確立過程（５１）が、
−第一端末（Ｔ１）が、所定のシグナリング・プロトコルにしたがってセッションを開くことにより、少なくとも一つのリクエストを第二端末（Ｔ２）に向けて発信する、リクエスト発信過程（５３）と、
−第二端末（Ｔ２）が、所定のシグナリング・プロトコルにしたがってセッションを閉じるために、一時的に利用できない状態であることを表す応答を送信する、応答送信過程（５４）を含んでおり、
前記リクエスト発信過程および前記応答送信過程（５３、５４）には、選択された前記データ交換チャネルを用いて、前記シグナリング・プロトコルに加えて追加情報を伝送する過程（５５）が含まれており、
このデータ交換チャネルは、セッションの特徴を専ら（ｐｕｒｅｍｅｎｔ）記述する／説明するフィールドを介してアクセス可能なチャネルであり、
前記追加情報は、マルチメディア・セッションの管理に必要ではないアプリケーション情報に対応する情報であることを特徴とする、交換チャネルの確立の制御方法。
【請求項２】
第一端末（Ｔ１）が、前記追加情報の伝送過程（５５）に用いることのできる少なくとも一つのデータ交換チャネルを識別する、データ交換チャネル識別過程（５０）を含み、
該識別は交換チャネルの検索過程（５００）の結果行われるものであり、
該データ交換チャネル識別過程において、第一端末（Ｔ１）が、専ら記述的なフィールドの一つに前記シグナリング・プロトコルに加えて追加情報が与えられたリクエストに対する第二端末（Ｔ２）の少なくとも一つの応答を分析することを特徴とする、請求項１に記載の方法。
【請求項３】
前記交換チャネルの検索過程（５００）が、第二端末（Ｔ２）が第一端末（Ｔ１）のリクエストに対する応答メッセージの全体を送信する過程（５１０）を含むことを特徴とする、請求項２に記載の方法。
【請求項４】
選択されたデータ交換チャネルがマルチメディア情報を最初から最後まで配信するために用いられることを特徴とする、請求項１〜請求項３のいずれか一つに記載の方法。
【請求項５】
前記データ交換チャネル選択過程（５２）において、追加情報の複数の伝送メソッドを並行して用いるために、複数のデータ交換チャネルが選択されることを特徴とする、請求項１〜請求項４のいずれか一つに記載の方法。
【請求項６】
シグナリング情報およびシグナリング・メッセージを介してアプリケーション・データを最初から最後まで伝達する能力を有した通信インフラを介して、第一端末（Ｔ１）のクライアント（Ａ１）と、サーバ（３）との間において通信手段をリアルタイムで調整（ｎｅｇｏｃｉａｔｉｏｎ）する過程をさらに含むことを特徴とする、請求項１〜請求項５のいずれか一つに記載の方法。
【請求項７】
ＳＩＰプロトコルに加えて追加情報を伝送する過程（５５）のために、
−セッションの特徴が述べられたＳＩＰパケットのヘッダー、
−応答コードの記述、
−Ｃａｌｌ＿ＩＤ、
−Ｂｒａｎｃｈ、
−ＴＡＧ、
というフィールドの少なくとも一つが用いられることを特徴とする、請求項１〜請求項６のいずれか一つに記載の方法。
【請求項８】
ＳＩＰプロトコルのＭＥＳＳＡＧＥメソッドに関連づけられた少なくとも一つのフィールドが、ＳＩＰプロトコルに加えて追加情報を伝送する過程（５５）のために用いられることを特徴とする、請求項１〜請求項７のいずれか一つに記載の方法。
【請求項９】
ＳＩＰの有効な記載（ｃｈａｒｇｅ  ｕｔｉｌｅ）であるＳＤＰ情報に関連づけられた少なくとも一つのフィールドが、ＳＩＰプロトコルに加えて追加情報を伝送する過程（５５）のために用いられ、ＳＩＰの有効な記載におけるこのＳＤＰフィールドがＳＩＰプロトコルによってオプション的に定義され、あるいは、ＳＩＰプロトコルによって固定されていない構造および構文を有していることを特徴とする、請求項１〜請求項８のいずれか一つに記載の方法。
【請求項１０】
ＳＩＰプロトコルのＣａｌｌ＿ＩＤフィールドがＳＩＰプロトコルに加えて追加情報を伝送する過程（５５）のために用いられることを特徴とする、請求項１〜請求項９のいずれか一つに記載の方法。
【請求項１１】
前記の追加情報を伝送する過程（５５）の際に伝送されるマルチメディア・コンテンツの消費／使用条件が、ＳＩＰプロトコルを介して搬送される追加情報の受信において、およびそれらの追加情報を考慮して、マルチメディア・コンテンツを消費するマルチメディア・アプリケーションによって変更されることを特徴とする、請求項１〜請求項１０のいずれか一つに記載の方法。
【請求項１２】
前記の追加情報を伝送する過程（５５）の際に伝送されるマルチメディア・コンテンツの前記消費／使用条件が、第二端末（Ｔ２）が使用可能なトランスポートネットワークの環境の変化に応じて変更されることを特徴とする、請求項１〜請求項１１のいずれか一つに記載の方法。
【請求項１３】
前記の追加情報を伝送する過程（５５）の際に伝送されるマルチメディア・コンテンツの前記消費／使用条件が、第二端末（Ｔ２）の地理的位置の条件の変化に応じて変更されることを特徴とする、請求項１〜請求項１２のいずれか一つに記載の方法。
【請求項１４】
前記の追加情報を伝送する過程（５５）の際に伝送されるマルチメディア・コンテンツの前記消費／使用条件が、第二端末（Ｔ２）に内在的な作動条件の変化に応じて変更されることを特徴とする、請求項１〜請求項１３のいずれか一つに記載の方法。
【請求項１５】
前記の追加情報を伝送する過程（５５）の際に伝送されるマルチメディア・コンテンツの前記消費／使用条件が、第二端末（Ｔ２）によって受信されるサービスの提供条件の変化に応じて変更されることを特徴とする、請求項１〜請求項１４のいずれか一つに記載の方法。
【請求項１６】
二つの通信端末（１，２）の間で確立された伝送ストリームの消費／使用条件が、ＳＩＰプロトコルを介して搬送される追加情報の送信、受信において、およびそれらの追加情報を考慮して、各端末のマルチメディア・コンテンツを消費および送信するマルチメディア・アプリケーションによって変更されることを特徴とする、請求項１〜請求項１５のいずれか一つに記載の方法。
【請求項１７】
識別されたセッション外で交換チャネルの少なくとも一つに使用可能な帯域幅を評価する過程を含むことを特徴とする、請求項１〜請求項１６のいずれか一つに記載の方法。
【請求項１８】
第二端末（Ｔ２）のレベルで使用条件が変更されたときにサービスをリアルタイムで再調整する過程であって、ディスプレイで視覚化される動画ウィンドウのサイズを変更することで帯域幅の消費を減少させるために実現される再調整過程を含むことを特徴とする、請求項１〜請求項１７のいずれか一つに記載の方法。
【請求項１９】
マルチメディア情報を伝送するためにセッション外で利用することのできる、識別された交換チャネルのリストを、二つの端末（Ｔ１、Ｔ２）のそれぞれのメモリに記憶する過程を含むことを特徴とする、請求項１〜請求項１８のいずれか一つに記載の方法。
【請求項２０】
シグナリング・プロトコルはＳＩＰプロトコルであり、前記プロトコルに加えて追加情報を伝送する過程（５５）が、
−第一端末（Ｔ１）がリクエストをテキスト・フォーマットで記述する過程と、
−該リクエストをエンコードする過程と、
−エンコードされたリクエストをＣａｌｌ−ＩＤフィールドに渡してＩＮＶＩＴＥメッセージを送信する過程を含んでいることを特徴とする、
請求項１〜請求項１９のいずれか一つに記載の方法。
【請求項２１】
前記プロトコルに加えて追加情報を伝送する過程（５５）がさらに、
−一時的に利用できない状態であることを表す表示を含み、リクエストに対する応答が第二端末（Ｔ２）によって専ら記述的または説明的なフィールドに位置づけられている応答メッセージを送信する過程と、
−ＳＩＰセッションの終了を確認する過程であり、第一端末（Ｔ１）が第二端末（Ｔ２）に同一のＣａｌｌ−ＩＤフィールドを用いて肯定応答メッセージＡＣＫを送信することで、リクエストに対する応答を確実に受信したことを示す過程を含んでいることを特徴とする、
請求項２０に記載の方法。
【請求項２２】
専ら記述的または説明的な前記フィールドが「Ｒｅａｓｏｎ」フィールドであることを特徴とする、請求項２１に記載の方法。
【請求項２３】
ネットワーク（Ｎ）との通信端末（Ｔ１、Ｔ２、４）のメモリに直接搭載することのできる処理モジュールのプログラムであり、前記プログラムが端末（Ｔ１、Ｔ２、４）上で実行されたときに請求項１から請求項５のいずれか一つに記載の方法における各過程を命令（ｃｏｍｍａｎｄｅｒ）するようになっていることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ（インターネット・プロトコル）テレフォニープロトコルまたはマルチメディア・セッションを確立するプロトコルを用いた電気通信（ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ）に関するものであり、より特徴的には、事業主（ｏｐｅｒａｔｅｕｒ）によって管理されるネットワーク内での通信チャネルの確立を制御することを目的とした、マルチメディア・セッションの管理方法および管理システムに関するものである。
【背景技術】
【０００２】
よく知られているデータ・ネットワークはインターネットである。ＩＰ（インターネット・プロトコル）ドメインでは、データ・ネットワークはオープンであり、このことは、どのような端末であっても、たとえば同一のシグナリング・プロトコルを用いていっしょに（ｄｅｕｘ  ａ  ｄｅｕｘ）通信ができることを意味している。したがって、マルチメディアタイプのセッションを、インターネット網を介し、二つの通信端末の間で作り出すことができる。ボイス・ネットワークとデータ・ネットワークの収束（ｃｏｎｖｅｒｇｅｎｃｅ）は、適合化されたシグナリング・プロトコルを利用することで可能となる。
【０００３】
ボイス・オーバーＩＰの技術すなわちＶｏＩＰと、より一般的に、マルチメディア・セッションの確立を可能とする技術は、ＳＩＰプロトコル（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  ｐｒｏｔｏｃｏｌ）を用いることが最も多く、該ＳＩＰは相互運用可能なオープンスタンダードである。たとえば、Ｈ３２３、ＭＧＣＰ（Ｍｅｄｉａ  Ｇａｔｅｗａｙ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）およびＭｅｇａｃｏ（この後者のプロトコルはＭｅｄｉａ  Ｇａｔｅｗａｙｓというゲートウェイを制御するために３ＧＰＰによってＵＭＴＳ規格で採用されている）といったその他のシグナリング・プロトコルもマルチメディア・セッションのために用いることができる。
【０００４】
ＳＩＰプロトコルはＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）によって標準化され、特にＲＦＣ  ３２６１に記載されている。ＳＩＰプロトコルは、Ｈ３２３プロトコルおよびＭＧＣＰプロトコルと同様に、マルチメディア・セッションを確立（ｅｔａｂｌｉｒ）、変更（ｍｏｄｉｆｉｅｒ）および終了（ｔｅｒｍｉｎｅｒ）するために設計された。該プロトコルは複数の参加者の認証（ａｕｔｈｅｎｔｉｆｉｃａｔｉｏｎ）とローカライゼーション（ｌｏｃａｌｉｓａｔｉｏｎ）を担当する。また、該プロトコルは、ＳＤＰ（Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）メッセージをカプセル化（ｅｎｃａｐｓｕｌｅｒ）し、さまざまな参加者によって利用可能なメディア・タイプについての調整（ｎｅｇｏｃｉａｔｉｏｎ）も担当している。ＳＩＰプロトコルはセッションの間、音声や動画といった交換されるデータはトランスポート（ｔｒａｎｓｐｏｒｔｅｒ）しない。このプロトコルはデータの伝送から独立しているため、あらゆるタイプのデータおよびプロトコルをこの交換のために用いることができる。すなわち、音声セッションおよび動画セッションを保証するのはほとんどの場合においてＲＴＰプロトコル（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）である。ＳＩＰプロトコルの利点は、ボイス・オーバーＩＰだけではなく、テレビ電話、インスタント・メッセージ、バーチャル・リアリティまたはテレビ・ゲームといった他の多くの応用も対象としていることである。
【０００５】
あらゆるシグナリング・プロトコルと同様に、ＳＩＰは、接続ネットワーク（ｒｅｓｅａｕ  ｄｅ  ｒａｔｔａｃｈｅｍｅｎｔ）に宣言する段階と、マルチメディア・セッションの確立を要求する段階、要求されたサービスの特徴（ｃａｒａｃｔｅｒｉｓｔｉｑｕｅ）を調整する段階、そして、マルチメディア・セッションを閉じる段階を含んでいる。ＳＩＰプロトコル（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）の開始プロトコルによって、ｖ２．０から、マルチメディア・セッションの前または間に、通信中のエンティティ間における情報の交換が可能となっている。それ自体は既知の方法により、この交換は以下のメソッドによって実現することができる。
−ＩＮＦＯ：コール状態に影響を与えない情報の交換を可能にする（ＲＦＣ  ２９７６に記載）。ある場合には、このフィールドはＤＴＭＦトーンを転送するために用いられる。
−ＮＯＴＩＦＹ：イベント通知の送信を可能にする（ＲＦＣ  ３２６５）。
−ＳＵＢＳＣＲＩＢＥ：イベント通知への参加を可能にする（ＲＦＣ  ３２６５に記載）。
−ＵＰＤＡＴＥ：メディア・パラメータを更新するために用いられる（ＲＦＣ  ３３１１参照）。
−ＭＥＳＳＡＧＥ：ＲＦＣ  ３４２８「インスタント・メッセージへのＳＩＰの拡張」で定義されているこのメソッドによって、二つの端末間でインスタント・メッセージを交換することが可能となる。
【０００６】
たとえば無線電話網では、このようなプロトコル（ＳＩＰ／Ｈ３２３／ＭＧＣＰ）をマルチメディア・セッションに利用することによって、ボイス・チャネルに並行なデータ・チャネルを介する情報交換を可能にすることができる。しかし、これらの情報交換メソッドの不都合は、該メソッドが、基底（ｓｏｕｓ‐ｊａｃｅｎｔ）にあるネットワークおよび／または単純な端末では必ずしもサポートされていないということである。
また、特許文献１には、複数の端末間でアドレス体系が異なるネットワークに属するＳＩＰサーバを経由してＳＩＰのメッセージを送受信を行い、メディアの伝達を行うときに、ＮＡＴ装置にかかる負荷を軽減することを目的とするＳＩＰ通信制御装置が記載されている。
しかし、係るＳＩＰ通信制御装置もまた、行っているのはＳＩＰメッセージの送受信であり、該ＳＩＰメソッドが、基底にあるネットワークおよび／または単純な端末では必ずしもサポートされているとはいえない。
【特許文献１】特許第３９８０５６２号明細書
【非特許文献１】ＲＦＣ  ３２６１
【非特許文献２】ＲＦＣ  ２９７６
【非特許文献３】ＲＦＣ  ３２６５
【非特許文献４】ＲＦＣ  ３３１１
【非特許文献５】ＲＦＣ  ３４２８
【発明の開示】
【発明が解決しようとする課題】
【０００７】
したがって、本発明は、このタイプのプロトコルをサポートするネットワークのインフラの潜在能力を最大限に利用し、シグナリング・プロトコルの新たな利用を可能にする方法を定義することで、先行技術の一つまたは複数の不都合な点を解消することを目的とする。
【課題を解決するための手段】
【０００８】
そのため、本発明による教示は、マルチメディア・セッションの確立に必要な基本メソッドを用いる方法と、該基本メソッドをネットワーク全体によって伝達させる方法を示すものである。規格に合致した新たな使用法を介して、たとえばこれらの単純なメソッドは、既に確立されているマルチメディア・セッションについて調整された質をリアルタイムで再調整するといった問題を解決することができる。
【０００９】
そのため、本発明は、電気通信ネットワークによって互いに接続された少なくとも二つの通信端末の間でマルチメディア情報の伝送を可能とするための交換チャネルの確立を制御する方法に関するものであり、第一の通信端末と第二の通信端末の間で、セッションの開始を可能にする所定のシグナリング・プロトコルを管理するそれぞれのアプリケーションを用いて通信を確立する過程を含み、第一端末が二つの端末の間における少なくとも一つのデータ交換チャネルを選択する過程を実行し、該選択過程がアプリケーション・レベルで行われることと、前記通信の確立過程が、
−所定のシグナリング・プロトコルにしたがってセッションを開くことにより、第一端末が第二端末に向けて少なくとも一つのリクエストを発信する過程と、
−所定のシグナリング・プロトコルにしたがってセッションを閉じるために、第二端末が、利用できない状態であることを表す応答を送信する過程
を含むことを特徴としており、
本方法は、前記発信過程および送信過程の際に、選択された前記データ交換チャネルを用いて、前記シグナリング・プロトコルに加えて追加情報を伝送する過程を含んでおり、このデータ交換チャネルは、セッションの特徴を専ら（ｐｕｒｅｍｅｎｔ）記述する／説明するフィールドを介してアクセス可能であり、前記追加情報はマルチメディア・セッションの管理に必要ではないアプリケーション情報に対応するものである。
【００１０】
こうして、本発明によって、ネットワーク事業主のインフラ（ＳＩＰまたは特にＩＭＳ）を先進的に／異例な方法で使用することを可能にするアプリケーション・レベルでの解決法の創出を制御することが可能となる。シグナリング・プロトコル（たとえばＳＩＰ）に内在的な機能の仕方が変化しないままであることで、世界規模の基本的なネットワークのインフラを利用することができるようになっている。本方法が、好適にはシグナリング・プロトコルのメソッドの使用を拡大し、たとえば、通信しているエンティティ間で割り当てられたデータ・チャネル（ＲＴＰ）以外によって、サービスおよび／または該サービスの質および提供に関してシグナリング情報を交換することを可能にすることが分かる。この斬新な経路（コンテキスト・フィールドを介する）によるアプリケーション情報の交換によって、リアルタイムでのサービスを保証することができる。
【００１１】
もう一つの特徴によると、本方法は、第一端末によって、追加情報の伝送過程に用いることのできる少なくとも一つのデータ交換チャネルを識別する過程を含んでおり、該識別は交換チャネルの検索過程の結果行われるものであって、該識別過程において、第一端末は、専ら記述的なフィールドの一つに前記シグナリング・プロトコルに加えて追加情報が与えられたリクエストに対する第二端末の少なくとも一つの応答を分析する。
【００１２】
もう一つの特徴によると、交換チャネルの検索過程は、第二端末によって第一端末のリクエストに対する応答メッセージ全体を送信する過程を含んでいる。
【００１３】
もう一つの特徴によると、選択されたデータ交換チャネルはマルチメディア情報を最初から最後まで配信するために用いられる。
【００１４】
もう一つの特徴によると、選択過程は、追加情報の複数の伝送メソッドを並行して用いるために、複数のデータ交換チャネルを選択することを含んでいる。
【００１５】
もう一つの特徴によると、本方法は、シグナリング情報およびシグナリング・メッセージを介してアプリケーション・データを最初から最後まで伝達する能力を有した通信インフラを通して、第一端末のクライアントとサーバの間において通信手段をリアルタイムで調整する過程を含んでいる。
【００１６】
もう一つの特徴によると、以下のフィールドの少なくとも一つが、ＳＩＰプロトコルに加えて追加情報を伝送する過程のために用いられる。該フィールドとは、
−セッションの特徴が述べられたＳＩＰパケットのヘッダー、
−応答コードの記述、
−Ｃａｌｌ＿ＩＤ、
−Ｂｒａｎｃｈ、
−ＴＡＧ、
である。
【００１７】
もう一つの特徴によると、ＳＩＰプロトコルのＭＥＳＳＡＧＥメソッドに関連づけられた少なくとも一つのフィールドが、ＳＩＰプロトコルに加えて追加情報を伝送する過程のために用いられる。
【００１８】
もう一つの特徴によると、ＳＩＰの有効な記載（ｃｈａｒｇｅ  ｕｔｉｌｅ）であるＳＤＰ情報に関連づけられた少なくとも一つのフィールドが、ＳＩＰプロトコルに加えて追加情報を伝送する過程のために用いられ、ＳＩＰの有効な記載におけるこのＳＤＰフィールドは、ＳＩＰプロトコルによってオプション的に定義され、あるいは、ＳＩＰプロトコルによって固定されていない構造および構文を有している。
【００１９】
もう一つの特徴によると、ＳＩＰプロトコルのＣａｌｌ＿ＩＤフィールドは、ＳＩＰプロトコルに加えて追加情報を伝送する過程のために用いられる。
【００２０】
もう一つの特徴によると、前記伝送過程の際に伝送されるマルチメディア・コンテンツの消費／使用条件は、ＳＩＰプロトコルを介して搬送される追加情報の受信において、およびそれらの追加情報を考慮して、マルチメディア・コンテンツを消費するマルチメディア・アプリケーションによって変更される。
【００２１】
もう一つの特徴によると、二つの通信端末の間で確立された伝送ストリームの消費／使用条件は、ＳＩＰプロトコルを介して搬送される追加情報の送信、受信において、およびそれらの追加情報を考慮して、各端末のマルチメディア・コンテンツを消費および送信するマルチメディア・アプリケーションによって変更される。
【００２２】
この考慮は、事前に二つのマルチメディア・アプリケーションによって共有されるプロトコルにしたがって計画することができる。
【００２３】
もう一つの特徴によると、本方法は、識別されたセッション外で交換チャネルの少なくとも一つに使用可能な帯域幅を評価する過程を含んでいる。
【００２４】
もう一つの特徴によると、本方法は、使用条件が、基底にあるＳＩＰネットワークを介した追加情報の発信によって変更されたとき、マルチメディア・サービスの提供をリアルタイムで再調整する過程を含んでおり、該再調整過程は、第二端末によってこの使用条件の変更を、
−第二端末が使用可能なトランスポートネットワーク環境の変化（たとえばＷｉｆｉネットワークあるいはローカル接続ネットワークおよび／またはパーベイシブ（ｐｅｒｖａｓｉｆ）接続ネットワークの検出）、
−第二端末の地理的位置の条件（ＧＰＳ位置測位タイプの情報、またはモバイル・ネットワークの接続セルまたは接続ネットワーク（ｒｏａｍｉｎｇ／ローミング）に基づく）、
−たとえば無線環境の変化、使用可能なエネルギー（バッテリ）の変化、第二端末内部で実行中のタスクの数に応じた前記第二端末の内部プロセッサの使用可能容量（ｄｉｓｐｏｎｉｂｉｌｉｔｅ）の変化（とりわけ該端末がモバイル端末のとき）による、第二端末自体の作動条件、
−たとえば接続時間にしたがった時間の区切りによるペイメント（ｐａｉｅｍｅｎｔ）、表示解像度および描写色数に応じたペイメント、地理的な位置にしたがって劣化するサービス、第二端末が不確実なゾーンに位置したために補足の暗号化あるいは補足の認証を必要とするサービスのような、
サービスの使用条件および消費条件、
に応じて検出することを含んでいる。
【００２５】
もう一つの特徴によると、再調整過程は、ユーザの特定の動作にしたがってマルチメディア・サービスの提供条件を変更するために実現される。したがって、ユーザが、ＴＶ／動画のストリーミングのフローをアイコニファイ（ｉｃｏｎｉｆｉｅｒ）して、一時的に帯域幅の消費量を減少させることも可能である。換言すれば、たとえば第二端末のレベルで使用条件が変更されたとき、再調整過程によって、ディスプレイで視覚化できる動画ウィンドウのサイズを変更することが可能となる。
【００２６】
もう一つの特徴によると、本方法は、マルチメディア情報を伝送するためにセッション外で利用することのできる、識別された交換チャネルのリストを、二つの端末のそれぞれのメモリに記憶する過程を含んでいる。
【００２７】
もう一つの特徴によると、シグナリング・プロトコルはＳＩＰプロトコルであり、前記プロトコルに加えて追加情報を伝送する過程は、
−第一端末によってリクエストをテキスト・フォーマットで記述する過程と、
−該リクエストをエンコードする過程と、
−エンコードされたリクエストをＣａｌｌ−ＩＤフィールドに渡してＩＮＶＩＴＥメッセージを送信する過程、
を含んでいる。
【００２８】
もう一つの特徴によると、前記プロトコルに加えて追加情報を伝送する過程はさらに、
−一時的に利用できない状態であることを表す表示を含む応答メッセージであって、リクエストに対する応答が第二端末によって専ら記述的または説明的なフィールドに位置づけられているような応答メッセージを送信する過程と、
−ＳＩＰセッションの終了を確認する過程であり、第一端末が第二端末に同一のＣａｌｌ−ＩＤフィールドを用いて肯定応答メッセージＡＣＫを送信することで、リクエストに対する応答（最終的な）を確実に受信したことを示す過程、
を含んでいる。
【００２９】
もう一つの特徴によると、専ら記述的または説明的な前記フィールドは「Ｒｅａｓｏｎ」フィールド（通常、リクエストの拒絶理由または許可理由の役割を果たす）である。
【００３０】
補足的な目的の一つは、ネットワーク上の通信端末内に、シグナリング・プロトコルの新たな利用を、このタイプのプロトコルをサポートするネットワークのインフラの潜在能力を最大限に利用することによって可能にするアプリケーションを提案することである。
【００３１】
そのため、本発明は、ネットワークと通信する端末のメモリに直接搭載することのできる処理モジュールのプログラムに関するものであり、該プログラムは、前記プログラムが端末上で実行されたとき、本発明による方法の各過程を命令（ｃｏｍｍａｎｄｅｒ）するようになっている。
【発明を実施するための最良の形態】
【００３２】
本発明の特徴および利点は、非制限的な例示として示した添付図面に関連する説明を読むことでより明らかになるものであり、該添付図面において、
−図１は、本発明の一つの実施態様における方法の各過程の論理図を示し、
−図２は、基底にあるＳＩＰネットワークとの干渉がない、端末のアプリケーションに固有のシグナリングの交換を確立する実施例を示し、
−図３は、本発明によるシステムのインジケータ（ｉｎｄｉｃａｔｅｕｒ）を用いることで検出することができる第一のコール・シナリオを示しており、
−図４は、本発明によるシステムのインジケータを用いることで検出することができる第二のコール・シナリオを示しており、
−図５は、無線電話網の事業主のネットワークが、本発明の一つの実施態様にしたがってＳＩＰリクエストを監視し、管理するシステムを備えている、ＩＰマルチメディア・サブシステム（ＩＭＳ）のコンテキストを概略的に示している。
【００３３】
本発明による方法は、ＳＩＰプロトコルまたはその他のシグナリング・プロトコルの特性（ｓｐｅｃｉｆｉｃｉｔｅ）を用いて、アプリケーション・レベルでのシグナリングの交換メソッドを提案することを目的とするが、世界規模のネットワークのインフラを利用できるようにするために、シグナリング・プロトコルに内在的な作動を侵害することは決してない。図２の実施例では、用いられるアプリケーションに固有のシグナリングの交換は端末（Ｔ１、Ｔ２、４）のアプリケーション（Ａ１、Ａ２、Ａ４）の間で確立されなければならない。シグナリング情報は、基底にあるＳＩＰネットワークと干渉せずにこれらのアプリケーション（Ａ１、Ａ２、Ａ４）の間で交換することができる。本方法には、単純な通信シナリオにおける情報交換の複数の可能な手段を識別することが用意されており、非制限的な例示としてはＩＮＶＩＴＥ、応答、ＡＣＫとＢＹＥである。
【００３４】
ＩＮＶＩＴＥメソッドは、ＳＩＰの特定されたＵＲＬアドレスに対応するアプリケーション（すなわちユーザ）がセッションに参加するよう招待されていることを示し（メッセージのボディはこのセッションを記述し、たとえばコールする側によってサポートされるメディアを記述する）、肯定応答の場合、招待された側はサポートするメディアを特定しなければならない。また、ＲＥ−ＩＮＶＩＴＥメソッドも存在している。
【００３５】
ＳＩＰメッセージのフォーマットは変わらないままである。ここで、ＳＩＰメッセージがクライアント（コールする端末）によるサーバ（コールされる端末）へのリクエストであると同時に、サーバによるクライアントへの応答でもありうることが思い出される。たとえば、クライアントによるサーバへのＳＩＰリクエストは以下のように表すことができる。
【００３６】
【表１】
2008148313.tif 000003
【００３７】
サーバによるクライアントへのＳＩＰリクエストは以下のように表すことができる。
【００３８】
【表２】
2008148313.tif 000004
【００３９】
リクエストの場合、（メッセージの）ボディが、用いられるメソッドに応じて加えられる、または加えられない。たとえばＩＮＶＩＴＥメソッドであるとき、ＩＮＶＩＴＥリクエストのメッセージ・ボディはリクエストの進行を示す情報を含んでいる。応答の場合、メッセージ・ボディは義務的である。したがって、ＩＮＶＩＴＥリクエストへの応答はメッセージ・ボディにセッションの記述を含んでいる。
【００４０】
端末（Ｔ１）を介してＳＩＰインフラを用いる加入者は、通常、該インフラに接続している。該加入者は認証段階をパスしており、ＳＩＰプロキシ・サーバ（３）に登録を済ましている。本発明による方法の原理を用いてサービスを確立しようとする加入者は、クライアントと呼ばれる自身の端末（Ｔ１）のアプリケーション（Ａ１）を起動することになり、該アプリケーションは、用いられるＳＩＰインフラの潜在能力を“スキャン”する第一の段階に入る。これを行うため、加入者の搭載クライアントはリクエストの全体を、サービスを提供するサーバ（３）に発信し、あるいは、リクエストされるサービスがピアツーピア「Ｐｅｅｒ  ｔｏ  Ｐｅｅｒ」（Ｐ２Ｐ）タイプであれば、別の加入者（端末Ｔ２）に発信する。
【００４１】
ＳＩＰプロトコルはテキスト・フォーマットのリクエストの送信に基づいている。リクエストは、ＩＮＶＩＴＥ、ＯＰＴＩＯＮＳ、ＡＣＫ、ＢＹＥ、ＲＥＧＩＳＴＥＲ、ＣＡＮＣＥＬあるいはＭＥＳＳＡＧＥ（ＲＦＣの拡張で定義されている）といったプロトコルのＲＦＣで定義されたメソッドを用いる。各リクエストは複数のヘッダー（一般的には１０程度だが、数は拡張できる）と、場合によってはメッセージ・ボディを含んでいる。付属文書１は電話コールを確立するＳＩＰリクエストの実施例を示している。付属文書１に記載されている手続きは図３に示された一連の過程に関わるものである。この実施例において、コールが確立するということは、ＳＩＰインフラの挙動に影響を与えることに注意しなければならない。
【００４２】
Ｃａｌｌ−ＩＤ、ｂｒａｎｃｈ、ｔａｇのフィールドは送信端末（Ｔ１）によって選択され、ＳＩＰインフラによって受信端末（Ｔ２）まで伝達される。これらのフィールドはフォーマットにほとんど制約がないため、送信端末（Ｔ１）の追加情報を受信端末（Ｔ２）に送信するために簡単に用いることができる。本発明の一つの実施態様では、本方法を実施するために、規格によって用意されているこの簡便さを利用する手段が用意されている。そのため、送信端末（Ｔ１）は、これらのフィールドの利用を可能にするスクリプトを備えた処理エージェントを含んでいる。
【００４３】
また、第二の端末である受信端末（Ｔ２）が、第一端末（Ｔ１）にプロトコルに加えて情報を発信できるようにするための説明コンテキスト・フィールドを利用できることも分かる。第一端末（Ｔ１）によって発信された値が与えられているＣａｌｌ＿ＩＤフィールドを備えたステータス・メッセージの受信は、「Ｃａｌｌ−ＩＤ」フィールドに搬送されてきたデータが第二端末（Ｔ２）によって確かに考慮されたことに関する情報を与える。並行して、第一端末（Ｔ１）は第二端末（Ｔ２）に肯定応答ＡＣＫを返し、該第二端末に「ｆｒｏｍ」フィールドに関連づけられたＴＡＧを介して応答が確実に考慮されたことを伝えることができる。
【００４４】
図２を参照すると、ＳＩＰネットワーク（Ｎ）はルーティング・オプション（点線）のトポロジーの利用を可能にする、ＩＰプロトコル（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）の第一ドメイン（１５）と、無線電話網（１６）に対応する第二のドメインを含んでいる。ＲＴＣ（Ｒｅｓｅａｕ  Ｔｅｌｅｐｈｏｎｉｑｕｅ  Ｃｏｍｍｕｔｅ）タイプのドメインもＳＩＰネットワーク（Ｎ）の一部を構成することができる。
【００４５】
好ましい実施態様では、図２に示されたＳＩＰネットワーク（Ｎ）はＩＭＳサブシステム（ＩＰ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｕｂｓｙｓｔｅｍ）を備えたサービス・アーキテクチャを用いており、該サブシステムによってボイス・オーバーＩＰ技術を展開することが可能となっている。ＳＩＰネットワーク（Ｎ）はステーションを備えた無線電話網（１６）と有線接続部分を含むように表示しているが、ネットワーク（Ｎ）ではどのような無線接続を用いることもできることが理解されるものであり、該ネットワーク（Ｎ）は無線接続（無線、ＷｉＦｉ、Ｗｉｍａｘ、Ｂｌｕｅｔｏｏｔｈ（登録商標）など）のみを用いることもできる。
【００４６】
図２の実施例において、ＩＰドメイン（１５）は複数のネットワーク要素を備えており、とりわけ、メディア・ゲートウェイ（２）（ｍｅｄｉａ  ｇａｔｅｗａｙ）、プロキシ・サーバ（３）ならびに第一および第二のユーザ端末（Ｔ１、Ｔ２）を備えている。各端末（Ｔ１、Ｔ２）は、無線電話網（１６）を介して接続された無線通信端末（４）、たとえば携帯電話との通信を確立する際、ルーティング・オプションのトポロジーの一部を用いることができる。この場合、プロキシ・サーバ（３）およびゲートウェイ（２）が用いられる。したがって、第一および第二の端末は、ＳＩＰプロキシ・サーバ（３）を利用することで、この場合はゲートウェイ（２）を使わずに互いに通信することができる。
【００４７】
図１を参照すると、本方法はシグナリング・プロトコルを介してアクセス可能なデータ交換チャネルを利用することで、マルチメディア・セッションの管理に必要となる情報以外の情報を最初から最後まで配信するようにすることを計画している。本方法によって、電気通信ネットワーク（Ｎ）によって互いに接続された通信端末（Ｔ１、Ｔ２、４）の間でマルチメディア情報の伝送を可能にするための交換チャネルの確立が制御される。
【００４８】
図１および図２を参照すると、第一の通信端末（Ｔ１）と第二の通信端末（Ｔ２）の間における通信を確立する過程（５１）は、シグナリング・プロトコルを管理するそれぞれのアプリケーション（Ａ１、Ａ２）を用いることで実現される。第一端末（Ｔ１）は二つの端末（Ｔ１、Ｔ２）の間の交換チャネルを検索する過程（５００）を実行する。したがって、この交換チャネルの検索過程（５００）は、アプリケーション情報を交換することが可能な手段をインデックス化することを可能にし、交換チャネルは後の選択過程（５２）で選択されることができる。少なくとも一つの交換チャネルを第一端末（Ｔ１）によって識別する過程（５０）は、第一端末（Ｔ１）によって、たとえば検索過程（５００）の際に発信されたリクエストの一つに対する応答メッセージを受信するごとに実現することができる。
【００４９】
通信の際、本方法は、
−所定のシグナリング・プロトコルにしたがってセッションを開くことにより、第一端末（Ｔ１）から第二端末（Ｔ２）に向けて一つまたは複数のリクエストを発信する過程（５３）と、
−所定のシグナリング・プロトコルにしたがってセッションを閉じるために、第二端末（Ｔ２）によって利用できない状態であることを表す応答を送信する過程（５４）、
を含むことができる。
【００５０】
本発明の実施態様では、本方法は選択された前記交換チャネルを用いることで、マルチメディア情報を伝送する過程（５５）を含んでいる。この交換チャネルを利用することは、マルチメディア情報の転送開始がＳＩＰリクエストのメッセージ・ボディを用いて実行される従来のセッションの際に用いられる経路にはまったく相当しないことが分かる。有利には、このチャネルを介した追加情報の伝送過程（５５）は、前記発信過程および送信過程（５３、５４）の際に、前記シグナリング・プロトコルに加えて行われる。
【００５１】
この伝送過程（５５）は、たとえば交換チャネルの選択過程（５２）の後に実現される。これら二つの過程（５２、５５）はそれぞれ、たとえばアプリケーション・レベルで開始される。交換チャネルの検索過程（５００）は、第二端末（Ｔ２）によって、第一端末（Ｔ１）のリクエストに対する応答メッセージの全体を送信する過程（５１０）を含むことができる。このことによって、それぞれのアプリケーション（Ａ１、Ａ２）のレベルで、使用可能な並行チャネルを識別し、インデックス化することが可能となる。
【００５２】
通信チャネルの転用利用の原理の基底にある複数のメソッドをこれから説明することとする。記載した実施例はＳＩＰプロトコルに焦点をあてているが、その他のシグナリング・プロトコル（ＳＩＰ、Ｈ３２３、ＭＧＣＰ、Ｍｅｇａｃｏ）に拡張することも可能であると理解されるものである。
【００５３】
未定義フィールドのメソッド
提案する技術は、ＳＩＰプロトコルによって提案されるエンコーディングの簡便性を巧く利用し、信号の上でアプリケーション・レベルのデータを交換することに基づいている。単純に交換するために利用可能な四つのメソッドに焦点をあて、それらを多かれ少なかれ結合させる、つまり、すべての使用ケースを一般化することができる。制御方法はこれら四つのメソッドに制限されるものではないと理解されるものである。なぜなら、本解決法は、進行中のストリーミングのフローの消費量がいくらであれ、より一般的に、常に存在する信号トランスポートを用いることを対象としているからである（付属文書１および付属文書２におけるＢｏｂとＡｌｉｃｅの間における交換の記述を参照）。以下の四つのメソッドを挙げることができる。すなわち、
−ＳＩＰパケットのヘッダー（セッションの特徴）、
−応答コードの記述（ｒｅｑ２００  ＯＫ）、
−Ｃａｌｌ  ＩＤ（＜ＣＳｅｑ＞）、
−ＴＡＧ（またはＢＲＡＮＣＨ）、
である。
【００５４】
このように、プロトコル（ＳＩＰまたはその他）で提案され、セッションの特徴をより詳細化するためのメッセージに含むことのできる複数のヘッダーは、情報を信号に転移させることができる。同様に、任意のプロトコルにおけるリクエストに対する応答は、コードとコード記述（たとえば、ＳＩＰについて２００はＯＫ、３０１はＭｏｖｅｄ  Ｐｅｒｍａｎｅｎｔｌｙ、４０４はＮｏｔ  Ｆｏｕｎｄなど）で構成され、情報を信号に転移させることができ、たとえば、「応答  ２００  Ｂｏｎｊｏｕｒ」となる。
【００５５】
ＭＥＳＳＡＧＥメソッドの内部に含まれるメソッド
端末（Ｔ１）のアプリケーション（Ａ１）はＳＩＰプロトコルのＭＥＳＳＡＧＥメソッドにおいてトランスポートされるリクエストを作成するのだが、該リクエストのフォーマットは、該端末がアクセス／通信しようとしているサーバ／受信者との間で事前に確立されている。このとき、搭載されたエージェントは記述情報のサーバ（３）と通信できるかどうかテストする。ＳＩＰネットワーク（Ｎ）がＭＥＳＳＡＧＥメソッドを伝達するのであれば、それは二人のユーザ（ＢｏｂとＡｌｉｃｅ）の間におけるアプリケーション（Ａ１、Ａ２）の間でトランスポートし、データ交換を確立する最も単純な方法である。ＭＥＳＳＡＧＥメソッドの唯一の不都合は、基底にあるネットワークがインスタント・メッセージ・サービスを実施している場合に、我々の問題意識としては、マルチメディア・コンテンツの提供の質に関する条件の再調整がシグナリング行為については課金されるべきではないのに、該メソッドが課金される可能性があることである。
【００５６】
本発明の一つの実施態様では、通信チャネルの確立を制御する方法によって、交換される情報の性質、したがってシグナリングの性質をリアルタイムで変更するために、シグナリング情報を交換することが可能となる。提供中のサービスに関するシグナリングを確立し、交換するために、課金の対象になるチャネルを使わなくてはならないのは損失となる可能性があるのである。
【００５７】
ＳＩＰプロトコルのＳＤＰ  ペイロード（ｐａｙｌｏａｄ）（ＳＩＰの有効な記載）の使用に基づくメソッド
ＳＤＰプロトコル（Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）はＲＦＣ  ２３２７［２．］に記載されており、セッションの告知または招待においてマルチキャスト・セッションを記述するために用いられる。これらの記述がすべてのフィールド、とりわけオプション・フィールドの構造および構文を必ずしも固定するわけではない。これら任意のフィールドの中には、構文的に記述されておらず、したがって開発されたサービスの意思にしたがって利用できるものもある。このことは付属文書４に巧く記載されている。非制限的な例としては、いかなるセッションも確立されていなくとも、ＩＮＶＩＴＥメッセージおよび特定の２００およびＡＣＫに含まれるＳＩＰの有効な記載、すなわちＳＤＰペイロードを、データを転送するために用いることができる。たとえば、ＳＤＰペイロードのｓ＝フィールドはセッションを記述するネームであり、並行してデータを伝送するために用いることができる。
【００５８】
ＩＮＶＩＴＥメッセージにおけるＣａｌｌ  ＩＤメソッドへの応用
これらのフィールドにフォーマットがないことにより、エージェント／クライアント（Ａ１）は自身の固有のデータを生成し、フィールドの統一性を全体として保証することを可能にする一意のデータを該固有のデータに加えることが可能となる。ＣＡＬＬ−ＩＤフィールドの内部において、
＜ｕｎｉｑｕｅ  ｉｄ＞＜ｃｏｍｍａｎｄ／ｒｅｑｕｅｓｔ＞＜ａｓｓｏｃｉａｔｅｄ  ｄａｔａ＞、
というタイプの構造の利用が容易に想像できる。
【００５９】
この識別子「ｕｎｉｑｕｅ−ｉｄ」は、加入者すなわちエージェントの識別情報と、一意の値の変数「ｔｏｔｏ＿ＭＳＩＳＤＮ＠ｓｆｒ．ｆｒ−ｕｎｉｑｕｅ  ｄａｔａ（ｔｉｍｅ）」によって構成することができ、たとえば、
ｔｏｔｏ＿０３３６０３１３１３０２０２＠ｓｆｒ．ｆｒ−１９７．１１８．０．１０＿１２ｈ３０４７ＧＭＴ、
のように構成することができる。
【００６０】
有利な実施例は以下の通りである。（事前に確立されている）ストリーミングでのコンテンツ配信の際、ストリーミングのフローを受信する端末（Ｔ２）のクライアント（Ａ２）は、サーバ（３）または発信者（Ｔ１）に対し、クライアント（Ａ２）のレベルで処理ユニットＣＰＵの使用可能容量のために一時的にストリームの質を下げる必要性があることを知らせようとしている。動画の質を値７に５分間変更するリクエストは、動作の記述フィールドに対するＡＡの間と、パラメータの記述フィールドに対するＰＰの間でコードすることができ、ＡＡｖｉｄｅｏＡＡＰＰ７＿５ＰＰとなる。
【００６１】
サーバ（３）または離れた加入者のクライアント（Ａ２）に情報を転送するために、ｃａｌｌ  ＩＤフィールドをｔｏｔｏ＿０３３６０３１３１３０２０２＠ｓｆｒ．ｆｒ−１９７．１１８．０．１０＿１２ｈ３０４７ＧＭＴ＿ＡＡｖｉｄｅｏＡＡＰＰ７＿５ＰＰと記述するようにすることができる。付属文書２は第一端末（Ｔ１）のアプリケーション（Ａ１）によって発信されたリクエストのフォーマットを示している。このとき、相手はＣＡＬＬ−ＩＤを再コピーし、応答コードの記述フィールドを介して応答またはパラメータを返送することができる。したがって、「リクエスト  動画  ７  ５  処理中（ｒｅｑｕｅｔｅ  ｖｉｄｅｏ  ７  ５  ｅｎ  ｔｒａｉｔｅｍｅｎｔ）」というメッセージは第一端末（Ｔ１）によって受信することができる。この実施例は、タイムラグの概念またはＲＴＰフレームによるリードタイムのプログラム化あるいは画像シーケンスという概念を組み込むことで複雑にすることができる。
【００６２】
プロトコルは質問／応答または命令／応答の形式で実現される。次の構造＜ｕｎｉｑｕｅ−ｉｄ＞＜ｃｏｍｍａｎｄ／ｒｅｑｕｅｓｔ＞＜ａｓｓｏｃｉａｔｅｄ  ｄａｔａ＞によって、どのようなアプリケーション層にでも伝送媒体（ベアラ）を提供することが可能となる。このように、ＣＡＬＬ−ＩＤチャネルの使用によって作動し、ＩＮＶＩＴＥメッセージを通して応答コードを記述する、ファイルの転送モジュールを再構成することは非常に単純である。ＩＮＶＩＴＥの考慮が否定であれば、ＳＩＰサーバ（３）のレベルではいかなるセッションも確立されず、構成されることもないことに注意すべきである。したがって、ファイル転送モジュールはＩＮＶＩＴＥメッセージを発信することができ、ＣＡＬＬ−ＩＤのところでは、＜ｔｏｔｏ＠ＭＳＩＳＤＮ＠ｆｒｎｃｅ＠ｓｆｒ．ｎｅｔ＞＜ｍｏｄｉｆｙ  ｖｉｄｅｏ  ｑｕａｌｉｔｙ＞＜７，５＞というリクエスト、つまり、レベル７を選択して動画の画質を５分間にわたって変更するリクエストを伴う。サーバの応答の実施例は付属文書２の最後に示している。
【００６３】
この実施例においては、クライアントがあまり確かではない環境に位置している場合、ＩＮＶＩＴＥリクエストを用いて、サーバ（３）はユーザに高いセキュリティ手段を有効化するように即座に要求することができる。
【００６４】
ＦＲＯＭフィールドはどのようなエイリアス値についても使用可能であるため、サービスのサーバと直接対話するために該フィールドを用いることができることも注目される。このフィールドは自身の内容に拘束されないため、規格による構造の義務にしたがって事前に取り決められたいかなる構造を与えることができる。ＦＲＯＭフィールドのもう一つの利点は、一般的には、このフィールドの内容が端末による受信時に表示されることである。したがって、発信された処理要求の受信時に、この要求が配信中のマルチメディア・コンテンツのサービスの質を再調整することに関係していても関係していなくても、ユーザのアクションを要求する（相互的な）サービス提供を構築することができる。
【００６５】
付属文書３を参照すると、シグナリング・プロトコルのフィールドの本発明にしたがったＳＩＰシグナリングの並行利用の枠組みでは、他の二つのフィールド、つまり、「警告（ｗａｒｎｉｎｇ）フィールド」と「理由（ｒｅａｓｏｎ）フィールド」も好適である。ＲＦＣの記載内容を読むことで、これらのフィールドがテキスト・タイプであり、失敗した際または警告の際、特にＲＴＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）の対話者間でデータ交換セッションを確立しないように求められるイベントでは義務的であることが分かる。
【００６６】
最も巧みな手段の一つは、自由なまま残されている規格フィールド全体についてアプリケーション・レベルでフォーマット規則を確立し、テキストでの説明（人間の読める：「理由フレーズは人間に解読可能でなければならない」）を与えるようにすることである。このように、情報は、通過するサーバ、ゲートウェイおよびプロキシ（２、３）のレベルではいかなる変更もなく、ＳＩＰインフラによって最初から最後まで搬送される。この情報はＳＩＰ応答およびメソッドに存在する。
【００６７】
データ・チャネルの確立を始動させないために、失敗に至るようなリクエストを発信することが避けられるようになっていることにも注目すべきである。実際、新しいデータ・チャネルは有利には二つの端末（Ｔ１、Ｔ２）の間あるいは二つ以上の端末（Ｔ１、Ｔ２、４）の間で確立し、用いることができる。
【００６８】
図５の実施態様は異なる二つの無線電話の事業主によるインフラを示しており、該インフラには、ＣＳＣＦ（Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）サーバ（３１、３２）を介するこれらのネットワークの間での通信があり、該サーバは、たとえば加入者データを入手するためにＨＳＳ（Ｈｏｍｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｓｅｒｖｅｒ）データベースを備えている。これらの無線電話網（１６、１６’）のそれぞれに用意されているゲートウェイ（２１、２１’）とスイッチ（２２、２２’）によって、メッセージを無線通信のモバイル端末（Ｔ１、Ｔ２）まで伝達することが可能となっている。ＧＴＰプロトコル（ＧＰＲＳ  Ｔｕｎｎｅｌ  Ｐｒｏｔｏｃｏｌ）により、ＧＧＳＮ（Ｇａｔｅｗａｙ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）タイプのゲートウェイ（２１、２１’）とＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）タイプのスイッチ（２２、２２’）の間で通信することが可能となる。ファイアウォール（ＦＷ）を無線電話網（１６）の少なくとも一つとインターネット・タイプのドメイン（１５）の間のインタフェースに配置することができる。
【００６９】
図５に示されたようなＩＭＳアーキテクチャによって、モバイル端末または固定端末から、ＩＰ上のＳＩＰプロトコルを用いてマルチメディア・サービスにアクセスすることが可能となる。ＩＭＳサブシステムは三層で構成され、該三層とは、
−携帯電話についてはＧＧＳＮ、ＡＤＳＬについてはＤＳＬＡＭなどといったように、ＩＭＳへのアクセス手段を指示するトランスポート層と、
−セッション・コントローラ（Ｃａｌｌ／Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  ＦｕｎｃｔｉｏｎすなわちＣＳＣＦ）であり、とりわけ、
・プロキシ−ＣＳＣＦサーバであり、すべてのシグナリング・メッセージが該サーバを通過し、ＧＧＳＮとの間にＩＰＳｅｃトンネルを確立する、ＳＩＰプロキシの役割を果たすサーバと、
・Ｓｅｒｖｉｎｇ−ＣＳＣＦサーバであり、ＳＩＰレジストラ（ｒｅｇｉｓｔｒａｒ）の役割を果たし、シグナリング・ポリシーを確立することを可能にし、また、ルーティング機能を保証する、ドメイン管理（ａｄｍｉｎｉｓｔｒｅｒ）を可能にするサーバ（すべてのメッセージは該サーバも通過する）と、
・Ｉｎｔｅｒｒｏｇａｔｉｎｇ−ＣＳＣＦであり、他のドメインからきたＳＩＰパケットが通過し、そのアドレスがＤＮＳシステム（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）で公開されている、ドメインのエントリー・ポイントであるサーバ、
を含んだ層と、
−サービスを実行するアプリケーション・サーバ、
である。
【００７０】
図３によってシグナリング・プロトコルを用いたコール・シナリオの慣習的な展開を確認することができる。単純な通信シナリオでは、ＩＮＶＩＴＥ、ＡＣＫ、ＢＹＥといったＳＩＰリクエストが用いられる。ＳＩＰクライアントの端末（Ｔ１）はＩＮＶＩＴＥメッセージを用いてもう一つの端末（Ｔ２）にコールする。送信されたメッセージはコールする側のクライアント端末（Ｔ１）に向けてメディアのストリームを確立することを可能にする情報を含んでいる。以下の実施例はＳＩＰプロトコルにしたがった招待メッセージを示している。
ＩＮＶＩＴＥ  ｓｉｐ  ｃｈｒｉｓｔｉａｎ＠ｄｏｍａｉｎ．ｆｒ  ＳＩＰ／２．０
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ｛ｍｙ  ｐｒｉｖａｔｅ  ａｄｄｒｅｓｓ：ｐｏｒｔ｝；ｂｒａｎｃｈ＝｛ｂｒａｎｃｈ｝
Ｍａｘ＿ｆｏｒｗａｒｄｓ：７０
Ｆｒｏｍ：｛“Ｃｈｒｉｓｔｉａｎ”｝＜ｓｉｐ：｛ｃｈｒｉｓｔｉａｎ＠ｄｏｍａｉｎ．ｆｒ｝＞；
Ｔｏ：｛Ｐａｕｌ｝＜ｓｉｐ：｛ｐａｕｌ＠ｄｏｍａｉｎ．ｆｒ｝＞
Ｃａｌｌ−ＩＤ：｛２９６６３２４５５８−ｅｄｃ−６５４８−ｆｇ８ｇ９｝
ＣＳｅｑ：｛１｝ＩＮＶＩＴＥ
Ｅｘｐｉｒｅｓ：  １８００
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：｛１８７｝
【００７１】
ＳＩＰサーバ、たとえばドメイン「ｄｏｍａｉｎ．ｆｒ」のプロキシ・サーバ（３）は、一つまたは複数の応答を用いてＳＩＰリクエストに応答する。応答の大半はコードが２ｘｘ、３ｘｘ、４ｘｘ、５ｘｘおよび６ｘｘの形式をしており、「最終」応答であって、現在のトランザクションを終了させる。１ｘｘの形式をした応答は暫定応答である。応答例を以下に示す。
ＳＩＰ／２．０  １００  Ｔｒｙｉｎｇ
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ｛ｍｙ  ｐｒｉｖａｔｅ  ａｄｄｒｅｓｓ：ｐｏｒｔ｝；ｂｒａｎｃｈ＝｛ｂｒａｎｃｈ｝
Ｆｒｏｍ：｛“Ｃｈｒｉｓｔｉａｎ”｝＜ｓｉｐ：｛ｃｈｒｉｓｔｉａｎ＠ｄｏｍａｉｎ．ｆｒ｝＞；
Ｔｏ：｛Ｐａｕｌ｝＜ｓｉｐ：｛ｐａｕｌ＠ｄｏｍａｉｎ．ｆｒ｝＞
Ｃａｌｌ−ＩＤ：｛２９６６３２４５５８−ｅｄｃ−６５４８−ｆｇ８ｇ９｝
ＣＳｅｑ：｛１｝ＩＮＶＩＴＥ
【００７２】
図３の実施例において、
−応答コード「１００」は処理中「Ｔｒｙｉｎｇ」を意味し、
−応答コード「１８０」は進行中の呼び出し音「Ｒｉｎｇｉｎｇ」を意味し、
−応答コード「２００」は「ＯＫ」を意味する。
【００７３】
トランザクションとメッセージの再伝送の概念を理解するために、ここでは、ＳＩＰダイアログは「Ｆｒｏｍ」、「Ｔｏ」、Ｃａｌｌ−ＩＤおよびシーケンス番号「Ｃｓｅｑ」というフィールドの組み合わせによって識別されることを確認する必要がある。ダイアログが確立されると、すべてのリクエストおよび応答はこれらのヘッダー・フィールドを含むことになる。各トランザクションはヘッダー「Ｃｓｅｑ」の共通の値によって識別される（メソッドの名称とシーケンス番号は一致しなければならない）。本発明によるシステムは各トランザクションにおいて、関連づけられた応答を含む発信されたリクエストのタイプを分析し、トランザクションを互いに比較することを可能にする。
【００７４】
図４を参照すると、ＳＵＢＳＣＲＩＢＥおよびＮＯＴＩＦＹのような汎用的なリクエストも、マルチメディア情報の伝送過程（５５）の際に制御し、利用することができる。ＳＵＢＳＣＲＩＢＥリクエストおよびＮＯＴＩＦＹリクエストを用いることによって、マルチメディア・セッションの管理に必要な情報以外の情報を最初から最後まで配信することが可能となる。これら二つの汎用的なリクエストは、ヘッダー「Ｆｒｏｍ」および「Ｔｏ」を用いてプロキシ・サーバ（３）によってルーティングすることができ、応答によって肯定応答が返送される（ａｃｑｕｉｔｔｅｒ）。ＳＵＢＳＣＲＩＢＥリクエストは、あるイベントを受信しようとしているクライアント端末（Ｔ１）によって、イベントを生成するサーバ（３）に送信される（たとえば、友人のリスト「ｂｕｄｄｙ  ｌｉｓｔ」タイプのアプリケーションに対する存在情報要求）。ＳＵＢＳＣＲＩＢＥリクエストはヘッダーに、登録期間を示す「Ｅｘｐｉｒｅｓ」を含んでいる。ＮＯＴＩＦＹリクエストはイベント通知を送信する役割を持つ。これらＳＵＢＳＣＲＩＢＥおよびＮＯＴＩＦＹリクエストはＳＩＰダイアログを生成することができ、該リクエストはＩＮＶＩＴＥリクエストを必要とせず、非同期的にどのような瞬間にも送信することができる。
【００７５】
このように、ＳＩＰインフラ上に、質問／応答に基づく通信システムを実現することは非常に容易である。ｃａｌｌ−ＩＤフィールドの実施例では、第一端末（Ｔ１）がたとえば第二端末（Ｔ２）に、データベースを検索するための基本的なリクエストを発信しようとすれば、
−第一端末（Ｔ１）はテキスト形式で基本的なリクエストを記述し、
−次に、該端末はベース６４（ｂａｓｅ−６４）でリクエストをエンコードし、そして、
−該端末は、エンコードされたリクエストをＣＡＬＬ−ＩＤに入れてＩＮＶＩＴＥメッセージを第二端末（Ｔ２）に送信する。
【００７６】
第二端末（Ｔ２）はコード４８０（一時的に利用不可）で応答し、データベースへのリクエストの応答を理由コードのフィールドに位置づける。そこから第一端末（Ｔ１）は肯定応答ＡＣＫを同一のＣａｌｌ−ＩＤを用いて返すことで、ＳＩＰセッションの終了とリクエストに対する結果を確かに受信したことを確認するようになっている。ＳＩＰのインフラは、コールがまったく通じず、セッションが終わったと見なすことになるが、リクエストはＳＩＰのインフラを通して処理されたことになる。
【００７７】
ＣＡＬＬ−ＩＤのようなフィールドレベルに一連のリクエストを載せるためにプロトコルを複雑化することが容易であることが分かる。当業者であれば、第一のパケットを識別し、Ｎ番目のパケットおよび最後のパケットを識別するためには規則を確立するだけで十分であることが分かるだろう（ＳＩＰ  ＩＮＶＩＴＥの定義参照。ＲＦＣ  ２５４３およびＲＦＣ  ３２６１）。図３の実施例によって、ＩＮＶＩＴＥ／ＡＣＫおよびＢＹＥの使用による通信シナリオが比較的単純であることが確認できる。
【００７８】
本発明の一つの実施態様では、本方法はオープンなチャネルを精査／スキャンすることを計画している。先に挙げたほとんどの実施例ではリクエストを搬送するために単純にＣａｌｌ−ＩＤフィールドが用いられ、それはＳＩＰプロトコルのパワーによって双方向的である。しかし、Ｃａｌｌ−ＩＤの情報を最初から最後までは伝達しないＳＩＰのインフラもあり、特にＳＩＰプロキシ・サーバ（３）がこれらのデータを上書きするときには伝達しない。これはＳＩＰプロトコルのレベルでは起こりうることであり、それは、唯一の制約が、ＴＯ、ＦＲＯＭおよびＣＡＬＬ  ＩＤで構成される情報が一意のピアツーピア接続を識別しなければならないことにあるためである。
【００７９】
交換開始者として「ｆｒｏｍ」フィールドを使用することが必要となる可能性がある。容量の制限のためにＳＩＰプロキシ・サーバ（３）によって「ｆｒｏｍ」フィールドも束縛される場合には、ＴＯフィールドの使用に基づくスキーマを考えることもできる。
【００８０】
ＦＲＯＭフィールドを使用する枠組みでは、リクエストは該フィールドにエンコードされ、ｃａｌｌ−ＩＤを用いて示されるスキーマは同一のままである（付属文書１〜２参照）。ＴＯフィールドの枠組みでは、Ｂｏｂによって用いられる受信端末（Ｔ２）はＡｌｉｃｅの端末（Ｔ１）にリクエストを行うが、Ａｌｉｃｅの特定のエイリアス（ニックネーム）を標的にしており、リクエストを通すことを可能とするために、該Ａｌｉｃｅの端末に再コールするように要求する。したがってＡｌｉｃｅが再コールし、返ってきたところで、Ｂｏｂの端末（Ｔ２）は与えられたコンテキスト・フィールドの一つに入れたリクエストをトランスポートする。つまり、応答は肯定応答ＡＣＫのところに戻ることになり、このメソッドがネットワーク内で使用可能でなければ、リクエストの拒絶のところで、リクエストの識別子を仲介して、ＢｏｂがＡｌｉｃｅに再コールすることで、Ａｌｉｃｅにリクエストの識別子を伝送し、Ａｌｉｃｅが拒絶時にＢｏｂに応答をすることが適切となることもある。
【００８１】
したがって、ＳＩＰプロトコルのパワーを巧く引き出すためには複数のメソッドが可能であるが、これらのメソッドのどれを用いるのか取り決めを行い、特に、ＳＩＰネットワーク（Ｎ）で利用できるものを検出することが必要であり、それが自動的になされることが必要である。スキャン（精査）の作動原理はメソッド全体を連続的に、そのインフラでオペレーション可能なメソッドを検出するまで利用することに基づいている。
【００８２】
使用可能な並行チャネルを発見する段階では、搭載されたエージェント／クライアントはＩＮＶＩＴＥリクエストを受信者に向けて発信して使用可能なフィールドを連続的に教え、相手に到達するために使用可能な並行通信手段のマップを作成することができる。拡張することによって、エージェントはＮ個の相手またはサーバに到達するために使用可能な並行通信手段のマップを作成することができ、拡張により、受信者のグループの概念も、やはりマップ作成された並行通信手段に関連して、管理することができる。
【００８３】
並行通信手段の発見に必要なテストの記述は連続的に事前にエンコードすることができる。文法（ｇｒａｍｍａｉｒｅ）によって、アプリケーション（Ａ１、Ａ２）またはエージェントが利用し、評価できるようになるシグナリング・プロトコルのフィールドのリストを記述することができる。いったんマップが実現されると、並行チャネルのそれぞれに対して使用可能な帯域幅を、マップ作成された並行チャネルの利用可能性について反復的な一連のテストを行うことで評価することも考えられる。
【００８４】
複数のオプションが可能であり、クライアント（Ａ１、Ａ２）は第一の操作可能なメソッドにとどまる。該クライアントはすべての既知のメソッドをテストし、乱数的な基準、序数的な基準あるいは、相手と交換しようとしている情報の性質に応じて、自身の選択によってメソッドを選択する。ＳＩＰインフラがこれらのメソッドのうち複数を許可し、各メソッドを十分に詳細化されたサービスのサブ・タイプに割り当てる／特有化させることができれば、クライアント（Ａ１、Ａ２）は複数のメソッドを並行して用いる。
【００８５】
２人またはＮ人のユーザの間におけるピアツーピア・サービスの枠組みにおけるクライアント（Ａ１、Ａ２）、または、最初の場合におけるサーバ（３）とクライアント（Ａ１、Ａ２）は、分かりやすさを保つために、事前に、プロトコル規則と、交換される情報の構造に関して取り決めを行っていることが十分に理解される。結果的に得られる利点は、ＲＴＰを介したマルチメディア・データの交換を確立するために最適な仕方でＳＩＰのインフラを用いることである。ＳＩＰのインフラを利用し続け、さらに、既に確立されたＲＴＰデータの接続を別の接続を確立するために中断しようとすることなく、既に確立されたＲＴＰデータの接続を介して性質、質、さらには交換されるサービスまでを変更することに到達する。したがって、クライアントおよびサーバあるいはピアツーピアにあるユーザのクライアントが、伝送／交換の制御（モニタリング）のレベルで使用可能な帯域幅の変質を検出すれば、コンテンツの提供における質の劣化を強制することもできる。このタイプの変更は、現在では実施するのが非常に難しく、ほとんどの場合において、別のセッションを再構築するために確立済のセッションを中断することを要していた。
【００８６】
帯域幅の消費量を減らすために、受信端末（Ｔ２）はたとえば、動画の表示サイズをアイコン化または小さくし、必要な帯域幅をその分だけ減らす（したがってＴＶ／動画のストリーミングのフローを削減）ことができる。図５に示した実施例では、小さくしたウィンドウ（Ｉ）が受信したマルチメディア・コンテンツ（画像／動画）の視覚化に用いられている。このウィンドウ（Ｉ）は受信端末（Ｔ２）のディスプレイ（Ｅ）のサイズよりもかなり小さなサイズを有しており、コンテンツは低い解像度でも視覚化することができ、このことによって帯域幅を節約できるようになっている。たとえば、帯域幅の消費量は、映画の予告編の配信のいくつかの段階、たとえばクレジットタイトルのときに、故意に減少させることができる。帯域幅の消費量を自動的に調整するために、マルチメディア・コンテンツの受信における利用条件を考慮することができる。
【００８７】
本発明の利点の一つは、とりわけテレビ電話、ボイス・オーバーＩＰ、ファイル交換、メッセージングといったマルチメディア・サービスの管理において用いられる新しいプロトコルの支配が可能となることである。特に、本発明による方法によって、ボイス・オーバーＩＰのプロトコルにおける並行チャネルの使用を制御できるようになり、また、柔軟で、アクセス媒体（ベアラ）から独立したシグナリングの実施によって、消費されるサービスの質、サービスのレベルおよびサービスのタイプを変更する可能性をユーザに提供する通信チャネルをリアルタイムで実施できるようになる。さらに、サービスのアプリケーション層は、有利には、基底にあるシグナリング・サーバのフィルタリング・ポリシーや機能容量とは独立して、中央サーバとの通信手段をアプリケーションに提供するように用意することができる。
【００８８】
本発明による方法は、たとえばプッシュメールサービス、新しいメディアの消費における双方向サービス（たとえば、インタラクティブなテレビ、あるいは、コミュニティ内部におけるピアツーピア・タイプの交換）、サービスの質をリアルタイムで調整するサービスのような、複数のサービスに応用することができる。
【００８９】
当業者には、本発明が、特許請求した本発明の適用範囲を離れることなく、他の多くの特徴的な態様における実施態様を可能とするものであることは明らかである。したがって、本実施態様は例示として捉えるべきものであって、付属の特許請求の範囲に定義された範囲で変更することができ、また、本発明は上述された詳細に限定されるものではない。
【００９０】
付属文書１
ＩＮＶＩＴＥ  ｓｉｐ：ｂｏｂ＠ｆｒ．ｓｆｒ．ｃｏｍ  ＳＩＰ／２．０
Ｖｉａ：  ＳＩＰ／２．０／ＵＤＰ  １９７．１１８．０．１０：５０６０；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫ８９４３４８３０４
Ｆｒｏｍ：  ＜ｓｉｐ：ａｌｉｃｅ＠ｆｒ．ｓｆｒ．ｃｏｍ＞；ｔａｇ＝ＥＸ４ＥｖＲｄ７ＬＹ
Ｔｏ：  ＜ｓｉｐ：ｂｏｂ＠ｆｒ．ｓｆｒ．ｃｏｍ＞
Ｃｓｅｑ：  １  ＩＮＶＩＴＥ
Ｃａｌｌ−ＩＤ：  ｕｕｔｎｑ５００１ｑｗＪｉＧ＠１９７．１１８．０．１０
Ｍａｘ−Ｆｏｒｗａｒｄｓ：  ７０
ｕｓｅｒ−ａｇｅｎｔ：  Ｘ−ｌｉｔｅ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：  ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：  ３７０
ＳＩＰ／２．０  １８０  Ｒｉｎｇｉｎｇ
Ｆｒｏｍ：  ＜ｓｉｐ：ａｌｉｃｅ＠ｆｒ．ｓｆｒ．ｃｏｍ＞；ｔａｇ＝ＥＸ４ＥｖＲｄ７ＬＹ
Ｔｏ：  ＜ｓｉｐ：ｂｏｂ＠ｆｒ．ｓｆｒ．ｃｏｍ＞
Ｃｓｅｑ：  １  ＩＮＶＩＴＥ
Ｃａｌｌ−ＩＤ：  ｕｕｔｎｑ５００１ｑｗＪｉＧ＠１９７．１１８．０．１０
Ｍａｘ−Ｆｏｒｗａｒｄｓ：  ７０
ｕｓｅｒ−ａｇｅｎｔ：  Ｘ−ｌｉｔｅ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：  ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：  ３７０
ＳＩＰ／２．０  ２００  ＯＫ
Ｆｒｏｍ：  ＜ｓｉｐ：ａｌｉｃｅ＠ｆｒ．ｓｆｒ．ｃｏｍ＞；ｔａｇ＝ＥＸ４ＥｖＲｄ７ＬＹ
Ｔｏ：  ＜ｓｉｐ：ｂｏｂ＠ｆｒ．ｓｆｒ．ｃｏｍ＞
Ｃｓｅｑ：  １  ＩＮＶＩＴＥ
Ｃａｌｌ−ＩＤ：  ｕｕｔｎｑ５００１ｑｗＪｉＧ＠１９７．１１８．０．１０
Ｍａｘ−Ｆｏｒｗａｒｄｓ：  ７０
ｕｓｅｒ−ａｇｅｎｔ：  Ｘ−ｌｉｔｅ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：  ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：  ３７０
ＡＣＫ  ｓｉｐ：ｂｏｂ＠ｆｒ．ｓｆｒ．ｃｏｍ  ＳＩＰ／２．０
Ｖｉａ：  ＳＩＰ／２．０／ＵＤＰ  １９７．１１８．０．１０：５０６０；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫ８９４３４８３０４
Ｆｒｏｍ：  ＜ｓｉｐ：ａｌｉｃｅ＠ｆｒ．ｓｆｒ．ｃｏｍ＞；ｔａｇ＝ＥＸ４ＥｖＲｄ７ＬＹ
Ｔｏ：  ＜ｓｉｐ：ｂｏｂ＠ｆｒ．ｓｆｒ．ｃｏｍ＞
Ｃｓｅｑ：  １  ＩＮＶＩＴＥ
Ｃａｌｌ−ＩＤ：  ｕｕｔｎｑ５００１ｑｗＪｉＧ＠１９７．１１８．０．１０
Ｍａｘ−Ｆｏｒｗａｒｄｓ：  ７０
ｕｓｅｒ−ａｇｅｎｔ：  Ｘ−ｌｉｔｅ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：  ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：  ３７０
【００９１】
付属文書２
サーバまたは離れた加入者のエージェントに情報を伝送するため
ｃａｌｌ  ＩＤ：
ｔｏｔｏ＿０３３６０３１３１３０２０２＠ｓｆｒ．ｆｒ−
１９７．１１８．０．１０＿１２ｈ３０４７ＧＭＴ＿ＡＡｖｉｄｅｏＡＡＰＰ７＿５ＰＰ
ＩＮＶＩＴＥ  ｓｉｐ：ｂｏｂ＠ｆｒ．ｓｆｒ．ｃｏｍ  ＳＩＰ／２．０
Ｖｉａ：  ＳＩＰ／２．０／ＵＤＰ  １９７．１１８．０．１０：５０６０；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫ８９４３４８３０４
Ｆｒｏｍ：  ＜ｓｉｐ：ａｌｉｃｅ＠ｆｒ．ｓｆｒ．ｃｏｍ＞；ｔａｇ＝ＥＸ４ＥｖＲｄ７ＬＹ
Ｔｏ：  ＜ｓｉｐ：ｂｏｂ＠ｆｒ．ｓｆｒ．ｃｏｍ＞
Ｃｓｅｑ：  １  ＩＮＶＩＴＥ
Ｃａｌｌ−ＩＤ：  ｔｏｔｏ＿０３３６０３１３１３０２０２＠ｓｆｒ．ｆｒ−
１９７．１１８．０．１０＿１２ｈ３０４７ＧＭＴ＿ＡＡｖｉｄｅｏＡＡＰＰ７＿５ＰＰ
Ｍａｘ−Ｆｏｒｗａｒｄｓ：  ７０
ｕｓｅｒ−ａｇｅｎｔ：  Ｘ−ｌｉｔｅ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：  ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：  ３７０
ＣＡＬＬ−ＩＤを再コピーしながら、応答コードの記述フィールドを介して応答またはパラメータを返送するため
ＳＩＰ／２．０／  １８０  ｒｅｑｕｅｓｔ  ｖｉｄｅｏ  ７  ５  処理中
Ｆｒｏｍ：  ＜ｓｉｐ：ａｌｉｃｅ＠ｆｒ．ｓｆｒ．ｃｏｍ＞；ｔａｇ＝ＥＸ４ＥｖＲｄ７ＬＹ
Ｔｏ：  ＜ｓｉｐ：ｂｏｂ＠ｆｒ．ｓｆｒ．ｃｏｍ＞
Ｃｓｅｑ：  １  ＩＮＶＩＴＥ
Ｃａｌｌ−ＩＤ：  ｔｏｔｏ＿０３３６０３１３１３０２０２＠ｓｆｒ．ｆｒ−
１９７．１１８．０．１０＿１２ｈ３０４７ＧＭＴ＿ＡＡｖｉｄｅｏＡＡＰＰ７＿５ＰＰ
Ｍａｘ−Ｆｏｒｗａｒｄｓ：  ７０
ｕｓｅｒ−ａｇｅｎｔ：  Ｘ−ｌｉｔｅ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：  ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：  ３７０
サーバの応答
ＣＡＬＬ  ＩＤ：  ＜ｔｏｔｏ＠ＭＳＩＳＤＮ＠ｆｒｎｃｅ＠ｓｆｒ．ｎｅｔ＞＜ｍｏｄｉｆｙ  ｖｉｄｅｏ  ｑｕａｌｉｔｙ＞＜７，５＞
４００ＫＯ  ＜ｒｅｑｕｅｓｔ  ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：ｖｉｄｅｏ  ｑｕａｌｉｔｙ  ｍｏｄｉｆｉｅｄ  ｆｒｏｍ  １４  ｔｏ  ７＞
ＳＩＰ／２．０  ４００  ｒｅｑｕｅｓｔ  ｖｉｄｅｏ  ７  ５  考慮済
Ｆｒｏｍ：  ＜ｓｉｐ：ａｌｉｃｅ＠ｆｒ．ｓｆｒ．ｃｏｍ＞；ｔａｇ＝ＥＸ４ＥｖＲｄ７ＬＹ
Ｔｏ：  ＜ｓｉｐ：ｂｏｂ＠ｆｒ．ｓｆｒ．ｃｏｍ＞
Ｃｓｅｑ：  １  ＩＮＶＩＴＥ
Ｃａｌｌ−ＩＤ：  ｔｏｔｏ＿０３３６０３１３１３０２０２＠ｓｆｒ．ｆｒ−
１９７．１１８．０．１０＿１２ｈ３０４７ＧＭＴ＿ＡＡｖｉｄｅｏＡＡＰＰ７＿５ＰＰ
Ｍａｘ−Ｆｏｒｗａｒｄｓ：  ７０
ｕｓｅｒ−ａｇｅｎｔ：  Ｘ−ｌｉｔｅ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：  ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：  ３７０
【００９２】
付属文書３
新しいデータ・チャネルの確立（自由なまま残された規格のフィールドを参照）
Ｗａｒｎｉｎｇ  ｍｅｔｈｏｄ
Ｗａｒｎｉｎｇ：  ３０７  ｉｓｉ．ｅｄｕ  “Ｓｅｓｓｉｏｎ  ｐａｒａｍｅｔｅｒ  ‘ｆｏｏ’  ｎｏｔ  ｕｎｄｅｒｓｔｏｏｄ  ”
Ｗａｒｎｉｎｇ：  ３０１  ｉｓｉ．ｅｄｕ  “Ｉｎｃｏｍｐａｔｉｂｌｅ  ｎｅｔｗｏｒｋ  ａｄｄｒｅｓｓ  ｔｙｐｅ  ‘Ｅ．１６４’”
Ｒｅａｓｏｎ  ｍｅｔｈｏｄ
Ｔｈｅ  Ｒｅａｓｏｎ  ｈｅａｄｅｒ  ｆｉｅｌｄ  ＭＡＹ  ａｐｐｅａｒ  ｉｎ  ａｎｙ  ｒｅｑｕｅｓｔ  ｗｉｔｈｉｎ  ａ  ｄｉａｌｏｇ，  ｉｎ  ａｎｙ  ＣＡＮＣＥＬ  ｒｅｑｕｅｓｔ  ａｎｄ  ｉｎ  ａｎｙ  ｒｅｓｐｏｎｓｅ  ｗｈｏｓｅ  ｓｔａｔｕｓ  ｃｏｄｅ  ｅｘｐｌｉｃｉｔｌｙ  ａｌｌｏｗｓ  ｔｈｅ  ｐｒｅｓｅｎｃｅ  ｏｆ  ｔｈｉｓ  ｈｅａｄｅｒ  ｆｉｅｌｄ．  Ｔｈｅ  ｓｙｎｔａｘ  ｏｆ  ｔｈｅ  ｈｅａｄｅｒ  ｆｉｅｌｄ  ｆｏｌｌｏｗｓ  ｔｈｅ  ｓｔａｎｄａｒｄ  ＳＩＰ  ｐａｒａｍｅｔｅｒ  ｓｙｎｔａｘ．
Ｒｅａｓｏｎ    ＝  “Ｒｅａｓｏｎ”  ＨＣＯＬＯＮ  ｒｅａｓｏｎ−ｖａｌｕｅ  ＊（ＣＯＭＭＡ  ｒｅａｓｏｎ−ｖａｌｕｅ）
ｒｅａｓｏｎ−ｖａｌｕｅ    ＝  ｐｒｏｔｏｃｏｌ  ＊（ＳＥＭＩ  ｒｅａｓｏｎ−ｐａｒａｍｓ）
ｐｒｏｔｏｃｏｌ    ＝  “ＳＩＰ”  ／  “Ｑ．８５０”  ／  ｔｏｋｅｎ
ｒｅａｓｏｎ−ｐａｒａｍｓ    ＝  ｐｒｏｔｏｃｏｌ−ｃａｕｓｅ  ／  ｒｅａｓｏｎ−ｔｅｘｔ
／  ｒｅａｓｏｎ−ｅｘｔｅｎｓｉｏｎ
ｐｒｏｔｏｃｏｌ−ｃａｕｓｅ    ＝  ＜＜  ｃａｕｓｅ  ＞＞  ＥＱＵＡＬ  ｃａｕｓｅ
ｃａｕｓｅ    ＝  １＊ＤＩＧＩＴ
ｒｅａｓｏｎ−ｔｅｘｔ  ＝  “ｔｅｘｔ”  ＥＱＵＡＬ  ｑｕｏｔｅｄ−ｓｔｒｉｎｇ
ｒｅａｓｏｎ−ｅｘｔｅｎｓｉｏｎ    ＝  ｇｅｎｅｒｉｃ−ｐａｒａｍ
Ｒｅａｓｏｎ：  ＳＩＰ  ；ｃａｕｓｅ＝５８０  ；ｔｅｘｔ＝”Ｐｒｅｃｏｎｄｉｔｉｏｎ  Ｆａｉｌｕｒｅ”
【００９３】
付属文書４
ＳＤＰによるセッションの記述
ｖ＝（ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎ）
ｏ＝（ｏｗｎｅｒ／ｃｒｅａｔｏｒ  ａｎｄ  ｓｅｓｓｉｏｎ  ｉｄｅｎｔｉｆｉｅｒ）  ｕｓｅｒｎａｍｅ  ｓｅｓｓｉｏｎ  ｉｄ  ｖｅｒｓｉｏｎ  ｎｅｔｗｏｒｋ  ｔｙｐｅ  ａｄｄｒｅｓｓ  ｔｙｐｅ  ａｄｄｒｅｓｓ
ｓ＝（ｓｅｓｓｉｏｎ  ｎａｍｅ）
｛ｉ＝＊（ｓｅｓｓｉｏｎ  ｉｎｆｏｒｍａｔｉｏｎ）
ｕ＝＊（ＵＲＩ  ｏｆ  ｄｅｓｃｒｉｐｔｉｏｎ  ：  ｌｉｎｋ  ｔｏ  ｍｏｒｅ  ｉｎｆｏｒｍａｔｉｏｎ）
ｅ＝＊（ｅｍａｉｌ  ａｄｄｒｅｓｓ  ｏｆ  ｔｈｅ  ｐｅｒｓｏｎ  ｒｅｓｐｏｎｓｉｂｌｅ  ｏｆ  ｔｈｅ  ｓｅｓｓｉｏｎ  −＞
ｅ＝ｍｊｈ＠ｉｓｉ．ｅｄｕ（Ｍａｒｋ  Ｈａｎｄｌｅｙ）  ｏｒ  ｅ＝Ｍａｒｋ  Ｈａｎｄｌｅｙ  ｍｊｈ＠ｉｓｉ．ｅｄｕ）
ｐ＝＊（ｐｈｏｎｅ  ｎｕｍｂｅｒ  −＞  ｐ＝＋４４−１７１−３８０−７７７７  ｏｒ  ｐ＝＋１  ６１７  ２５３  ６０１１）
ｃ＝＊（ｃｏｎｎｅｃｔｉｏｎ  ｉｎｆｏｒｍａｔｉｏｎ  −  ｎｏｔ  ｒｅｑｕｉｒｅｄ  ｉｆ  ｉｎｃｌｕｄｅｄ  ｉｎ  ａｌｌ  ｍｅｄｉａ）  ｃ＝ｎｅｔｗｏｒｋ  ｔｙｐｅ  ａｄｄｒｅｓｓ  ｔｙｐｅ  ｃｏｎｎｅｃｔｉｏｎ  ａｄｄｒｅｓｓ／ＴＴＬ
ｂ＝＊（ｂａｎｄｗｉｄｔｈ  ｉｎｆｏｒｍａｔｉｏｎ）ｂ＝ｍｏｄｉｆｉｅｒ：ｂａｎｄｗｉｄｔｈ−ｖａｌｕｅ
一つまたはそれ以上の時間の記述（下記参照）
ｚ＝＊（ｔｉｍｅ  ｚｏｎｅ  ａｄｊｕｓｔｍｅｎｔｓ）  ｚ＝ａｄｊｕｓｔｍｅｎｔ  ｔｉｍｅ  ｏｆｆｓｅｔ  ａｄｊｕｓｔｍｅｎｔ  ｔｉｍｅ  ｏｆｆｓｅｔ  ．．．．  ｅｇ  ｚ＝２８８２８４４５２６  −１ｈ  ２８９８８４８０７０  ０
ｋ＝＊（ｅｎｃｒｙｐｔｉｏｎ  ｋｅｙ）  ｋ＝ｍｅｔｈｏｄ［：ｅｎｃｒｙｐｔｉｏｎ  ｋｅｙ］
ａ＝＊（ｚｅｒｏ  ｏｒ  ｍｏｒｅ  ｓｅｓｓｉｏｎ  ａｔｔｒｉｂｕｔｅ  ｌｉｎｅｓ）  ａ＝ａｔｔｒｉｂｕｔｅ［：ｖａｌｕｅ］｝
ゼロまたはそれ以上のメディアの記述（下記参照）
時間記述
ｔ＝（ｔｉｍｅ  ｔｈｅ  ｓｅｓｓｉｏｎ  ｉｓ  ａｃｔｉｖｅ）  ｔ＝ｓｔａｒｔ  ｔｉｍｅ  ｓｔｏｐ  ｔｉｍｅ  ｄａｔａ  ｖａｌｕｅｓ  ａｃｃｏｒｄｉｎｇ  ｔｏ  ｔｈｅ  ｆｏｒｍａｔ  ｏｆ  ＮＴＰ  ｐｒｏｔｏｃｏｌ
｛ｒ＝＊（ｚｅｒｏ  ｏｒ  ｍｏｒｅ  ｒｅｐｅａｔ  ｔｉｍｅｓ）  ｒ＝ｒｅｐｅａｔ  ｉｎｔｅｒｖａｌ  ａｃｔｉｖｅ  ｄｕｒａｔｉｏｎ  ｌｉｓｔ  ｏｆ  ｏｆｆｓｅｔｓ  ｆｒｏｍ  ｓｔａｒｔ−ｔｉｍｅ｝
メディア記述
ｍ＝（ｍｅｄｉａ  ｎａｍｅ  ａｎｄ  ｔｒａｎｓｐｏｒｔ  ａｄｄｒｅｓｓ）  ｍ＝ｍｅｄｉａ  ｐｏｒｔ［／ｎｕｍｂｅｒ  ｏｆ  ｐｏｒｔｓ］ｔｒａｎｓｐｏｒｔ  ｆｍｔ  ｌｉｓｔ（ポートは連続的）
｛ｉ＝＊（ｍｅｄｉａ  ｔｉｔｌｅ）
ｃ＝＊（ｃｏｎｎｅｃｔｉｏｎ  ｉｎｆｏｒｍａｔｉｏｎ  −  ｏｐｔｉｏｎａｌ  ｉｆ  ｉｎｃｌｕｄｅｄ  ａｔ  ｓｅｓｓｉｏｎ−ｌｅｖｅｌ）
ｂ＝＊（ｂａｎｄｗｉｄｔｈ  ｉｎｆｏｒｍａｔｉｏｎ）
ｋ＝＊（ｅｎｃｒｙｐｔｉｏｎ  ｋｅｙ）｝
”｛｝”で囲ってある属性は任意である。ＳＤＰによって記述される情報はＳＡＰ（ｓｅｒｖｉｃｅ  ａｄｖｅｒｔｉｓｉｎｇ  ｐｒｏｔｏｃｏｌ）フレームのタイプによって異なる。これら任意のフィールドには、構文的に記述されず、したがって開発されたサービスの意志にしたがって利用できるものもある。
【図面の簡単な説明】
【００９４】
【図１】本発明の一つの実施態様における方法の各過程の論理図である。
【図２】基底にあるＳＩＰネットワークとの干渉がない、端末のアプリケーションに固有のシグナリングの交換を確立する実施例を示す図である。
【図３】本発明によるシステムのインジケータを用いることで検出することができる第一のコール・シナリオを示す図である。
【図４】本発明によるシステムのインジケータを用いることで検出することができる第二のコール・シナリオを示す図である。
【図５】無線電話網の事業主のネットワークが、本発明の一つの実施態様にしたがってＳＩＰリクエストを監視し、管理するシステムを備えている、ＩＰマルチメディア・サブシステム（ＩＭＳ）のコンテキストを概略的に示す図である。
【符号の説明】
【００９５】
Ｔ１、Ｔ２、４  端末
Ａ１、Ａ２、Ａ４  アプリケーション
Ｎ  ネットワーク
２  ゲートウェイ
３  プロキシ・サーバ
１５  ＩＰドメイン
１６、１６’  無線電話網
２１、２１’  ゲートウェイ
２２、２２’  スイッチ
３１、３２  サーバ
Ｉ  ウィンドウ
Ｅ  ディスプレイ
【図１】
2008148313.tif 000005
【図２】
2008148313.tif 000006
【図３】
2008148313.tif 000007
【図４】
2008148313.tif 000008
【図５】
2008148313.tif 000009