JP2008148310A - マルチメディアセッション管理方法およびシステム - Google Patents

Abstract

【課題】電気通信ネットワークにより接続された通信端末間で、所定のシグナリング・プロトコルに従って行われるマルチメディアセッションにおいて、シグナリング・プロトコルの不正使用を発見し、防止する。
【解決手段】シグナリング・プロトコルの不正使用を表わす異常の調査（５０）、及び、調査された異常に応じたリアクションの定義づけ（５００）を予め行っておいた上で、端末（Ｔ１、Ｔ２、４）およびプロキシサーバ（３）の間で交換されるリクエスト全体を収集（５１）し、複数のインジケータの各々に予め調査されている異常のうちの一つが結びつけられたものを利用して、異常を検出すべく、収集されたリクエストを分析する（５２）。分析の結果、異常を検出したら、検出された異常に対応するリアクションをプロキシサーバ（３）によって開始する。このリアクションには該異常を有するメッセージに関する通信への、リアルタイムでの介入が含まれる。
【選択図】図１

Description

本発明は、電気通信（ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ）に関するものであり、より特徴的には、事業者（ｏｐｅｒａｔｅｕｒ）によって管理されるネットワーク内での通信チャネルの確立を制御することを目的とした、マルチメディアセッションの管理方法に関するものである。

ボイス・オーバーＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）の技術すなわちＶｏＩＰと、そしてさらに一般的には、マルチメディアセッションの確立を可能にする技術は、相互運用可能なオープンスタンダードであるＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を利用することが最も多い。マルチメディアセッションのためには、例えばＨ３２３、ＭＧＣＰ（Ｍｅｄｉａ Ｇａｔｅｗａｙ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）およびＭｅｇａｃｏ（この後者のプロトコルはＭｅｄｉａ Ｇａｔｅｗａｙｓというゲートウェイを制御するために３ＧＰＰによってＵＭＴＳ規格で採用されている）といったその他のシグナリング・プロトコルを利用することができる。

ＳＩＰプロトコルは、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）により規格化され、特にＲＦＣ ３２６１に記載されている。ＳＩＰプロトコルは、マルチメディア・セッションを確立（ｅｔａｂｌｉｒ）、変更（ｍｏｄｉｆｉｅｒ）および終了（ｔｅｒｍｉｎｅｒ）するために設計された（例えばＲＦＣ ２５４３を参照のこと）。これは、多数の参加者の認証（ａｕｔｈｅｎｔｉｆｉｃａｔｉｏｎ）とローカライゼーション（ｌｏｃａｌｉｓａｔｉｏｎ）を担当する。同様に、該プロトコルは、ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）メッセージをカプセル化（ｅｎｃａｐｓｕｌｅｒ）し、さまざまな参加者によって利用可能なメディア・タイプについての調整（ｎｅｇｏｃｉａｔｉｏｎ）も担当する。ＳＩＰプロトコルはセッションの間、音声や動画といった交換されるデータはトランスポート（ｔｒａｎｓｐｏｒｔｅｒ）しない。このプロトコルはデータの伝送から独立しているため、あらゆるタイプのデータおよびプロトコルをこの交換のために用いることができる。すなわち、音声セッションおよび動画セッションを保証するのはほとんどの場合においてＲＴＰプロトコル（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）である。ＳＩＰプロトコルの利点は、ボイス・オーバーＩＰだけではなく、テレビ電話、インスタント・メッセージ、バーチャル・リアリティまたはテレビ・ゲームといった他の多くの応用も対象としていることである。

このタイプの技術に関連する一つの問題点はＶｏＩＰプロトコルおよびそれに付随するサービスが安全性について一切考慮することなく定義されているという点にある。特に、ＳＩＰの場合、サービスの拒否を行なうこと、通信を流用すること、通信を盗聴すること、無料で電話をすること、コールログを取ること、隠れチャネル（ｃｏｖｅｒｔ ｃｈａｎｎｅｌ、ｃａｎａｌ ｃａｃｈｅ）を開設することなどが可能である。同様に、被害者のＶｏＩＰ電話機になりすまして自らを呼出させることさえ可能である。

ＶｏＩＰシステムは、クライアントによる規格の遵守に基づいている。したがって、多数の攻撃を行う可能性を入手するためには、独自のＶｏＩＰクライアントを開発するだけでよい。ＶｏＩＰ技術は、安全性を考慮に入れることなく、通信経路選択、複数人数での会話などといった多機能性を重視して緊急に開発された。その結果、ＶｏＩＰは、企業における業務用途向けにはまだ整備不十分な状態にある。

例えば無線電話ネットワークにおいては、マルチメディアセッションのためのかかるプロトコル（ＳＩＰ／Ｈ３２３／ＭＧＣＰ）の利用は、事業者による検出が不可能な情報交換を可能にし得る。それは、通信制御上の問題をひき起こし（テロまたは大型犯罪のための裏通信手段）、事業者がこれらの通信に課金することは不可能である。既存の規格は、いくつかのフィールドの使用もシンタックスも固定させることがないため、かくして、マルチメディアセッションのマネジメントに必要なもの以外の情報を流すために並行（ｐａｒａｌｌｅｌｅ）な複数のチャネルを利用することが可能になる。すなわち、ウイルス、トロイの木馬が伝送され得、または事業者が検出できない状態で加入者の知らないうちに機密扱いのデータが回収され得る。したがって事業者は、例えば行政的または司法的枠内で国家の要請に基づき通知しなくてはならない通信全体に関する自らの法律上および規則上の義務を果たすことさえできない。

利用された隠れチャネルがＶｏＩＰシステムのシグナリングによりトランスポートされていることから、事業者は隠れチャネルに課金することができず、法律上または規則上の義務を果たすことができない。

ネットワーク事業者のＳＩＰまたはＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）インフラストラクチャ上、ならびにＩＰ上のテレフォニーインフラストラクチャ上の不正行為に直面しながらも、これらのインフラストラクチャの不正な使用を回避するための満足のいく解決法は存在しない。

欧州特許第１５３３９７７号明細書により、ＳＩＰプロトコルを用いたデバイスに対するサービス拒否攻撃の検出方式が知られている。ただしこのタイプの、ＳＩＰネットワークインフラストラクチャの保護方式は、ＶｏＩＰプロトコルにおける並行チャネルを介した交換を制御するためには適していない。同様に、特開２００５−２１５９３５号公報により、メッセージのＳＤＰ記述の中身を分析することによって一つの通信を許可または拒絶するための「Ｆｉｒｅｗａｌｌ」ファイアウォールインタフェースデバイスを提供することも知られている。このタイプのインタフェースデバイスは、事業者がこのタイプの通信を管理できるようにする並行チャネルを介した交換の制御を可能にしない。

