JP2008148313A - マルチメディア情報の伝送を可能にするための通信チャネルの確立を制御する方法およびシステム - Google Patents

マルチメディア情報の伝送を可能にするための通信チャネルの確立を制御する方法およびシステム Download PDF

Info

Publication number
JP2008148313A
JP2008148313A JP2007316185A JP2007316185A JP2008148313A JP 2008148313 A JP2008148313 A JP 2008148313A JP 2007316185 A JP2007316185 A JP 2007316185A JP 2007316185 A JP2007316185 A JP 2007316185A JP 2008148313 A JP2008148313 A JP 2008148313A
Authority
JP
Japan
Prior art keywords
terminal
sip
protocol
additional information
session
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.)
Pending
Application number
JP2007316185A
Other languages
English (en)
Inventor
Christian Bouvier
ブヴィエ クリスティアン
Jean-Philippe Wary
ワリ ジャン−フィリップ
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.)
Societe Francaise du Radiotelephone SFR SA
Original Assignee
Societe Francaise du Radiotelephone SFR SA
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 Societe Francaise du Radiotelephone SFR SA filed Critical Societe Francaise du Radiotelephone SFR SA
Publication of JP2008148313A publication Critical patent/JP2008148313A/ja
Pending legal-status Critical Current

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
    • H04L65/1104—Session initiation protocol [SIP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Sub-Exchange Stations And Push- Button Telephones (AREA)

Abstract

【課題】マルチメディア・セッション管理に必要な情報以外の情報を配信する為の通信手段のインデックス化を可能とする。
【解決手段】第一端末（Ｔ１）と第二端末（Ｔ２）とが通信を確立し、該通信確立においては、第一端末（Ｔ１）が両端末間のデータ交換チャネルを選択し、セッションを開いて第一端末（Ｔ１）が第二端末（Ｔ２）にリクエスト発信し（５３）、セッションを閉じるべく第二端末（Ｔ２）が使用不可を表す応答を送信する（５４）のだが、該セッションの開始、終了は所定のシグナリング・プロトコルに従い行われる。前記リクエスト発信及び応答送信において、前記シグナリング・プロトコルに加え、マルチメディア・セッション管理に必要でないアプリケーション情報に対応する追加情報を、選択されたデータ交換チャネルにより伝送（５５）する。該データ交換チャネルはセッションの特徴を専ら記述／説明するフィールドを介してアクセス可能である。
【選択図】図１

Description

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

ＳＩＰ／２．０ １８０ Ｒｉｎｇｉｎｇ
Ｆｒｏｍ： ＜ｓｉｐ：ａｌｉｃｅ＠ｆｒ．ｓｆｒ．ｃｏｍ＞；ｔａｇ＝ＥＸ４ＥｖＲｄ７ＬＹ
Ｔｏ： ＜ｓｉｐ：ｂｏｂ＠ｆｒ．ｓｆｒ．ｃｏｍ＞
Ｃｓｅｑ： １ ＩＮＶＩＴＥ
Ｃａｌｌ−ＩＤ： ｕｕｔｎｑ５００１ｑｗＪｉＧ＠１９７．１１８．０．１０
Ｍａｘ−Ｆｏｒｗａｒｄｓ： ７０
ｕｓｅｒ−ａｇｅｎｔ： Ｘ−ｌｉｔｅ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ： ３７０

ＳＩＰ／２．０ ２００ ＯＫ
Ｆｒｏｍ： ＜ｓｉｐ：ａｌｉｃｅ＠ｆｒ．ｓｆｒ．ｃｏｍ＞；ｔａｇ＝ＥＸ４ＥｖＲｄ７ＬＹ
Ｔｏ： ＜ｓｉｐ：ｂｏｂ＠ｆｒ．ｓｆｒ．ｃｏｍ＞
Ｃｓｅｑ： １ ＩＮＶＩＴＥ
Ｃａｌｌ−ＩＤ： ｕｕｔｎｑ５００１ｑｗＪｉＧ＠１９７．１１８．０．１０
Ｍａｘ−Ｆｏｒｗａｒｄｓ： ７０
ｕｓｅｒ−ａｇｅｎｔ： Ｘ−ｌｉｔｅ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ： ３７０

ＡＣＫ ｓｉｐ：ｂｏｂ＠ｆｒ．ｓｆｒ．ｃｏｍ ＳＩＰ／２．０
Ｖｉａ： ＳＩＰ／２．０／ＵＤＰ １９７．１１８．０．１０：５０６０；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫ８９４３４８３０４
Ｆｒｏｍ： ＜ｓｉｐ：ａｌｉｃｅ＠ｆｒ．ｓｆｒ．ｃｏｍ＞；ｔａｇ＝ＥＸ４ＥｖＲｄ７ＬＹ
Ｔｏ： ＜ｓｉｐ：ｂｏｂ＠ｆｒ．ｓｆｒ．ｃｏｍ＞
Ｃｓｅｑ： １ ＩＮＶＩＴＥ
Ｃａｌｌ−ＩＤ： ｕｕｔｎｑ５００１ｑｗＪｉＧ＠１９７．１１８．０．１０
Ｍａｘ−Ｆｏｒｗａｒｄｓ： ７０
ｕｓｅｒ−ａｇｅｎｔ： Ｘ−ｌｉｔｅ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ： ３７０
付属文書２
サーバまたは離れた加入者のエージェントに情報を伝送するため

ｃａｌｌ ＩＤ：
ｔｏｔｏ＿０３３６０３１３１３０２０２＠ｓｆｒ．ｆｒ−
１９７．１１８．０．１０＿１２ｈ３０４７ＧＭＴ＿ＡＡｖｉｄｅｏＡＡＰＰ７＿５ＰＰ
ＩＮＶＩＴＥ ｓｉｐ：ｂｏｂ＠ｆｒ．ｓｆｒ．ｃｏｍ ＳＩＰ／２．０
Ｖｉａ： ＳＩＰ／２．０／ＵＤＰ １９７．１１８．０．１０：５０６０；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫ８９４３４８３０４
Ｆｒｏｍ： ＜ｓｉｐ：ａｌｉｃｅ＠ｆｒ．ｓｆｒ．ｃｏｍ＞；ｔａｇ＝ＥＸ４ＥｖＲｄ７ＬＹ
Ｔｏ： ＜ｓｉｐ：ｂｏｂ＠ｆｒ．ｓｆｒ．ｃｏｍ＞
Ｃｓｅｑ： １ ＩＮＶＩＴＥ
Ｃａｌｌ−ＩＤ： ｔｏｔｏ＿０３３６０３１３１３０２０２＠ｓｆｒ．ｆｒ−
１９７．１１８．０．１０＿１２ｈ３０４７ＧＭＴ＿ＡＡｖｉｄｅｏＡＡＰＰ７＿５ＰＰ

Ｍａｘ−Ｆｏｒｗａｒｄｓ： ７０
ｕｓｅｒ−ａｇｅｎｔ： Ｘ−ｌｉｔｅ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ： ３７０

ＣＡＬＬ−ＩＤを再コピーしながら、応答コードの記述フィールドを介して応答またはパラメータを返送するため

ＳＩＰ／２．０／ １８０ ｒｅｑｕｅｓｔ ｖｉｄｅｏ ７ ５ 処理中
Ｆｒｏｍ： ＜ｓｉｐ：ａｌｉｃｅ＠ｆｒ．ｓｆｒ．ｃｏｍ＞；ｔａｇ＝ＥＸ４ＥｖＲｄ７ＬＹ
Ｔｏ： ＜ｓｉｐ：ｂｏｂ＠ｆｒ．ｓｆｒ．ｃｏｍ＞
Ｃｓｅｑ： １ ＩＮＶＩＴＥ
Ｃａｌｌ−ＩＤ： ｔｏｔｏ＿０３３６０３１３１３０２０２＠ｓｆｒ．ｆｒ−
１９７．１１８．０．１０＿１２ｈ３０４７ＧＭＴ＿ＡＡｖｉｄｅｏＡＡＰＰ７＿５ＰＰ
Ｍａｘ−Ｆｏｒｗａｒｄｓ： ７０
ｕｓｅｒ−ａｇｅｎｔ： Ｘ−ｌｉｔｅ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ： ３７０

サーバの応答
ＣＡＬＬ ＩＤ： ＜ｔｏｔｏ＠ＭＳＩＳＤＮ＠ｆｒｎｃｅ＠ｓｆｒ．ｎｅｔ＞＜ｍｏｄｉｆｙ ｖｉｄｅｏ ｑｕａｌｉｔｙ＞＜７，５＞
４００ＫＯ ＜ｒｅｑｕｅｓｔ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：ｖｉｄｅｏ ｑｕａｌｉｔｙ ｍｏｄｉｆｉｅｄ ｆｒｏｍ １４ ｔｏ ７＞
ＳＩＰ／２．０ ４００ ｒｅｑｕｅｓｔ ｖｉｄｅｏ ７ ５ 考慮済
Ｆｒｏｍ： ＜ｓｉｐ：ａｌｉｃｅ＠ｆｒ．ｓｆｒ．ｃｏｍ＞；ｔａｇ＝ＥＸ４ＥｖＲｄ７ＬＹ
Ｔｏ： ＜ｓｉｐ：ｂｏｂ＠ｆｒ．ｓｆｒ．ｃｏｍ＞
Ｃｓｅｑ： １ ＩＮＶＩＴＥ
Ｃａｌｌ−ＩＤ： ｔｏｔｏ＿０３３６０３１３１３０２０２＠ｓｆｒ．ｆｒ−
１９７．１１８．０．１０＿１２ｈ３０４７ＧＭＴ＿ＡＡｖｉｄｅｏＡＡＰＰ７＿５ＰＰ
Ｍａｘ−Ｆｏｒｗａｒｄｓ： ７０
ｕｓｅｒ−ａｇｅｎｔ： Ｘ−ｌｉｔｅ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ： ３７０
付属文書３
新しいデータ・チャネルの確立（自由なまま残された規格のフィールドを参照）

Ｗａｒｎｉｎｇ ｍｅｔｈｏｄ
Ｗａｒｎｉｎｇ： ３０７ ｉｓｉ．ｅｄｕ “Ｓｅｓｓｉｏｎ ｐａｒａｍｅｔｅｒ ‘ｆｏｏ’ ｎｏｔ ｕｎｄｅｒｓｔｏｏｄ ”
Ｗａｒｎｉｎｇ： ３０１ ｉｓｉ．ｅｄｕ “Ｉｎｃｏｍｐａｔｉｂｌｅ ｎｅｔｗｏｒｋ ａｄｄｒｅｓｓ ｔｙｐｅ ‘Ｅ．１６４’”

Ｒｅａｓｏｎ ｍｅｔｈｏｄ
Ｔｈｅ Ｒｅａｓｏｎ ｈｅａｄｅｒ ｆｉｅｌｄ ＭＡＹ ａｐｐｅａｒ ｉｎ ａｎｙ ｒｅｑｕｅｓｔ ｗｉｔｈｉｎ ａ ｄｉａｌｏｇ， ｉｎ ａｎｙ ＣＡＮＣＥＬ ｒｅｑｕｅｓｔ ａｎｄ ｉｎ ａｎｙ ｒｅｓｐｏｎｓｅ ｗｈｏｓｅ ｓｔａｔｕｓ ｃｏｄｅ ｅｘｐｌｉｃｉｔｌｙ ａｌｌｏｗｓ ｔｈｅ ｐｒｅｓｅｎｃｅ ｏｆ ｔｈｉｓ ｈｅａｄｅｒ ｆｉｅｌｄ． Ｔｈｅ ｓｙｎｔａｘ ｏｆ ｔｈｅ ｈｅａｄｅｒ ｆｉｅｌｄ ｆｏｌｌｏｗｓ ｔｈｅ ｓｔａｎｄａｒｄ ＳＩＰ ｐａｒａｍｅｔｅｒ ｓｙｎｔａｘ．

Ｒｅａｓｏｎ ＝ “Ｒｅａｓｏｎ” ＨＣＯＬＯＮ ｒｅａｓｏｎ−ｖａｌｕｅ ＊（ＣＯＭＭＡ ｒｅａｓｏｎ−ｖａｌｕｅ）
ｒｅａｓｏｎ−ｖａｌｕｅ ＝ ｐｒｏｔｏｃｏｌ ＊（ＳＥＭＩ ｒｅａｓｏｎ−ｐａｒａｍｓ）
ｐｒｏｔｏｃｏｌ ＝ “ＳＩＰ” ／ “Ｑ．８５０” ／ ｔｏｋｅｎ
ｒｅａｓｏｎ−ｐａｒａｍｓ ＝ ｐｒｏｔｏｃｏｌ−ｃａｕｓｅ ／ ｒｅａｓｏｎ−ｔｅｘｔ
／ ｒｅａｓｏｎ−ｅｘｔｅｎｓｉｏｎ
ｐｒｏｔｏｃｏｌ−ｃａｕｓｅ ＝ ＜＜ ｃａｕｓｅ ＞＞ ＥＱＵＡＬ ｃａｕｓｅ
ｃａｕｓｅ ＝ １＊ＤＩＧＩＴ
ｒｅａｓｏｎ−ｔｅｘｔ ＝ “ｔｅｘｔ” ＥＱＵＡＬ ｑｕｏｔｅｄ−ｓｔｒｉｎｇ
ｒｅａｓｏｎ−ｅｘｔｅｎｓｉｏｎ ＝ ｇｅｎｅｒｉｃ−ｐａｒａｍ
Ｒｅａｓｏｎ： ＳＩＰ ；ｃａｕｓｅ＝５８０ ；ｔｅｘｔ＝”Ｐｒｅｃｏｎｄｉｔｉｏｎ Ｆａｉｌｕｒｅ”
付属文書４
ＳＤＰによるセッションの記述

ｖ＝（ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ）
ｏ＝（ｏｗｎｅｒ／ｃｒｅａｔｏｒ ａｎｄ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ） ｕｓｅｒｎａｍｅ ｓｅｓｓｉｏｎ ｉｄ ｖｅｒｓｉｏｎ ｎｅｔｗｏｒｋ ｔｙｐｅ ａｄｄｒｅｓｓ ｔｙｐｅ ａｄｄｒｅｓｓ
ｓ＝（ｓｅｓｓｉｏｎ ｎａｍｅ）
｛ｉ＝＊（ｓｅｓｓｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）
ｕ＝＊（ＵＲＩ ｏｆ ｄｅｓｃｒｉｐｔｉｏｎ ： ｌｉｎｋ ｔｏ ｍｏｒｅ ｉｎｆｏｒｍａｔｉｏｎ）
ｅ＝＊（ｅｍａｉｌ ａｄｄｒｅｓｓ ｏｆ ｔｈｅ ｐｅｒｓｏｎ ｒｅｓｐｏｎｓｉｂｌｅ ｏｆ ｔｈｅ ｓｅｓｓｉｏｎ −＞
ｅ＝ｍｊｈ＠ｉｓｉ．ｅｄｕ（Ｍａｒｋ Ｈａｎｄｌｅｙ） ｏｒ ｅ＝Ｍａｒｋ Ｈａｎｄｌｅｙ ｍｊｈ＠ｉｓｉ．ｅｄｕ）
ｐ＝＊（ｐｈｏｎｅ ｎｕｍｂｅｒ −＞ ｐ＝＋４４−１７１−３８０−７７７７ ｏｒ ｐ＝＋１ ６１７ ２５３ ６０１１）
ｃ＝＊（ｃｏｎｎｅｃｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ − ｎｏｔ ｒｅｑｕｉｒｅｄ ｉｆ ｉｎｃｌｕｄｅｄ ｉｎ ａｌｌ ｍｅｄｉａ） ｃ＝ｎｅｔｗｏｒｋ ｔｙｐｅ ａｄｄｒｅｓｓ ｔｙｐｅ ｃｏｎｎｅｃｔｉｏｎ ａｄｄｒｅｓｓ／ＴＴＬ
ｂ＝＊（ｂａｎｄｗｉｄｔｈ ｉｎｆｏｒｍａｔｉｏｎ）ｂ＝ｍｏｄｉｆｉｅｒ：ｂａｎｄｗｉｄｔｈ−ｖａｌｕｅ
一つまたはそれ以上の時間の記述（下記参照）
ｚ＝＊（ｔｉｍｅ ｚｏｎｅ ａｄｊｕｓｔｍｅｎｔｓ） ｚ＝ａｄｊｕｓｔｍｅｎｔ ｔｉｍｅ ｏｆｆｓｅｔ ａｄｊｕｓｔｍｅｎｔ ｔｉｍｅ ｏｆｆｓｅｔ ．．．． ｅｇ ｚ＝２８８２８４４５２６ −１ｈ ２８９８８４８０７０ ０
ｋ＝＊（ｅｎｃｒｙｐｔｉｏｎ ｋｅｙ） ｋ＝ｍｅｔｈｏｄ［：ｅｎｃｒｙｐｔｉｏｎ ｋｅｙ］
ａ＝＊（ｚｅｒｏ ｏｒ ｍｏｒｅ ｓｅｓｓｉｏｎ ａｔｔｒｉｂｕｔｅ ｌｉｎｅｓ） ａ＝ａｔｔｒｉｂｕｔｅ［：ｖａｌｕｅ］｝
ゼロまたはそれ以上のメディアの記述（下記参照）

時間記述
ｔ＝（ｔｉｍｅ ｔｈｅ ｓｅｓｓｉｏｎ ｉｓ ａｃｔｉｖｅ） ｔ＝ｓｔａｒｔ ｔｉｍｅ ｓｔｏｐ ｔｉｍｅ ｄａｔａ ｖａｌｕｅｓ ａｃｃｏｒｄｉｎｇ ｔｏ ｔｈｅ ｆｏｒｍａｔ ｏｆ ＮＴＰ ｐｒｏｔｏｃｏｌ
｛ｒ＝＊（ｚｅｒｏ ｏｒ ｍｏｒｅ ｒｅｐｅａｔ ｔｉｍｅｓ） ｒ＝ｒｅｐｅａｔ ｉｎｔｅｒｖａｌ ａｃｔｉｖｅ ｄｕｒａｔｉｏｎ ｌｉｓｔ ｏｆ ｏｆｆｓｅｔｓ ｆｒｏｍ ｓｔａｒｔ−ｔｉｍｅ｝
メディア記述
ｍ＝（ｍｅｄｉａ ｎａｍｅ ａｎｄ ｔｒａｎｓｐｏｒｔ ａｄｄｒｅｓｓ） ｍ＝ｍｅｄｉａ ｐｏｒｔ［／ｎｕｍｂｅｒ ｏｆ ｐｏｒｔｓ］ｔｒａｎｓｐｏｒｔ ｆｍｔ ｌｉｓｔ（ポートは連続的）
｛ｉ＝＊（ｍｅｄｉａ ｔｉｔｌｅ）
ｃ＝＊（ｃｏｎｎｅｃｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ − ｏｐｔｉｏｎａｌ ｉｆ ｉｎｃｌｕｄｅｄ ａｔ ｓｅｓｓｉｏｎ−ｌｅｖｅｌ）
ｂ＝＊（ｂａｎｄｗｉｄｔｈ ｉｎｆｏｒｍａｔｉｏｎ）
ｋ＝＊（ｅｎｃｒｙｐｔｉｏｎ ｋｅｙ）｝

”｛｝”で囲ってある属性は任意である。ＳＤＰによって記述される情報はＳＡＰ（ｓｅｒｖｉｃｅ ａｄｖｅｒｔｉｓｉｎｇ ｐｒｏｔｏｃｏｌ）フレームのタイプによって異なる。これら任意のフィールドには、構文的に記述されず、したがって開発されたサービスの意志にしたがって利用できるものもある。
本発明の一つの実施態様における方法の各過程の論理図である。 基底にあるＳＩＰネットワークとの干渉がない、端末のアプリケーションに固有のシグナリングの交換を確立する実施例を示す図である。 本発明によるシステムのインジケータを用いることで検出することができる第一のコール・シナリオを示す図である。 本発明によるシステムのインジケータを用いることで検出することができる第二のコール・シナリオを示す図である。 無線電話網の事業主のネットワークが、本発明の一つの実施態様にしたがってＳＩＰリクエストを監視し、管理するシステムを備えている、ＩＰマルチメディア・サブシステム（ＩＭＳ）のコンテキストを概略的に示す図である。
符号の説明
Ｔ１、Ｔ２、４ 端末
Ａ１、Ａ２、Ａ４ アプリケーション
Ｎ ネットワーク
２ ゲートウェイ
３ プロキシ・サーバ
１５ ＩＰドメイン
１６、１６’ 無線電話網
２１、２１’ ゲートウェイ
２２、２２’ スイッチ
３１、３２ サーバ
Ｉ ウィンドウ
Ｅ ディスプレイ

Claims (23)

  1. 電気通信（ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ）ネットワーク（Ｎ）によって互いに接続された少なくとも二つの通信端末（Ｔ１、Ｔ２、４）の間でマルチメディア情報の伝送をするための、交換チャネルの確立の制御方法であって、
    該方法が、第一の通信端末（Ｔ１）と第二の通信端末（Ｔ２）とが、セッションの開始を可能にする所定のシグナリング・プロトコルを管理するアプリケーションをそれぞれ用いて通信を確立する、通信確立過程（５１）を含んでおり、
    第一端末（Ｔ１）が二つの端末（Ｔ１、Ｔ２）の間における少なくとも一つのデータ交換チャネルを選択する、データ交換チャネル選択過程（５２）を実行し、
    前記データ交換チャネル選択過程（５２）はアプリケーション・レベルで行われるものであり、
    前記通信確立過程（５１）が、
    −第一端末（Ｔ１）が、所定のシグナリング・プロトコルにしたがってセッションを開くことにより、少なくとも一つのリクエストを第二端末（Ｔ２）に向けて発信する、リクエスト発信過程（５３）と、
    −第二端末（Ｔ２）が、所定のシグナリング・プロトコルにしたがってセッションを閉じるために、一時的に利用できない状態であることを表す応答を送信する、応答送信過程（５４）を含んでおり、
    前記リクエスト発信過程および前記応答送信過程（５３、５４）には、選択された前記データ交換チャネルを用いて、前記シグナリング・プロトコルに加えて追加情報を伝送する過程（５５）が含まれており、
    このデータ交換チャネルは、セッションの特徴を専ら（ｐｕｒｅｍｅｎｔ）記述する／説明するフィールドを介してアクセス可能なチャネルであり、
    前記追加情報は、マルチメディア・セッションの管理に必要ではないアプリケーション情報に対応する情報であることを特徴とする、交換チャネルの確立の制御方法。
  2. 第一端末（Ｔ１）が、前記追加情報の伝送過程（５５）に用いることのできる少なくとも一つのデータ交換チャネルを識別する、データ交換チャネル識別過程（５０）を含み、
    該識別は交換チャネルの検索過程（５００）の結果行われるものであり、
    該データ交換チャネル識別過程において、第一端末（Ｔ１）が、専ら記述的なフィールドの一つに前記シグナリング・プロトコルに加えて追加情報が与えられたリクエストに対する第二端末（Ｔ２）の少なくとも一つの応答を分析することを特徴とする、請求項１に記載の方法。
  3. 前記交換チャネルの検索過程（５００）が、第二端末（Ｔ２）が第一端末（Ｔ１）のリクエストに対する応答メッセージの全体を送信する過程（５１０）を含むことを特徴とする、請求項２に記載の方法。
  4. 選択されたデータ交換チャネルがマルチメディア情報を最初から最後まで配信するために用いられることを特徴とする、請求項１〜請求項３のいずれか一つに記載の方法。
  5. 前記データ交換チャネル選択過程（５２）において、追加情報の複数の伝送メソッドを並行して用いるために、複数のデータ交換チャネルが選択されることを特徴とする、請求項１〜請求項４のいずれか一つに記載の方法。
  6. シグナリング情報およびシグナリング・メッセージを介してアプリケーション・データを最初から最後まで伝達する能力を有した通信インフラを介して、第一端末（Ｔ１）のクライアント（Ａ１）と、サーバ（３）との間において通信手段をリアルタイムで調整（ｎｅｇｏｃｉａｔｉｏｎ）する過程をさらに含むことを特徴とする、請求項１〜請求項５のいずれか一つに記載の方法。
  7. ＳＩＰプロトコルに加えて追加情報を伝送する過程（５５）のために、
    −セッションの特徴が述べられたＳＩＰパケットのヘッダー、
    −応答コードの記述、
    −Ｃａｌｌ＿ＩＤ、
    −Ｂｒａｎｃｈ、
    −ＴＡＧ、
    というフィールドの少なくとも一つが用いられることを特徴とする、請求項１〜請求項６のいずれか一つに記載の方法。
  8. ＳＩＰプロトコルのＭＥＳＳＡＧＥメソッドに関連づけられた少なくとも一つのフィールドが、ＳＩＰプロトコルに加えて追加情報を伝送する過程（５５）のために用いられることを特徴とする、請求項１〜請求項７のいずれか一つに記載の方法。
  9. ＳＩＰの有効な記載（ｃｈａｒｇｅ ｕｔｉｌｅ）であるＳＤＰ情報に関連づけられた少なくとも一つのフィールドが、ＳＩＰプロトコルに加えて追加情報を伝送する過程（５５）のために用いられ、ＳＩＰの有効な記載におけるこのＳＤＰフィールドがＳＩＰプロトコルによってオプション的に定義され、あるいは、ＳＩＰプロトコルによって固定されていない構造および構文を有していることを特徴とする、請求項１〜請求項８のいずれか一つに記載の方法。
  10. ＳＩＰプロトコルのＣａｌｌ＿ＩＤフィールドがＳＩＰプロトコルに加えて追加情報を伝送する過程（５５）のために用いられることを特徴とする、請求項１〜請求項９のいずれか一つに記載の方法。
  11. 前記の追加情報を伝送する過程（５５）の際に伝送されるマルチメディア・コンテンツの消費／使用条件が、ＳＩＰプロトコルを介して搬送される追加情報の受信において、およびそれらの追加情報を考慮して、マルチメディア・コンテンツを消費するマルチメディア・アプリケーションによって変更されることを特徴とする、請求項１〜請求項１０のいずれか一つに記載の方法。
  12. 前記の追加情報を伝送する過程（５５）の際に伝送されるマルチメディア・コンテンツの前記消費／使用条件が、第二端末（Ｔ２）が使用可能なトランスポートネットワークの環境の変化に応じて変更されることを特徴とする、請求項１〜請求項１１のいずれか一つに記載の方法。
  13. 前記の追加情報を伝送する過程（５５）の際に伝送されるマルチメディア・コンテンツの前記消費／使用条件が、第二端末（Ｔ２）の地理的位置の条件の変化に応じて変更されることを特徴とする、請求項１〜請求項１２のいずれか一つに記載の方法。
  14. 前記の追加情報を伝送する過程（５５）の際に伝送されるマルチメディア・コンテンツの前記消費／使用条件が、第二端末（Ｔ２）に内在的な作動条件の変化に応じて変更されることを特徴とする、請求項１〜請求項１３のいずれか一つに記載の方法。
  15. 前記の追加情報を伝送する過程（５５）の際に伝送されるマルチメディア・コンテンツの前記消費／使用条件が、第二端末（Ｔ２）によって受信されるサービスの提供条件の変化に応じて変更されることを特徴とする、請求項１〜請求項１４のいずれか一つに記載の方法。
  16. 二つの通信端末（１，２）の間で確立された伝送ストリームの消費／使用条件が、ＳＩＰプロトコルを介して搬送される追加情報の送信、受信において、およびそれらの追加情報を考慮して、各端末のマルチメディア・コンテンツを消費および送信するマルチメディア・アプリケーションによって変更されることを特徴とする、請求項１〜請求項１５のいずれか一つに記載の方法。
  17. 識別されたセッション外で交換チャネルの少なくとも一つに使用可能な帯域幅を評価する過程を含むことを特徴とする、請求項１〜請求項１６のいずれか一つに記載の方法。
  18. 第二端末（Ｔ２）のレベルで使用条件が変更されたときにサービスをリアルタイムで再調整する過程であって、ディスプレイで視覚化される動画ウィンドウのサイズを変更することで帯域幅の消費を減少させるために実現される再調整過程を含むことを特徴とする、請求項１〜請求項１７のいずれか一つに記載の方法。
  19. マルチメディア情報を伝送するためにセッション外で利用することのできる、識別された交換チャネルのリストを、二つの端末（Ｔ１、Ｔ２）のそれぞれのメモリに記憶する過程を含むことを特徴とする、請求項１〜請求項１８のいずれか一つに記載の方法。
  20. シグナリング・プロトコルはＳＩＰプロトコルであり、前記プロトコルに加えて追加情報を伝送する過程（５５）が、
    −第一端末（Ｔ１）がリクエストをテキスト・フォーマットで記述する過程と、
    −該リクエストをエンコードする過程と、
    −エンコードされたリクエストをＣａｌｌ−ＩＤフィールドに渡してＩＮＶＩＴＥメッセージを送信する過程を含んでいることを特徴とする、
    請求項１〜請求項１９のいずれか一つに記載の方法。
  21. 前記プロトコルに加えて追加情報を伝送する過程（５５）がさらに、
    −一時的に利用できない状態であることを表す表示を含み、リクエストに対する応答が第二端末（Ｔ２）によって専ら記述的または説明的なフィールドに位置づけられている応答メッセージを送信する過程と、
    −ＳＩＰセッションの終了を確認する過程であり、第一端末（Ｔ１）が第二端末（Ｔ２）に同一のＣａｌｌ−ＩＤフィールドを用いて肯定応答メッセージＡＣＫを送信することで、リクエストに対する応答を確実に受信したことを示す過程を含んでいることを特徴とする、
    請求項２０に記載の方法。
  22. 専ら記述的または説明的な前記フィールドが「Ｒｅａｓｏｎ」フィールドであることを特徴とする、請求項２１に記載の方法。
  23. ネットワーク（Ｎ）との通信端末（Ｔ１、Ｔ２、４）のメモリに直接搭載することのできる処理モジュールのプログラムであり、前記プログラムが端末（Ｔ１、Ｔ２、４）上で実行されたときに請求項１から請求項５のいずれか一つに記載の方法における各過程を命令（ｃｏｍｍａｎｄｅｒ）するようになっていることを特徴とするプログラム。
JP2007316185A 2006-12-06 2007-12-06 マルチメディア情報の伝送を可能にするための通信チャネルの確立を制御する方法およびシステム Pending JP2008148313A (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0610629A FR2909822B1 (fr) 2006-12-06 2006-12-06 Procede et systeme de controle de l'etablissement de canaux de communication pour permettre une transmission d'informations multimedia.

Publications (1)

Publication Number Publication Date
JP2008148313A true JP2008148313A (ja) 2008-06-26

Family

ID=38202529

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007316185A Pending JP2008148313A (ja) 2006-12-06 2007-12-06 マルチメディア情報の伝送を可能にするための通信チャネルの確立を制御する方法およびシステム

Country Status (9)

Country Link
US (1) US7953123B2 (ja)
EP (1) EP1931104B1 (ja)
JP (1) JP2008148313A (ja)
AT (1) ATE434331T1 (ja)
DE (1) DE602007001332D1 (ja)
DK (1) DK1931104T3 (ja)
ES (1) ES2327969T3 (ja)
FR (1) FR2909822B1 (ja)
PT (1) PT1931104E (ja)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100205628A1 (en) 2009-02-12 2010-08-12 Davis Bruce L Media processing methods and arrangements
CN102064994B (zh) * 2009-11-18 2013-12-18 中兴通讯股份有限公司 基于媒体网关控制协议识别网络电话流量的方法和装置
FR2995164A1 (fr) * 2012-08-29 2014-03-07 France Telecom Procedes, dispositifs et systeme de journalisation d'appels pour terminaux
US9106673B2 (en) 2012-12-28 2015-08-11 Vonage Network, Llc Systems and methods for connecting telephony communications
US20150111557A1 (en) * 2013-10-23 2015-04-23 Acer Incorporated Method of managing contact information for mobile devices according to network messages
WO2015180130A1 (zh) * 2014-05-30 2015-12-03 华为技术有限公司 报文编辑处理方法和相关设备
US20170244992A1 (en) * 2014-10-30 2017-08-24 Sharp Kabushiki Kaisha Media playback communication
CN115695382A (zh) * 2021-07-31 2023-02-03 华为技术有限公司 一种通信方法及装置
CN116155868A (zh) * 2021-11-19 2023-05-23 中兴通讯股份有限公司 电信通讯方法、电子设备及存储介质
US11775245B1 (en) * 2022-05-09 2023-10-03 International Business Machines Corporation Consistent representative screen sharing

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6738349B1 (en) * 2000-03-01 2004-05-18 Tektronix, Inc. Non-intrusive measurement of end-to-end network properties
US7024461B1 (en) * 2000-04-28 2006-04-04 Nortel Networks Limited Session initiation protocol enabled set-top device
EP1248431B1 (en) * 2001-03-27 2007-10-31 Sony Deutschland GmbH Method for achieving end-to-end quality of service negotiation for distributed multimedia applications
US8126127B2 (en) * 2002-01-16 2012-02-28 Qualcomm Incorporated Method and apparatus for provision of broadcast service information
EP1331785B1 (en) * 2002-01-23 2005-04-20 Sony International (Europe) GmbH A method for enabling the negotiation of end-to-end QoS by using the end-to-end negotiation protocol (E2ENP)
US20050071459A1 (en) * 2003-09-26 2005-03-31 Jose Costa-Requena System, apparatus, and method for providing media session descriptors
US8396973B2 (en) * 2004-10-22 2013-03-12 Microsoft Corporation Distributed speech service
FI20041634A0 (fi) * 2004-12-20 2004-12-20 Nokia Corp Tarjontaistunnon muodostaminen kommunikaatiojärjestelmässä
DE202005021930U1 (de) * 2005-08-01 2011-08-08 Corning Cable Systems Llc Faseroptische Auskoppelkabel und vorverbundene Baugruppen mit Toning-Teilen
US20080089324A1 (en) * 2006-10-13 2008-04-17 Cisco Technology, Inc Indicating or remarking of a dscp for rtp of a flow (call) to and from a server

Also Published As

Publication number Publication date
DK1931104T3 (da) 2009-10-19
ATE434331T1 (de) 2009-07-15
US20080137598A1 (en) 2008-06-12
ES2327969T3 (es) 2009-11-05
EP1931104B1 (fr) 2009-06-17
FR2909822B1 (fr) 2010-04-30
DE602007001332D1 (de) 2009-07-30
PT1931104E (pt) 2009-08-14
EP1931104A1 (fr) 2008-06-11
FR2909822A1 (fr) 2008-06-13
US7953123B2 (en) 2011-05-31

Similar Documents

Publication Publication Date Title
JP5363461B2 (ja) グループ呼機能の問い合わせ
KR100802641B1 (ko) 패킷 교환 방식 네트워크 시그날링을 통해 회선 교환 방식통신을 설정하는 시스템, 장치, 및 방법
US7953123B2 (en) Method and system for controlling the establishment of communications channels for allowing transmission of multimedia information
CN102497621B (zh) 开启ad-hoc无线即按即说会话的方法、用户设备和服务器
US20090168758A1 (en) Methods for facilitating communication between internet protocol multimedia subsystem (ims) devices and non-ims devices and between ims devices on different ims networks and related electronic devices and computer program products
CA2605475C (en) Session initiation from application servers in an ip multimedia subsystem
WO2006064347A1 (en) Method and system to the instant transfer of multimedia files between mobile radio users within the scope of combinational services
CN105245493A (zh) 通信网络中的能力查询处理
US20090207789A1 (en) Shared ip multimedia resource reservation
KR20090074932A (ko) 무선 네트워크와 유선 네트워크의 연동을 위한 장치 및방법
US10771510B2 (en) IMS application control protocol
US10313400B2 (en) Method of selecting a network resource
JP6566522B2 (ja) 要求元端末のオプション機能の非使用を整合する網間制御方法、ｓｉｐサーバ及びプログラム
Nurmela Session initiation protocol
RU2417544C2 (ru) Способы и устройства для передачи информации о состоянии сигнального соединения, относящейся к сигнальному соединению между терминалом и модулем посреднической функции управления сеансом/вызовом (p-cscf) в мультимедийной подсистеме интернет-протокола (ims)
CN103828320A (zh) 抑制用于转移用户的camel服务调用
KR20080063926A (ko) 통신 네트워크에서 멀티미디어 회의 서비스를 제공하는방법 및 시스템

Legal Events

Date Code Title Description
RD01 Notification of change of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7426

Effective date: 20080401

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20080401