したがって、以下の安全性の諸問題をもつグループに適用可能な解決法に対するニーズが存在する：
−先験的に全てのＳＩＰメッセージ上で可能である、「ｆｒｏｍ」フィールドの変更によるアイデンティティのスプーフィング；
−情報交換のための隠れチャネルの利用、または、一人のユーザーにあるサービスまたはある別のユーザーへの接続を強制することによる情報奪取（バウンス攻撃（Ｂｏｕｎｃｅ ａｔｔａｃｋ））。
欧州特許第１５３３９７７号明細書 特開２００５−２１５９３５号公報

したがって本発明の目的は、（例えば無線電話などの）ネットワーク事業者が、自らのクライアントまたは自らの収入を保護するべくＳＩＰプロトコルの隠れチャネル（ｃｏｖｅｒｔ ｃｈａｎｎｅｌ、ｃａｎａｌ ｃａｃｈｅ）の悪用を発見することを可能にするマルチメディアセッション管理方法を定義することによって、先行技術の欠点のうちの一つまたは複数を除去することにある。

本発明は、有利にも、マルチメディアセッション内でクライアントとサーバの間を切る状態で（ｅｎ ｃｏｕｐｕｒｅ）位置する中間デバイスの利用を目的とするものである。このデバイスは、本書の以下の部分では「プロキシ」サーバと呼ばれる。

このために、本発明は、電気通信ネットワークにより連結された通信端末の間で、所定のシグナリング・プロトコルに従って実現されるマルチメディアセッションの管理方法に関するものであって、該方法は、シグナリング・プロトコルの不正使用を表わす異常の調査段階、および調査された異常に応じたリアクション（ｒｅａｃｔｉｏｎ）の定義づけ（ｄｅｆｉｎｉｒ）段階を予め含むことを特徴とし、
−クライアント端末およびプロキシサーバの間で交換されるリクエスト全体を収集する段階、
−複数のインジケータ（ｉｎｄｉｃａｔｅｕｒ）の各々に予め調査された異常のうちの一つが結びつけられたものを利用して、異常を検出するために、収集されたリクエストを分析する段階、
をさらに含む、マルチメディアセッションの管理方法に関するものである。

かくして、ネットワーク事業者は自身のクライアントによる通信チャネルの利用をより良く制御することができる。シグナリング・プロトコルの流用が通知されることが可能となるため、事業者は法律上または規則上の義務を果たすことができる。

もう一つの特徴によると、本方法は、少なくとも一つの異常を検出した場合に、検出された異常に対応する一つのリアクションをプロキシサーバによって開始する段階を含み、前記リアクションには該異常を有するメッセージに関する通信の間へのリアルタイムでの介入が含まれる。

もう一つの特徴によると、本方法は、端末間で隠れた情報（ｃｏｖｅｒｔ ｉｎｆｏｒｍａｔｉｏｎ、ｉｎｆｏｒｍａｔｉｏｎ ｃａｃｈｅｅ）が伝播されない保証を得るために、宛先端末に向かってメッセージを転送する前に、プロキシサーバが各リクエスト内に識別データを代入する段階を含む。

もう一つの特徴によると、収集されたリクエストの分析段階は、リクエストのＳＩＰパケットのヘッダーに関係する異常インジケータを利用する。

もう一つの特徴によると、収集されたリクエストの分析段階は、各リクエストの発呼者の識別フィールド「Ｃａｌｌ ＩＤ」に関係する異常インジケータを利用する。

もう一つの特徴によると、収集されたリクエストの分析段階は、取得／通知「ＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹ」メソッドに関係する異常インジケータを利用する。

もう一つの特徴によると、収集されたリクエストの分析段階は、隠れチャネルの活用を可能にするＳＩＰプロトコルの中で利用されるメソッドの一つに関係する異常インジケータを利用する。

もう一つの特徴によると、収集されたリクエストの分析段階は、応答コードの記述子（ｄｅｓｃｒｉｐｔｉｆ）に関係する異常インジケータを利用する。

もう一つの特徴によると、収集されたリクエストの分析段階は、ＳＩＰリクエストのペイロード（ｃｈａｒｇｅ ｕｔｉｌｅ）中のＳＤＰフィールドに関係する異常インジケータを利用する。

もう一つの特徴によると、収集されたリクエストの分析段階は、各々のＳＩＰリクエストの標識つまりＴＡＧに関係する異常インジケータを利用する。

かくして、本発明よる方法は、ＳＩＰといったようなシグナリング・プロトコルにおいて利用される隠れチャネルのリアルタイムでの検出およびフィルタリングを確実に行う。

もう一つの特徴によると、前記リアクションは、検出された異常に応じた課金（ｆａｃｔｕｒａｔｉｏｎ）段階を含み、該段階において、課金に必要となる、（かつ事業者の法律上の義務を遵守する）情報が課金サーバと呼ばれる専用サーバに向かって伝送される。

このリアクションはユーザーに隠れチャネル利用の余地を残す。

もう一つの特徴によると、前記リアクションには、ネットワークのＩＰの部分の監視センタに少なくとも一つの異常をリアルタイムで通知するための警告メッセージの伝送が含まれる。

もう一つの特徴によると、本方法は、プロキシサーバに結びつけられた変換モジュールによって、同じＳＩＰリクエストについて、一対のフィールドを管理する段階を含んでおり、該段階において第二のフィールドが第一のフィールドをもとに書換えられる。

もう一つの特徴によると、本方法は、前記リアクションの際にＳＩＰセッションの切断段階を含む。

かくして、特にＶｏＩＰサービスのために利用されるシグナリング・プロトコルのフィールド内に「隠されて（ｃｏｖｅｒｔ、ｃａｃｈｅ）」挿入された情報の伝播を妨げることが可能となる。

本発明のもう一つの目的は、通信ネットワークのリソース利用の制御と共にマルチメディアセッションの管理を可能にするシステムを定義することによって、先行技術において遭遇した問題のうちの一つまたは複数に対する解決法をもたらすことにある。

このために、本発明は、少なくとも一つのクライアント端末とＳＩＰプロキシサーバの間のＳＩＰタイプのネットワーク内で利用されることを目的とするマルチメディアセッションの管理システムにおいて、
−シグナリング・プロトコルの不正使用を表わす異常インジケータを記憶するための記憶手段、
−クライアント端末の各々とＳＩＰプロキシサーバの間で交換されるＳＩＰリクエスト全体を収集するためのＳＩＰリクエスト分析ファンクションを備えた、前記インジケータに結合された異常調査モジュール、
−調査された異常に応じて一つのアクション（ａｃｔｉｏｎ）を指令するように各々プログラミングされたリアクションモジュールであって、各々のリアクションモジュールはプロキシサーバによりアクティベート（ａｃｔｉｖｅｒ）され、該異常を有するメッセージに関する通信の間にリアルタイムで一つの介入を開始するリアクションモジュール、
を含むことを特徴とする管理システムに関するものである。

かくして、このようなシステムを用いると、いかなるＳＩＰリクエストも「隠れた（ｃｏｖｅｒｔ、ｃａｃｈｅ）」通信チャネルを網羅していないという保証を得ることができる（例えば一部のプロセスの尋常でない反復または一部のフィールドの異常なサイズなどに関するインジケータにより、実際、シグナリング・プロトコルの流用を見つけ出すことができる）。

もう一つの特徴に従うと、同じＳＩＰリクエストについて二つの異なるフィールドを管理するためにプロキシサーバに変換モジュールが具備されており、該変換モジュールの書換え手段によって、第二のフィールドが第一のフィールドをもとに書換えられる。

かくして、該書換え作業により、シグナリング・プロトコルのフィールドの流用は不可能になる。すなわち、したがって補足的情報をこのフィールドを介して伝播させることはできない。

本発明の補足的目的は、ＳＩＰプロトコルの隠れチャネルの悪用に対抗できるネットワークを提案することにある。

このために、本発明は、本発明によるマルチメディアセッションの管理システムを備えることを特徴とする、複数のネットワークエレメントを含む、ＳＩＰプロトコルを用いるネットワークに関するものである。

本発明、その特徴および利点は、非制限的に例示されている添付図面を参照しながら該記述を読むことによりさらに明確になるものである。
図１は、本発明の一実施形態における、本方法の段階の論理図である。
図２は、本発明に従ったマルチメディアセッションの管理を可能にするネットワークを示す図である。
図３は、本発明に従ったシステムのインジケータの利用によって検出可能な第一のコールシナリオを図示している。
図４は、本発明に従ったシステムのインジケータの利用によって検出可能な第二のコールシナリオを図示している。
図５は、無線電話事業者ネットワークが、本発明の一実施形態に従ったＳＩＰリクエストを監視および管理するシステムを備える、ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ（ＩＭＳ）コンテキストを概略的に表わしている。

ＳＩＰプロトコルは、マルチメディアセッションを確立し、変更し、または終了するように設計されている。該プロトコルは、ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）メッセージをカプセル化することによって、さまざまな参加者によって利用可能なメディアタイプについての調整を担当している。逆にＳＩＰプロトコルは、セッションの間に、音声または動画といったような交換データをトランスポートしないことになっている。

本発明によるマルチメディアセッションの管理方法は、ＳＩＰといったようなシグナリング・プロトコルの脆弱性全体を扱うことを目的としている。本発明は、（隠れチャネルを介して）隠れ情報を伝送するためにシグナリング・メッセージを利用する可能性を制限し、ひいてはこれをなくするように、検出、フィルタリングおよびリアクションという機能性を想定している。ＳＩＰプロトコルのための非制限的な一例として、隠れチャネルの使用を以下のように列挙することができる。すなわち、
・ＭＥＳＳＡＧＥメソッド、
・ＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹメソッド、
・ＳＩＰパケットのヘッダー（セッションの特徴（ｃａｒａｃｔｅｒｉｓｔｉｑｕｅ））、
・応答コードの記述子（ｒｅｑ ２００ ＯＫ）、
・ペイロードフィールド ＳＤＰ、
・Ｃａｌｌｅｒ ＩＤ（＠＜ＣＳｅｑ＞！！！）、
・ＴＡＧ、
である。

図２を参照すると、ＳＩＰネットワーク（Ｎ）は、ルーティングオプションのトポロジー（点線）を利用できるようにするＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）プロトコルの第一のドメイン（１５）、および無線電話ネットワーク（１６）に対応する第二のドメインを含む。ＲＴＣ（Ｒｅｓｅａｕ Ｔｅｌｅｐｈｏｎｉｑｕｅ Ｃｏｍｍｕｔｅ）タイプのドメインも同様にＳＩＰネットワーク（Ｎ）の一部を成すことができる。好ましい一実施態様においては、図１で示されているＳＩＰネットワーク（Ｎ）は、ＶｏＩＰ技術を展開できるようにするＩＭＳサブシステム（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）を伴うサービスアーキテクチャを利用する。ＳＩＰネットワーク（Ｎ）は、ステーションを備えた無線電話ネットワーク（１６）、および、有線接続を有する一部分を含むものとして表わされているものの、ネットワーク（Ｎ）内ではいかなる無線接続でも利用可能であり、このネットワークは無線接続（無線、ＷｉＦｉ、Ｗｉｍａｘ、Ｂｌｕｅｔｏｏｔｈ（登録商標）など）のみを利用する可能性さえある、ということが理解される。

図２の実施例においては、ＩＰドメイン（１５）は、複数のネットワークエレメント、特にメディアゲートウェイ（２）（ｍｅｄｉａ ｇａｔｅｗａｙ）、プロキシサーバ（３）ならびに第一および第二のユーザー端末（Ｔ１、Ｔ２）を備えている。各々の端末（Ｔ１、Ｔ２）は、無線電話ネットワーク（１６）を介して接続された例えば携帯端末といった無線通信端末（４）との通信の確立の際に、ルーティングオプションのトポロジーの一部分を利用することができる。この場合、プロキシサーバ（３）およびゲートウェイ（２）が利用される。第一および第二の端末は同様に、ＳＩＰプロキシサーバ（３）を利用して互いの間で通信することもでき、この場合はゲートウェイを利用しない。

本発明の一実施態様においては、ＳＩＰプロキシサーバ（３）および／またはゲートウェイ（２）の中に、ＳＩＰリクエストの収集および分析ファンクションが実装される。かかるファンクションは、場合によって、一部の需要のためには、ユーザー端末（Ｔ１、Ｔ２）のうちの少なくとも一つの中に実装可能である。分析ファンクションは有利にも、「隠れ」チャネルの不正使用を表わす異常を検出するために、ＳＩＰリクエストのフィルタリングを行うことを可能にする。

ＳＩＰネットワーク（Ｎ）は、ＳＩＰリクエスト分析ファンクションを備えた異常調査モジュール（３０）を有することができる。この異常調査モジュール（３０）は、各々のクライアント端末（Ｔ１、Ｔ２、４）とＳＩＰプロキシサーバ（３）の間で交換されるＳＩＰリクエスト全体を収集することを可能にする。該モジュールは同様に、別のＩＰネットワークからクライアント端末（Ｔ１、Ｔ２、４）に向かってゲートウェイ（２）を介して伝送されたＳＩＰリクエストを収集することもできる。該モジュールは同様に、クライアント端末（Ｔ１、Ｔ２、４）からゲートウェイ（２）を介して別のＩＰネットワークに向かって伝送されたＳＩＰリクエストを収集することもできる。この異常調査モジュール（３０）はプロキシサーバ（３）のレベルに配置され得る。代替的には、ＳＩＰネットワーク（Ｎ）の中、好ましくはＩＰドメイン（１５）のネットワークエレメントの中に、複数の異常調査モジュール（３０）を想定することができる。

本発明による方法は、ネットワーク（Ｎ）に連結された通信端末（Ｔ１、Ｔ２、４）の間で一定のシグナリング・プロトコル（例えばＳＩＰ）に応じて実現されるマルチメディアセッションを管理し制御できるようにする。図１を参照すると、該方法には、例えば以下の段階が含まれる：
−シグナリング・プロトコルの不正使用を表わす異常調査段階（５０）、
−調査された異常に応じたリアクションの定義づけ（ｄｅｆｉｎｉｒ）段階（５００）、
−クライアント端末とプロキシサーバの間で交換されるリクエスト全体の収集段階（５１）、
−調査された異常の一つに各々が結びつけられた複数のインジケータを利用することにより、異常を検出するために収集されたリクエストを分析する段階（５２）。

少なくとも一つの異常を検出した場合（５３）、該方法は、図１の実施例においては、検出された異常に対応するリアクションをプロキシサーバ（３）によって開始させる段階（５４）を想定している。このリアクションには、有利には、異常を含むメッセージに関する通信の間へのリアルタイムでの干渉が含まれ得る。かくして、該方法が、例えばクライアント端末（Ｔ１、Ｔ２、４）とプロキシサーバ（３）の間で、ネットワーク（Ｎ）のシグナリング・プロトコル上での検出およびフィルタリングを可能にするということがわかる。同じシグナリング・プロトコル（ＳＩＰまたは類似のシグナリング・プロトコル）で確立されたリクエスト全体を収集することで、セッションの管理を集中させることが可能となる。かくして、クライアント端末（Ｔ１、Ｔ２、４）と通信プロキシサーバ（３）の間、そしてその逆方向で交換されるリクエスト全体を分析することができる。

有利には、異常の検出のおかげで、インフラストラクチャを通して加入者間で情報が伝播されない保証を得ることができる。Ｃａｌｌｅｒ−ＩＤの尋常でないサイズを検出するために、複数の閾値を利用することができる。図２に示されている通りのＳＩＰインフラストラクチャの実施例においては、本発明による方法は例えば、発信機のＣＡＬＬ−ＩＤの情報を宛先に向けて伝えないようにすることができる。本発明のこのような実施態様においては、ＳＩＰネットワーク（Ｎ）の変換モジュールまたはファンクション（Ｐ）のレベルで、異なる二つのＣＡＬＬ−ＩＤフィールドを管理することが可能となる。すなわち発信機と通信プロキシの交換の各々に専用のＣＡＬＬ−ＩＤフィールド、および、通信プロキシと宛先の交換の各々に専用の第二のＣＡＬＬ−ＩＤフィールドである。前記ファンクション（Ｐ）は、図２の実施例では、調査モジュール（３０）に結びつけられる。

図１を参照すると、プロキシサーバによって、各リクエストについて識別データの代入段階（５５）を実現することができる。この代入段階（５５）は、端末間で隠れ情報が伝播されない保証を得るために、宛先端末に向かってメッセージを転送する前に実施される。

本発明よる方法により、不正使用という異常を検出するべく、挙動（ｃｏｍｐｏｒｔｅｍｅｎｔａｌ）タイプ、またはシグニチャに基づいた分析フィルタを適用できるようにすることができる。挙動アプローチは、ユーザーが、ＳＩＰトランザクションの普段の使用に比べて異常な挙動をとったか否かを分析することから成る。シナリオによるアプローチは、分析を実施するために、異常なシグニチャのデータベースを必要とする。これらのシグニチャを捕捉済みパケットと比較することにより、不正使用の有無の結論を下すことが可能である。これが「ｐａｔｔｅｒｎ ｍａｔｃｈｉｎｇ（パターンマッチング）」と呼ばれるものである。代替的にまたは補足的に、本方法は、イベント同士を相関させ、定義づけされたシナリオに従ってリアクション（通信遮断、課金チケットの発行など）するために、ファンクション（Ｐ）を利用することができる。したがって、通信チャネルの確立は有利にも、ＩＰドメイン（１５）の内部で、ＳＩＰ（または類似のシグナリング・プロトコルの）リクエストについて実施されるフィルタリングによって制御される。本発明の一実施態様においては、検出された異常に結びつけられたリクエストメッセージに関する介入が、宛先端末までの該リクエストの伝達（５６）を妨げるわけではない。この場合、本方法は、隠れチャネルの利用に結びつけられた補足的課金の確立を想定することができる。

異常インジケータは、隠れチャネルの利用を検証（ｖｅｒｉｆｉｃａｔｉｏｎ）できるようにするべくパラメータ化される。このとき、課税（ｔａｘａｔｉｏｎ）および／または登録を回避する目的でのシグナリング・メッセージを通したデータの伝送を、検出し、さらには課金することができる。該インジケータは、ＳＩＰのモジュラー性（ｍｏｄｕｌａｒｉｔｅ）を考慮するものであり、情報を搬送する可能性のある隠れチャネルの各タイプに対応している。補遺に例示したＳＩＰメッセージの実施例は、ＳＩＰメッセージの構文を喚起するものである。ＳＩＰメッセージは、ｈｔｔｐ／１．１（ＲＦＣ ２０６８）というメッセージ構文を用いて符号化される。利用される文字セットは、ＩＳＯ １０６４６規格内で定義されており、ＵＴＦ符号化（ＲＦＣ ２２７９）を利用する。行はＣＲ ＬＦ（キャリッジリターン、改行）で終了する。リクエストおよび応答という二つのメッセージタイプが存在する。ヘッダーフィールドのうちのいくつかは、リクエストおよび応答の両方に存在し、一般ヘッダー（例えばＣａｌｌ−ＩＤ，ＣＳｅｑ，ｆｒｏｍ，ｔｏおよびｖｉａ）を形成する。ＳＩＰリクエストの構造は、ネットワークとの関係において、隠れて（ｃｏｖｅｒｔ、ｃａｃｈｅ）フィールドを利用するための盲点を見破らせる。本発明による管理方法に従うと、例えば次のような、情報の隠れた伝達の技術と同じ数だけのインジケータを想定することができる：
−Ｍｅｓｓａｇｅメソッドの異常な利用についてのインジケータ、
−ＳＩＰパケットのさまざまなヘッダーへの異常な記入を制御するための少なくとも一つのインジケータ、
−ペイロードＳＤＰのフィールドについてのインジケータ、
−応答コードの記述の異常な記入についてのインジケータ、
−Ｃａｌｌ−ＩＤ、ｔａｇおよびｂｒａｎｃｈについてのインジケータ

図１、２および５を参照すると、収集段階（５１）は全てのＴＣＰまたはＵＤＰ／ＳＩＰ交換の捕捉から成り得る。ＳＩＰトランザクションは、例えばヘッダー「Ｃｓｅｑ」を利用してまとめられる。実際、各々のトランザクションは、ＳＩＰトランザクションの内部でリクエストを対応する応答にくっつける（ｒａｐｐｒｏｃｈｅｒ）のに役立つ識別子である、ヘッダー「Ｃｓｅｑ」の共通値により識別される。識別子は、利用されるメソッドの名称および恣意的であり得るシーケンス番号で構成されている。リクエストに対する応答は、このリクエストと同一のヘッダー「Ｃｓｅｑ」を有していなくてはならない。

収集されたリクエストの分析段階（５２）は、例えば、特に以下の項目のうちの一つまたは複数を検出するべく、さまざまな分析方式に従ってＳＩＰトランザクションのトラフィック上で適用されるフィルタリングに対応する。
−例えばリクエスト頻度の増大、同一のトランザクション内のリクエスト／応答の数が多いこと、エラーコード（コード ４８０「一時的に利用不可能」）の増大といったような、トラフィックの類型の変更を検出することによる、トラフィック異常の分析、
−ＳＩＰプロトコルのざまざまなフィールド内のサイズの増大

ＳＩＰプロトコルのフィールドの異常な増加を認識するために、検出閾値を伴うインジケータが利用される。反復的または異常なイベントの出現閾値を伴うインジケータも利用される。異常を検出した場合に、異常調査モジュール（３０）は、調査された異常に応じて一つのアクションを指令するように各々がプログラミングされた一つまたは複数のリアクションモジュール（図示せず）を選択できるようにする情報を提供する。各リアクションモジュールは、例えばプロキシサーバ（３）によりアクティベートされ、異常を含むメッセージに関する通信の間へのリアルタイムでの介入を開始する。当然、リアクションモジュールを同じ一つの介入モジュールの中にまとめることが可能である。

異常な挙動（通信の確立の失敗ひいては１タイムラップ期間（ｃｏｕｒｓ ｌａｐｓ ｄｅ ｔｅｍｐｓ）での通信のトレース不能を結果としてもたらす、過剰なシグナリング・メッセージの交換）の閾値による検出（例えば過度に大きいヘッダーのフィールド）および統計的検出決定は、異常調査モジュール（３０）が利用できる機能性（ｆｏｎｃｔｉｏｎｎａｌｉｔｅ）である。ひとたび閾値に達したならば、モジュール（３０）に結びつけられたファンクション（Ｐ）は、非制限的な例として、通信／シグナリングを遮断し、一つの通信が進行中であることを報じるために対話者を識別する使用チケットを発行し、課金のため「ａｃｃｏｕｎｔｉｎｇ（清算）」を開始させることができる。したがって、この場合、複数の利用に関係する多数のカウンタを管理し、特に、交換される情報量の評価を可能にする走査されたヘッダー（Ｈｅａｄｅｒ）フィールドのサイズを管理する、通信コンテキストを維持するという概念が存在する。補足的フィルタリングが同様に、ＭＥＳＳＡＧＥパケットまたはＳＩＰプロトコルにおいて提案されるその他のメソッドのパケット（例えばＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹ）の分析を可能にし得る。

本発明の一実施態様においては、リアクションモジュールは、検出された異常なイベントに従って、例えば、
−ＳＩＰトラフィックトランザクションの切断、
−課金チケットの生成、
−ネットワーク（１５）のＩＰ部分の監視センタに対するリアルタイムでの通知警告の送付、
といったような予めパラメータ化されたシナリオのうちの一つまたは複数を実行する。

ＳＩＰフロー（または類似プロトコルのフロー）のフィルタリングには、異常調査の予備段階（５０）が関与する。調査モジュール（３０）は異常インジケータを利用できる状態にある。収集段階（５１）は、モバイル事業者のインフラストラクチャの中に本発明に従った管理システムを挿入することによって可能となる。このシステムは例えば、クライアント端末（Ｔ１、Ｔ２、４）とプロキシサーバ（３）の間のＳＩＰフローの切断を確実に行う。端末（Ｔ１、Ｔ２、４）とサーバ（３）の間で交換されるＳＩＰ双方向トランザクション全体が捕捉される。図５の実施例では、異常調査モジュール（３０）に結びつけられたファンクション（Ｐ）が、第一の無線電話ネットワーク（１６）のＳＩＰプロキシサーバ（３）のところに位置づけられている。このファンクション（Ｐ）は、ＳＩＰリクエストを管理し、第一の無線電話ネットワーク（１６）を介した隠れチャネルの利用を回避することができるようにする。かくして、異なる無線電話ネットワーク（１６、１６’）を介して通信する二つの端末（４１、４２）の間のＳＩＰセッションを、ＳＩＰプロトコルの利用を制御しながら確立することによって、リクエスト内へ情報を隠れて挿入する可能な手段の不正使用を妨げられるようになる。

図５の実施形態は、二つの異なる無線電話事業者のインフラストラクチャと共に、加入者データを回収するためのＨＳＳ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ）を例えば備えたＣＳＣＦ（Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）サーバ（３１、３２）を介したこれらのネットワーク間の通信を示している。これらの無線電話ネットワーク（１６、１６’）の各々の中に想定されているスイッチ（２２、２２’）およびゲートウェイ（２１、２１’）が、無線通信移動端末（４１、４２）までメッセージを伝達できるようにする。ＧＴＰプロトコル（ＧＰＲＳ Ｔｕｎｎｅｌ Ｐｒｏｔｏｃｏｌ）により、ＧＧＳＮ（Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）タイプのゲートウェイ（２１、２１’）とＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）タイプのスイッチ（２２、２２’）との間の通信が可能となる。無線電話ネットワーク（１６）のうちの少なくとも一つとインターネットタイプのドメイン（１５）との間のインタフェースに、ファイヤウォール（ＦＷ）を配置することができる。

図３により、シグナリング・プロトコルを用いた呼出しシナリオの通常の展開を再確認することができる。単純な通信シナリオでは、ＩＮＶＩＴＥ、ＡＣＫ、ＢＹＥといったようなＳＩＰリクエストが利用される。ＳＩＰクライアント端末（Ｔ１）は、ＩＮＶＩＴＥメッセージを用いて別の端末（Ｔ２）を呼出す。送信されたメッセージは、発呼クライアント端末（Ｔ１）に向かってのメディアフローを確立できるようにする情報を含んでいる。以下の例は、ＳＩＰプロトコルに従ったインビテーションメッセージを例示している。
ＩＮＶＩＴＥ ｓｉｐ ｃｈｒｉｓｔｉａｎ＠ｄｏｍａｉｎ．ｆｒ ＳＩＰ／２．０
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ｛ｍｙ ｐｒｉｖａｔｅ ａｄｄｒｅｓｓ：ｐｏｒｔ｝；ｂｒａｎｃｈ＝｛ｂｒａｎｃｈ｝
Ｍａｘ＿ｆｏｒｗａｒｄｓ：７０
Ｆｒｏｍ：｛“Ｃｈｒｉｓｔｉａｎ“｝＜ｓｉｐ：｛ｃｈｒｉｓｔｉａｎ＠ｄｏｍａｉｎ．ｆｒ｝＞；
Ｔｏ：｛Ｐａｕｌ｝＜ｓｉｐ：｛ｐａｕｌ＠ｄｏｍａｉｎ．ｆｒ｝＞；
Ｃａｌｌ−ＩＤ：｛２９６６３２４５５８−ｅｄｃ−６５４８−ｆｇ８ｇ９｝
ＣＳｅｑ：｛１｝ＩＮＶＩＴＥ
Ｅｘｐｉｒｅｓ：１８００
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：｛１８７｝

ＳＩＰサーバ、例えばドメイン「ｄｏｍａｉｎｅ．ｆｒ」のプロキシサーバ（３）は、一つまたは複数の応答を用いてＳＩＰリクエストに応答する。２ｘｘ、３ｘｘ、４ｘｘ、５ｘｘおよび６ｘｘという形のコードをもつ応答の大部分は、「最終的な」応答であり、現行のトランザクションを終了させる。１ｘｘという形の応答は、暫定応答である。応答の一実施例を以下に提供する：
ＳＩＰ／２．０ １００ Ｔｒｙｉｎｇ
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ｛ｍｙ ｐｒｉｖａｔｅ ａｄｄｒｅｓｓ：ｐｏｒｔ｝；ｂｒａｎｃｈ＝｛ｂｒａｎｃｈ｝
Ｆｒｏｍ：Ｐａｕｌ｝＜ｓｉｐ：｛ｐａｕｌ＠ｄｏｍａｉｎ．ｆｒ
Ｔｏ：｛｝＞｛“Ｃｈｒｉｓｔｉａｎ”｝＜ｓｉｐ：｛ｃｈｒｉｓｔｉａｎ＠ｄｏｍａｉｎ．ｆｒ｝＞；
Ｃａｌｌ−ＩＤ：｛２９６６３２４５５８−ｅｄｃ−６５４８−ｆｇ８ｇ９｝
ＣＳｅｑ：｛１｝ＩＮＶＩＴＥ

図３の例においては、
−応答コード「１００」は処理中「Ｔｒｙｉｎｇ」を意味し、
−応答コード「１８０」は進行中の呼び出し音「Ｒｉｎｇｉｎｇ」を意味し、
−応答コード「２００」は「ＯＫ」を意味する。

トランザクションおよびメッセージ再伝送の概念を理解するために、ここでＳＩＰダイアログ（ｄｉａｌｏｇｕｅ）が「Ｆｒｏｍ」、「Ｔｏ」、Ｃａｌｌ−ＩＤおよびシーケンス番号「Ｃｓｅｑ」というフィールドの組合せによって識別されるということを喚起しておくべきである。ダイアログが確立された場合、全てのリクエストおよび応答は、これらのヘッダーフィールドを内含しなければならない。各トランザクションはヘッダー「Ｃｓｅｑ」の共通値によって識別される（メソッドの名称およびシーケンス番号は同一でなくてはならない）。本発明によるシステムは、各トランザクションの中で、付随する応答と共に発信されたリクエストのタイプを分析し、トランザクションを互いに比較することを可能にし得る。

本発明の一実施態様においては、管理システムは、特に、ヘッダー「Ｃａｌｌ−ＩＤ」内でのファイルの送信といったような、隠れチャネルの使用を検出するために、シグナリング・プロトコルセッションの反復を監視できるようにする。このタイプのセッションについては、送信端末（Ｔ１）と受信端末（Ｔ２）の間の通信の展開は、以下のようになる：
−まず第一に、送信機（Ｔ１）は、Ｃａｌｌ−ＩＤ内にデータを入れてＩＮＶＩＴＥメッセージを受信機（Ｔ２）に送信し、
−受信機（Ｔ２）は、「４８０ Ｔｅｍｐｏｒａｒｉｌｙ ｕｎａｖａｉｌａｂｌｅ」というコードおよび同じＣａｌｌ−ＩＤで応答する；したがってコード４８０の返送は、受信機（Ｔ２）のユーザーが呼出しを拒絶していることを意味している。
−このように戻されたコード４８０により、送信機（Ｔ１）は、受信機（Ｔ２）がＩＮＶＩＴＥメッセージを確かに受信した保証を得ることができ、この送信機（Ｔ１）はこのとき、ＳＩＰセッションのクローズを確認するために同じＣａｌｌ−ＩＤを用いて肯定応答メッセージＡＣＫを送付することで続行する。

この場合、プロキシサーバ（３）は、呼出しは一度も成功せず、セッションは終了したとみなす。ＩＮＶＩＴＥ−４８０−ＡＣＫシーケンスは不成功呼出しとみなされることから、このタイプのシーケンスを複数連続させることによって情報を伝送することは充分に可能である。このタイプのシーケンスの数が多いことは、異常とみなされなくてはならないことが分かる。本発明に従ったシステムは、この異常に固有のインジケータのおかげでこのタイプの異常を容易に検出させることができる。

図４を参照すると、ＳＵＢＳＣＲＩＢＥおよびＮＯＴＩＦＹといったような汎用的なリクエストも同じく、本発明によるシステムに備わったインジケータのおかげで制御可能である。ＳＵＢＳＣＲＩＢＥおよびＮＯＴＩＦＹといったリクエストを利用するという行為は監視が可能であり、マルチメディアコンテンツが隠れチャネルを介して交換されているならば例えば一つのリアクションを開始させることができる。これら二つの汎用的なリクエストは、ヘッダー「Ｆｒｏｍ」および「Ｔｏ」を用いてプロキシサーバ（３）によりルーティング可能であり、応答により肯定応答（ａｃｑｕｉｔｔｅｒ）される。ＳＵＢＳＣＲＩＢＥリクエストは、ある種のイベントを受信したいと考えているクライアント端末（Ｔ１）によって、イベント（例えば、友達リスト「ｂｕｄｄｙ ｌｉｓｔ」タイプのアプリケーションに対する存在情報要求）を生成するサーバ（３）に向かって送られる。ＳＵＢＳＣＲＩＢＥリクエストは、登録期間を示す「Ｅｘｐｉｒｅｓ」をヘッダーの中に含む。ＮＯＴＩＦＹリクエストは、イベントの通知を送るのに役立つ。

これらのＳＵＢＳＣＲＩＢＥおよびＮＯＴＩＦＹというリクエストは、一つのＳＩＰダイアログを作成することができ、ＩＮＶＩＴＥリクエストを必要とせず、任意の時点で非同期的に送付され得る。ネットワーク事業者は、本発明によるシステムのおかげで、このダイアログを制御することができる。そのためには、分析およびフィルタリングデバイスの中にこのタイプのシナリオを組み込むだけでよい。異常調査モジュール（３０）は、不正な方法でＳＩＰダイアログを開始できるようにする段階に匹敵する（ｃｏｍｐａｒａｂｌｅ）一連のイベントに関係する、インジケータを備えることができる。

本発明の一つの利点は、事業者がＶｏＩＰのプロトコルの中での並行チャネルの使用をコントロールできるようにするために、リアルタイムでのメッセージの監視を可能にするという点にある。かくして、ＳＩＰプロトコルを介して利用可能な並行チャネル全体を本発明によるＳＩＰリクエスト管理システムによって制御することができる。利用可能な並行通信手段のマッピングにより、異常調査モジュール（３０）が利用することになる適切なインジケータを提供することが可能となる。

並行通信手段を見つけるのに必要なテストの各記述（ｄｅｓｃｒｉｐｔｉｏｎ）は、逐次的に予め符号化可能である。文法（ｇｒａｍｍａｉｒｅ）によって、異常調査モジュール（３０）が利用し評価できると思われるシグナリングプロトコルのフィールドのリストを記述することができる。マッピングがひとたび実現されたならば、マッピングされた並行チャネルの利用可能性についての一連の反復テストにより、並行チャネルの各々について利用可能な帯域幅を評価することを考慮することができる。

Ｃａｌｌ＿ＩＤフィールドによっていかなるコンテンツも並行して伝送されない保証を得るために、本発明によるシステムはこのフィールドを特定する（例えば書換える）ことができる。この書換えは、例えばプロキシサーバ（３）に付随するファンクション（Ｐ）を介して実施可能である。この場合、該ファンクション（Ｐ）は、二つの異なるＣＡＬＬ−ＩＤフィールドを管理することによって、このフィールドにより情報を伝播させないようにする。プロキシサーバ（３）のレベルでの単なる書換えにより、当業者であればわかるように、伝播を妨げることができる（それ自体既知のエンロールメント（ｅｎｒｏｌｅｍｅｎｔ）技術、当初登録されたデータとの関係におけるフィールドの上書きなど）。したがってこのタイプのフィールド内の文字数は、変換ファンクション（Ｐ）によって実現される書換え作業のおかげで制限される。類似の要領で、他のフィールドおよび並行チャネルを管理することができる。

当業者にとっては、本発明が、請求されている通りの本発明の利用分野から逸脱することなく他の数多くの特定の形態での実施態様を可能にするものであるということは明白である。したがって、当該実施態様は例示としてみなされるべきであるものの、添付の請求項の範囲により定義された分野において変更は可能であり、本明は上述の詳細によって制限されるべきではない。

補遺
ＳＩＰメッセージの一実施例
ＩＮＶＩＴＥ ｓｉｐ：ｊａｃｑｕｅｓ＠ｍｙｄｏｍａｉｎ．ｆｒ ＳＩＰ／２．０
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ １３９．１００．１８４．１２：５０４０
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ ｓｉｐｓｅｒｖ．ｍｙｄｏｍａｉｎ．ｆｒ：５０６０
Ｍａｘ−Ｆｏｒｗａｒｄｓ：７０
Ｔｏ：Ｊａｑｕｅｓ＜ｓｉｐ：ｊａｃｑｕｅｓ＠ｍｙｄｏｍａｉｎ．ｆｒ＞
Ｆｒｏｍ：Ｐａｕｌ＜ｓｉｐ：ｐａｕｌ＠ｍｙｄｏｍａｉｎ．ｆｒ＞
Ｃａｌｌ−ＩＤ：２９６６３２４５５８−ｅｄｃ−６５４８−ｆｇ８ｇ９
ＣＳｅｑ：１ ＩＮＶＩＴＥ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：１８７
＜ｐａｙｌｏａｄ ＳＤＰ＞

本発明の一実施形態における、本方法の段階の論理図である。 本発明に従ったマルチメディアセッションの管理を可能にするネットワークを示す図である。 本発明に従ったシステムのインジケータの利用によって検出可能な第一の呼出しシナリオを示す図である。 本発明に従ったシステムのインジケータの利用によって検出可能な第二の呼出しシナリオを示す図である。 無線電話事業者ネットワークが本発明の一実施形態に従ったＳＩＰリクエストを監視および管理するシステムを備える、ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ（ＩＭＳ）コンテキストを概略的に表す図である。

符号の説明

Ｎ ネットワーク
Ｔ１、Ｔ２、４ 端末
１５ ＩＰドメイン
１６、１６’ 無線電話ネットワーク
２、２１、２１’ ゲートウェイ
２２、２２’ スイッチ
３ プロキシサーバ
３０ 異常調査モジュール
３１、３２ ＣＳＣＦサーバ
４１、４２ 端末

Claims (17)

1. 電気通信（ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ）ネットワークにより接続された通信端末の間で、所定のシグナリング・プロトコルに従って実現されるマルチメディアセッションを管理する方法であって、該方法は、シグナリング・プロトコルの不正使用を表わす異常の調査段階（５０）、および調査された異常に応じたリアクション（ｒｅａｃｔｉｏｎ）の定義づけ（ｄｅｆｉｎｉｒ）段階（５００）を予め含むことを特徴とし、
   −クライアント端末（Ｔ１、Ｔ２、４）およびプロキシサーバ（３）の間で交換されるリクエスト全体を収集する段階（５１）、
   −複数のインジケータ（ｉｎｄｉｃａｔｅｕｒ）の各々に予め調査された異常のうちの一つが結びつけられたものを利用して、異常を検出するために、収集されたリクエストを分析する段階（５２）、
   をさらに含むことを特徴とする、マルチメディアセッション管理方法。
2. 少なくとも一つの異常を検出（５３）した場合に、検出された異常に対応する一つのリアクションをプロキシサーバ（３）が開始する段階（５４）を含み、前記リアクションには該異常を有するメッセージに関する通信の間へのリアルタイムでの介入が含まれることを特徴とする、請求項１に記載のマルチメディアセッション管理方法。
3. 端末間で隠れた情報（ｃｏｖｅｒｔ ｉｎｆｏｒｍａｔｉｏｎ、ｉｎｆｏｒｍａｔｉｏｎ ｃａｃｈｅｅ）が伝播されない保証を得るために、宛先端末に向かってメッセージを転送する前に、プロキシサーバが各リクエスト内に識別データを代入する段階（５５）を含むことを特徴とする、請求項１または２に記載のマルチメディアセッション管理方法。
4. 収集されたリクエストの分析段階（５２）が、リクエストのＳＩＰパケットのヘッダーに関係する異常インジケータを利用することを特徴とする、請求項１〜３のいずれか一つに記載のマルチメディアセッション管理方法。
5. 収集されたリクエストの分析段階（５２）が、各リクエストのコーラー（ａｐｐｅｌａｎｔ）の識別フィールド「Ｃａｌｌ ＩＤ」に関係する異常インジケータを利用することを特徴とする、請求項１〜４のいずれか一つに記載のマルチメディアセッション管理方法。
6. 収集されたリクエストの分析段階（５２）が、ＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹメソッドに関係する異常インジケータを利用することを特徴とする、請求項１〜５のいずれか一つに記載のマルチメディアセッション管理方法。
7. 収集されたリクエストの分析段階（５２）が、隠れチャネル（ｃｏｖｅｒｔ ｃｈａｎｎｅｌ、ｃａｎａｌ ｃａｃｈｅ）の活用を可能にするＳＩＰプロトコルの中で利用されるメソッドの一つに関係する異常インジケータを利用することを特徴とする、請求項１〜６のいずれか一つに記載のマルチメディアセッション管理方法。
8. 収集されたリクエストの分析段階（５２）が、応答コードの記述子（ｄｅｓｃｒｉｐｔｉｆ）に関係する異常インジケータを利用することを特徴とする、請求項１〜７のいずれか一つに記載のマルチメディアセッション管理方法。
9. 収集されたリクエストの分析段階（５２）が、ＳＩＰリクエストのペイロード（ｃｈａｒｇｅ ｕｔｉｌｅ）中のＳＤＰフィールドに関係する異常インジケータを利用することを特徴とする、請求項１〜８のいずれか一つに記載のマルチメディアセッション管理方法。
10. 収集されたリクエストの分析段階（５２）が、各々のＳＩＰリクエストの標識つまりＴＡＧに関係する異常インジケータを利用することを特徴とする、請求項１〜９のいずれか一つに記載のマルチメディアセッション管理方法。
11. 前記リアクションが、検出された異常に応じた課金段階を含み、該段階において、課金に必要となる、かつ事業者の法律上の義務を遵守した情報が専用課金サーバに向かって伝送されることを特徴とする、請求項２に記載のマルチメディアセッション管理方法。
12. 前記リアクションには、ネットワーク（Ｎ）のＩＰの部分（１５）の監視センタに少なくとも一つの異常をリアルタイムで通知するための警告メッセージの伝送が含まれることを特徴とする、請求項２または１１に記載のマルチメディアセッション管理方法。
13. プロキシサーバ（３）に結びつけられた変換モジュール（Ｐ）が、同じＳＩＰリクエストについて、一対のフィールドを管理する段階を含み、該段階において第二のフィールドが第一のフィールドをもとに書換えられることを特徴とする、請求項１〜１２のいずれか一つに記載のマルチメディアセッション管理方法。
14. 該リアクションがＳＩＰセッションの切断段階を含むことを特徴とする、請求項２に記載のマルチメディアセッション管理方法。
15. 少なくとも一つのクライアント端末（Ｔ１、Ｔ２）とＳＩＰプロキシサーバ（３）の間のＳＩＰタイプのネットワーク内で利用されることを目的とするマルチメディアセッションの管理システムであって、
    −シグナリング・プロトコルの不正使用を表わす異常インジケータ（ｉｎｄｉｃａｔｅｕｒ）を記憶するための記憶手段；
    −クライアント端末（Ｔ１、Ｔ２）の各々とＳＩＰプロキシサーバ（３）の間で交換されるＳＩＰリクエスト全体を収集するためのＳＩＰリクエスト分析ファンクションを備えた、前記インジケータと組になる異常調査モジュール、
    −調査された異常に応じて一つのアクション（ａｃｔｉｏｎ）を指令するように各々プログラミングされたリアクション（ｒｅａｃｔｉｏｎ）モジュールであって、各々のリアクションモジュールはプロキシサーバ（３）によりアクティベート（ａｃｔｉｖｅｒ）され、該異常を有するメッセージに関する通信の間にリアルタイムで一つの介入を開始する、リアクションモジュール、
    を含むことを特徴とする、マルチメディアセッション管理システム。
16. 同じＳＩＰリクエストについて二つの異なるフィールドを管理するためにプロキシサーバ（３）に変換モジュール（Ｐ）が具備されており、該変換モジュール（Ｐ）の書換え手段によって、第二フィールドが第一フィールドをもとに書換えられることを特徴とする、請求項１５に記載のマルチメディアセッション管理システム。
17. 請求項１５に記載のマルチメディアセッション管理システムを備えることを特徴とする、複数のネットワークエレメントを含む、ＳＩＰプロトコルを利用するネットワーク（１５）。

Images