テキストベースのプロトコルによる受信データメッセージのハンドリング
【課題】テキストベースプロトコルに従って、データメッセージを端末で受信する。
【解決手段】最初に、受信データメッセージを、事前パース基準のセットに従って事前パースする。次に、上記データメッセージに関連付けられるメッセージコンテキストを生成する。当該メッセージコンテキストは、事前パースステップから取得された情報を示す。次に、上記データメッセージ及び上記関連付けられるメッセージコンテキストを、端末上で実行されているアプリケーションに提供する。
【解決手段】最初に、受信データメッセージを、事前パース基準のセットに従って事前パースする。次に、上記データメッセージに関連付けられるメッセージコンテキストを生成する。当該メッセージコンテキストは、事前パースステップから取得された情報を示す。次に、上記データメッセージ及び上記関連付けられるメッセージコンテキストを、端末上で実行されているアプリケーションに提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、包括的には、ＳＩＰプロトコル（「セッション開始プロトコル」を表す）又はＨＴＴＰプロトコル（「ハイパーテキスト転送プロトコル」を表す）又はＳＭＴＰプロトコル（「シンプルメール転送プロトコル」を表す）のようなテキストベースプロトコルに関し、より詳細には、このタイプのプロトコルに基づくアプリケーションを使用する端末の保護に関する。
【背景技術】
【０００２】
いくつかのテキストベースのプロトコルは、多くのネットワークで使用される。ＩＥＴＦ（「インターネットエンジニアリングタスクフォース」を表す）によって標準化されたプロトコルＳＩＰがこれに該当する。このテキストベースのプロトコルは、特に、アプリケーションＶｏＩＰ（「ボイスオーバインターネットプロトコル」を表す）に使用される。
【０００３】
このようなテキストベースのプロトコルは、高水準プログラミング言語のように、文法規則セットによって定義されたシンタックスを有する。その結果、ＳＩＰメッセージの復号は、複雑なタスクとなる可能性があり、このような復号オペレーションを担当するエンティティは、大量のメモリ及び計算資源を有する。
【０００４】
図１は、ＳＩＰメッセージ１４がＴＣＰ（「転送制御プロトコル」を表す）レイヤ又はＵＤＰ（「ユーザデータグラムプロトコル」を表す）レイヤを通じて送信される従来のアーキテクチャにおけるＳＩＰメッセージの処理を示している。メッセージＳＩＰ１４が、ＴＣＰ／ＵＤＰスタック１１を通じて端末のＵＤＰポート又はＴＣＰポート上で受信されると、メッセージＳＩＰ１４はＳＩＰパーサ１２によって解析される。このパーサは、このＳＩＰメッセージのシンタックスをチェックし、対応するＳＩＰアプリケーション１３に適合するＳＩＰ構造体１５を生成する。
【０００５】
この処理中、受信されたＳＩＰメッセージは、２回チェックされる。最初はＳＩＰパーサ１２のレベルでチェックされ、後にＳＩＰアプリケーション１３のレベルでチェックされる。一般に、ＳＩＰパーサ又はＳＩＰアプリケーションによってＳＩＰメッセージにエラーが検出されると、そのＳＩＰメッセージは廃棄される。
【０００６】
ＳＩＰパーサ１２において実行されるチェックのステップは、複雑であり、多くの時間を費やす。確かに、ＳＩＰメッセージの廃棄を決定する前に、ＳＩＰパーサは、このメッセージをかなり完全にパース(構文解析)する必要がある。その結果、処理電力は、不必要に消費される可能性がある。
【０００７】
加えて、一般に、端末は、フォームファクタ又はコストのようなさまざまな理由によって処理資源を制限される可能性があり、そのため、処理資源は通常の動作状態に適合するように決定される。その結果、このような端末が、たとえば、ＳＩＰパーサレベルにおける多くのチェックタスクが原因で異常な動作状態で動作すると、端末は、この場合に十分な処理資源を有しないので、その基本タスクを正しく実行することができない。
【０００８】
したがって、多くのＳＩＰメッセージをいくつかの端末へ送信することは、このプロトコルに基づくネットワークサービスに対する効率的な攻撃になる可能性がある。特に、ＳＩＰメッセージを処理するいくつかのソフトウェア機能は、端末があらゆる通常のオペレーションを実行することを妨げる効率的な攻撃のターゲットになる可能性がある。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明は、端末上で実行されるテキストベースのプロトコルに基づくアプリケーションのロバスト性及び性能を向上させることを目的とする。
【００１０】
上記に鑑み、性能、及び攻撃に対する保護を増大させることができる、テキストベースのプロトコルに従って受信されたデータメッセージをハンドリングする方法を強化する必要性がある。
【課題を解決するための手段】
【００１１】
本発明の第１の態様は、端末においてテキストベースのプロトコルに従って受信データメッセージをハンドリングする方法を提案し、
当該方法は、以下のステップ、すなわち、
／１／事前パース（pre parcing）基準のセットに従って、上記受信データメッセージを事前パースするステップと、
／２／データメッセージに関連付けられるメッセージコンテキストを生成するステップであって、上記メッセージコンテキストは、事前パースするステップから取得された情報を示す、生成するステップと、
／３／データメッセージ及び上記関連付けられるメッセージコンテキストを端末上で実行されているアプリケーションに提供するステップと、
を含む。
【００１２】
端末上で実行されるアプリケーションに、受信データメッセージに関連したメッセージコンテキストを提供することによって、アプリケーションレベルで当該データメッセージに対して行われる解析の上流側で、受信メッセージに対してチェックを行ういくつかのステップを実行することが可能である。したがって、いくつかのチェックステップを先取りして、アプリケーションレベルでデータメッセージをチェックすることに起因する負荷を削減すると共に、端末レベルでの受信データメッセージのチェックを最適化することが可能である。
【００１３】
これらの状況では、多くのデータメッセージを送信して対応するアプリケーションを過負荷にすることに基づくいくつかの攻撃を防止することができる。ＳＩＰアプリケーションに対してこのような方法を実行することは、特に有利となり得る。
【００１４】
一実施の形態では、事前パース基準のセットは、文法規則のセット(a set of grammatical rules)及び／又はセマンティック規則のセット(a set of semantic rules)を含む。
【００１５】
文法規則のセットは、解析されたテキストベースのプロトコルに従って有利に定めることができ、いくつかの決定された関連のあるフィールドに対する部分解析に対応することができる。
【００１６】
いくつかの決定された関連のあるフィールドは、完全な文法解析によって提供されるロバスト性とハンドリングの効率性との間の良好な妥協を有するように選択することができる。
【００１７】
ＳＩＰプロトコルの場合、このセットは、対応するＩＥＴＦ ＲＦＣ３２６１で定義されたＡＢＮＦ文法（「拡張バックス・ナウア記法（Augmented Backus-Naur form）」を表す）に基づくことができ、効率性及びロバスト性を向上させるために簡単化することができる。
【００１８】
セマンティック規則のセットは、いくつかの決定された関連のあるフィールドの有効性をチェックする部分解析に対応することができる。
【００１９】
この規則のセットは、効率性とロバスト性との間の妥協を可能にすることができる。この部分解析は、たとえば、関連のあるフィールドのうちの１つのコンテンツをチェックすることに対応することができ、且つデータメッセージのこのようなフィールドの長さをチェックすることに対応することができる。
【００２０】
事前パースするステップにおいて、データメッセージを、以下のクラス、すなわち、
文法規則のセットに基づき文法的に無効（grammatically invalid）、又は
セマンティック規則のセットに基づきセマンティック的に無効（semantically invalid）、又は
事前パース基準に関して有効、
のうちの１つに有利に分類することができ、関連付けられるメッセージコンテキストは上記クラスを示すことができる。
【００２１】
この情報は、データメッセージ及びそれに関連付けられるメッセージコンテキストを受信する対応するアプリケーションにとって非常に有用であることができる。
【００２２】
事前パースするステップの前に、事前廃棄ステップを有利に実行することができる。当該事前廃棄ステップは、メッセージが、事前廃棄基準のセットに基づいて廃棄されるものとみなされるか否かを判断することを担当する。このような事前廃棄基準は、たとえば、受信メッセージのスループットのしきい値に基づくことができる。
【００２３】
本発明の一実施の形態では、事前廃棄として分類されるデータメッセージは、前処理の他のステップを通じて処理されない。
【００２４】
受信データメッセージがデータパケットで受信されるとき、ステップ／１／の前に、連続したデータメッセージを受信データパケットからデリニエート(delineating)するステップを有利に実行することができる。このステップは、使用されるトランスポートプロトコルがＴＣＰプロトコルであるときに有用であることができる。
【００２５】
データメッセージ及び関連付けられるメッセージコンテキストをアプリケーションに提供するステップの前に、事前パースステップの結果に基づいて上記データメッセージをフィルタリングするステップをさらに実行することができる。
【００２６】
テキストベースのプロトコルは、ＳＩＰプロトコル、ＨＴＴＰプロトコル、及びＳＭＴＰプロトコル等の、ＩＥＴＦによって定義されたプロトコルのうちの１つとすることができる。
【００２７】
メッセージコンテキストは、事前パースステップ中に満たす(fill)ことができる。
【００２８】
本発明の第２の態様は、端末においてテキストベースプロトコルに従って受信データメッセージをハンドリングするようになっている前処理モジュールを提案し、
当該前処理モジュールは、以下のユニットから成るセット、すなわち、
−事前パース基準のセットに従って、上記受信データメッセージを事前パースするようになっている事前パースユニットと、
−上記データメッセージに関連付けられるメッセージコンテキストを生成するようになっている生成ユニットであって、当該メッセージコンテキストは、事前パースユニットから取得された情報を示す、生成ユニットと、
−上記データメッセージ及び上記関連付けられるメッセージコンテキストを端末上で実行されるアプリケーションに提供するようになっているフィルタリングユニットと、
から成るセットを備える。
【００２９】
この前処理モジュールは、端末レベルでハンドリングされる接続ごとに１つのユニットのセットを備えることができる。
【００３０】
この前処理モジュールは、ユニットのセットから少なくとも１つのユニットに関する構成情報を受信するようになっている構成インターフェースをさらに備えることができる。
【００３１】
このような前処理モジュールは、オフロードモジュールとすることができる。これは、前処理をメインプロセッサとは別のプロセッサが実行することができることを意味する。
【００３２】
本発明の第３の態様は、本発明の第２の態様による前処理モジュールを備える端末を提案する。
【００３３】
本発明のさらなる特徴及び利点は、以下の説明からより明らかになるであろう。以下の説明は、単に例示として与えられ、添付図面と共に読まれるべきである。
【図面の簡単な説明】
【００３４】
【図１】従来技術によるＳＩＰメッセージハンドリングのアーキテクチャの図である。
【図２】本発明の一実施形態による端末のアーキテクチャにおける、受信されたＳＩＰメッセージの処理を示す図である。
【図３】本発明の一実施形態によるＳＩＰソケットを詳細に示す図である。
【図４】ハードウェア端末のＳＩＰ前処理モジュールの使用を示す図である。
【発明を実施するための形態】
【００３５】
本発明は、以下の本明細書において、ＳＩＰプロトコルに対する一例示の適用で説明される。しかし、同じ原理を他の任意のテキストベースのプロトコルに適用することは容易である。
【００３６】
ＳＩＰプロトコルのパースは、特に組み込み環境で、ＣＰＵ及びメモリ資源を必要とする特に複雑なタスクである。これは、ＳＩＰプロトコルが受信側で多くの制御を伴う複雑な記述言語に基づいているからである。
【００３７】
本発明の一実施形態は、端末側で実行されるＳＩＰアプリケーションによって行われるパース及びチェックのタスクを容易にすることを可能にする。そのために、本発明の一実施形態では、受信されたＳＩＰシグナリングメッセージ内部の主要なアイテムを発見及びチェックするために、前処理が行われる。
【００３８】
このような前処理は、いくつかの場合にはＳＩＰメッセージを廃棄可能にするために、又は、ＳＩＰアプリケーションレベルのチェック段階に有用であるいくつかの情報を取り出すために、いくつかの主要なアイテムのみをチェックすることによって、受信されたＳＩＰメッセージを高速且つ効率的にチェックすることを可能にする。そのために、いくつかの情報が、本発明に従い、関連付けられるメッセージコンテキストにおいて、ＳＩＰアプリケーションに提供されるＳＩＰメッセージに関連付けられる。
【００３９】
したがって、このような前処理を行うことによって、ＳＩＰアプリケーションに情報を通知することができ、それによってアプリケーションレベルで行われるチェックステップが容易になる。
【００４０】
この前処理は、ＳＩＰアプリケーションによって行われるパースに取って代わるものではない。しかしながら、前処理は、アプリケーションレベルで実行されるパースの効率性を向上させるために、受信された各ＳＩＰメッセージについて、ＳＩＰアプリケーションに有用である情報を含む関連付けられるメッセージコンテキストを提供する。その上、この前処理は、たとえばエラーのあるＳＩＰメッセージに起因する過負荷を防止することによって、ＳＩＰアプリケーションのロバスト性を有利に高めることができる。
【００４１】
このようなメッセージコンテキストは、その関連付けられるメッセージコンテキストに含まれる情報に基づいて前処理によって無効とみなされたＳＩＰメッセージを廃棄するために、又は、ＳＩＰメッセージ全体をパースすることなくＳＩＰメッセージによって伝達された幾つかの特定の情報に直接アクセスするために、ＳＩＰアプリケーションレベルで有利に使用することができる。なお、このような特定の情報は、関連付けられるメッセージコンテキスト上に示されている。
【００４２】
その結果、このメッセージコンテキストは、いくつかのＳＩＰメッセージの廃棄を提案すること、又は、ＳＩＰアプリケーションレベルでパースするのに有用であるいくつかの情報を示すことのいずれかによって、ＳＩＰアプリケーションの負荷を低減することを可能にする。
【００４３】
これらの状況では、ＳＩＰプロトコルを実施する端末においてＳＩＰシグナリングチャネルの悪用の影響を低減又は防止することが可能である。
【００４４】
一実施形態では、ＳＩＰシグナリングチャネルの悪用は、以下のように定義することができる。すなわち、
−非ＳＩＰデータパケットをＳＩＰシグナリングチャネルによって送信すること、
−エラーのあるＳＩＰメッセージをＳＩＰシグナリングチャネルによって送信すること、又は
−適合していないレートでＳＩＰシグナリングチャネルによってデータパケットを送信すること、
と定義することができる。
【００４５】
本発明の一実施形態では、ＳＩＰアプリケーションは、ＳＩＰメッセージに関連して提供されたメッセージコンテキストに含まれる情報を正しく且つ効率的に利用するように設計される。しかしながら、たとえ前処理が本発明に従って実行されても、既存のＳＩＰアプリケーションを実行することができる。
【００４６】
本発明によるＳＩＰ前処理の技術的な実施には、何の制限も付随していない。たとえば、ＳＩＰ前処理は、ＳＩＰアプリケーションレベルで実行されるＳＩＰ処理ステップの上流側で、ソフトウェアモジュール又はハードウェアモジュールのいずれとしてでも端末機器において実施することができる。
【００４７】
図２は、本発明の一実施形態による端末のアーキテクチャにおける受信されたＳＩＰメッセージの処理を示している。
【００４８】
ＳＩＰシグナリングセッションは、発呼側端末と着呼側端末との間に確立することができる。発呼側端末は、呼セッション要求を着呼側端末へ送信することによって呼セッションを開始することができる。
【００４９】
このようなＳＩＰシグナリングセッションは、ＵＤＰプロトコル又はＴＣＰプロトコルに対応することができるレイヤ４フローの上に確立することができる。この場合、ＳＩＰシグナリングセッションは、
−発呼側端末及び着呼側端末のそれぞれのＩＰアドレス、
−発呼側端末によって選択された所与の送信元ポート番号、及び
−ＲＦＣ３２６１（「コメント要求(Request For Comments)」を表す）で定義された５０６０のような標準値とすることができる宛先ポート番号、
によって一意に識別される。
【００５０】
使用されるレイヤ４プロトコルがＴＣＰプロトコルであるとき、ＴＣＰ接続は、ＳＩＰシグナリングセッションの確立よりも前に発呼側端末と着呼側端末との間に確立され、このＳＩＰシグナリングセッションの終了後に切断される。
【００５１】
その場合、ＴＣＰ接続の一方向によって送信されたＳＩＰメッセージは、たとえば、各ＳＩＰメッセージヘッダの特定のフィールドに示されたコンテンツ長の表示、ＳＩＰ要求メッセージのメソッド名の表示、又はＳＩＰ応答メッセージのステータスライン上の表示のような、ＳＩＰメッセージ内に設けられた情報を使用することによって区切られる。
【００５２】
使用されるレイヤ４プロトコルがＵＤＰプロトコルであるとき、各ＳＩＰメッセージは、単に、単一のＵＤＰデータグラムにカプセル化される。ＳＩＰメッセージの区切りは、この場合、ＵＤＰによって暗黙的に行われる。
【００５３】
本発明の一実施形態では、前処理が、特定の宛先ポートのセットのレイヤ４フローによって受信されたデータパケットに適用される。
【００５４】
例示として、図２において、端末２０は、
−データパケットが受信されるネットワークとのインターフェースであるようになっているプロトコルスタック２１（ＴＣＰ／ＩＰスタック）、
−ＳＩＰソケット２２と呼ばれる複数の前処理エンティティを含むＳＩＰ前処理モジュール２４、並びに
−第１及び第２のＳＩＰアプリケーション２３、
を備える。
【００５５】
図示されたケースでは、ソケット＃１、ソケット＃２、及びソケット＃３の３つの異なるＳＩＰソケットが、本発明の一実施形態に従って端末レベルで管理される。
【００５６】
これらのＳＩＰソケット２２のそれぞれの内部では、最初にデータパケットがデータパケットＦＩＦＯ２０１で受信される。次に、受信されたデータパケットは、前処理ユニット２０２で処理される。この前処理ユニット２０２の出力では、受信された各データメッセージについて、メッセージコンテキストが生成される。データメッセージ及びその関連付けられるメッセージコンテキストは、ＳＩＰアプリケーションレベル２３へ送信される。
【００５７】
有利なことに、次に、この対応するＳＩＰアプリケーションは、関連付けられるメッセージコンテキストに含まれている情報に基づき、受信された各ＳＩＰメッセージに対してパースステップを実行するようになっている。
【００５８】
ＳＩＰアプリケーションレベルで実行される解析をより効率的にするために、パケット前処理レベルにおいて、受信されたＳＩＰメッセージを異なるクラスに分類することが有用であり得る。異なるクラスは、以下のものとすることができる。
−廃棄（Discarded）：たとえば、ネットワークインターフェース上に着信するメッセージがあまりにも多いため、又は、送信元ＩＰアドレスがブラックアドレスリストに属するために、ＳＩＰメッセージを事前パースすることができないことを意味する。
−文法的に無効(Grammatically invalid)：ＳＩＰメッセージが、文法規則のセットに基づいて検出されるシンタックスエラー又は文法エラーを有することを意味する。
−セマンティック的に無効(Semantically invalid)：ＳＩＰメッセージが、セマンティック的に正しくないか又はセマンティック規則のセットに関して欠落しているいくつかの情報を含むことを意味する。
−メッセージ有効（Message valid）：ＳＩＰメッセージが事前パース基準のセットに関して正しいことを意味する。この事前パース基準のセットは、上記文法規則のセット及び／又は上記文法規則のセットに対応することができる。
【００５９】
そのために、前処理ユニット２０２は、事前パース基準のセット、及び／又は文法規則のセット及び／又は上記セマンティック規則のセットにアクセスする。
【００６０】
これらの状況では、本発明の一実施形態によれば、本発明に従って、事前パースされた各ＳＩＰメッセージにクラスが関連付けられる。この関連付けは、事前パースされた各ＳＩＰメッセージについて、決定されたクラスを含むメッセージコンテキストを生成することによって行われる。
【００６１】
したがって、このＳＩＰ前処理は、一実施形態によれば、ＳＩＰアプリケーションに、受信されたＳＩＰメッセージ、及び前処理ユニットレベルで提供されたクラスを示す関連付けられるコンテキストを提供する。
【００６２】
この関連付けられるコンテキストは、ＳＩＰアプリケーションのパースプロセス及び決定プロセスを加速することを可能にする他のいくつかの有用である情報も示すことができる。
【００６３】
例示として、各ＳＩＰアプリケーションは、それぞれのＴＣＰ／ＵＤＰポートにバインド(bind)され、このポート上で着信するＴＣＰ／ＵＤＰデータパケットをリスン(listen)する。
【００６４】
ＳＩＰ前処理モジュール２４の内部では、ＳＩＰソケット２２と呼ばれる１つのＳＩＰ前処理エンティティが、１つの管理されたＴＣＰ接続に専用化されている。しかしながら、単一のＳＩＰユーザアプリケーションを宛先とした着信するすべてのＵＤＰメッセージを処理するのに必要とされるソケットは、１つのみとすることができる。
【００６５】
ＳＩＰソケット２２は、受信されたトラフィックを解析するが、有利に、上位のＳＩＰアプリケーションによって送信されたデータに対してトランスペアレントのままとすることができる。
【００６６】
たとえば、２つのＳＩＰアプリケーションがポート番号５０６０及びポート番号５０６１上でそれぞれ実行されている場合、ポート５０６０及び５０６１で受信されたＵＤＰメッセージを処理するために、２つの別個のＳＩＰソケット２２をそれぞれ割り当てることができる。その後、好ましくは、新しいＴＣＰ接続ごとに新しいＳＩＰアプリケーションを割り当てる。
【００６７】
たとえば、ＰＯＳＩＸ（「ＵＮＩＸ（登録商標）用ポータブルオペレーティングシステムインターフェース(Portable Operating System Interface for UNIX)」を表す）環境では、ＴＣＰ／ＵＤＰソケットと同じ方法で、新しいＳＩＰソケット２２をオープン及びクローズすることができる。
【００６８】
図３は、本発明の一実施形態によるＳＩＰソケット２２を詳細に示している。
【００６９】
ＳＩＰソケット２２は、
−データパケットＦＩＦＯ２０１、並びに
−ＳＩＰ前処理ユニット２０２であって、
−デリニエーション（delineation）ユニット３０６、
−事前廃棄ユニット３０７、
−文法事前パースユニット３０８、
−セマンティック事前パースユニット３０９、及び
−フィルタリングユニット３１０、
を含む、ＳＩＰ前処理ユニット２０２、
を備えることができる。
【００７０】
事前廃棄ユニット３０７は、いくつかの事前廃棄基準に基づいて、いくつかのデータメッセージを早期に廃棄するようになっている。
【００７１】
ＳＩＰシグナリングセッションは、ＴＣＰ／ＩＰスタック２１によって端末２０のＳＩＰポートへ伝達される。データパケットは、このＳＩＰポート上で受信され、ＦＩＦＯ２０１内にキューイングされる。
【００７２】
次に、受信データパケットから、連続したＳＩＰメッセージが、デリニエーションユニット３０６によってデリニエートされる。
【００７３】
理論的には、連続した有効なＳＩＰメッセージが受信されると、前のＳＩＰメッセージの終了及び次のＳＩＰメッセージの開始を見つけることを意味する、これらのＳＩＰメッセージの連続を規定するのに何ら問題はない。確かに、各ＳＩＰメッセージにおいて、コンテンツ長ヘッダは、対応するＳＩＰメッセージの正確なサイズを示す。
【００７４】
しかし、無効なＳＩＰメッセージが受信されると、たとえば、受信されたＳＩＰメッセージのコンテンツ長ヘッダが間違った情報を示しているとき、このＳＩＰメッセージを廃棄することができ、デリニエーションユニットは、新しいＳＩＰメッセージの最初のラインを見つけるまで、データを消費する。ＳＩＰ応答メッセージのこの最初のラインは、たとえば、文字列「SIP/2.0」に基づいて判断することができる。
【００７５】
したがって、ＦＩＦＯ２０１に記憶されているデータパケットは、事前廃棄ユニット３０７に送信されるために、デリニエートユニット３０６の出力で連続したＳＩＰメッセージを通じて示される。確かに、デリニエーションユニット３０６は、各ＳＩＰメッセージを事前廃棄ユニット３０７へ送信する。
【００７６】
この事前廃棄ユニット３０７は、たとえば、ＳＩＰメッセージのフラッディング(flooding)を回避するようになっているか、又は、有害なアドレス若しくは悪意のあるアドレスとして知られている送信元アドレスから到着したＳＩＰメッセージの受信を防止するようになっている。そのため、事前廃棄ユニット３０７は、送信元アドレスのブラックリストにアクセスすることができる。
【００７７】
前処理ユニット２０２でメッセージを廃棄するこのステップによって、受信されたＳＩＰデータメッセージのハンドリングをより効率的にすることができ、いくつかの場合には、廃棄されたＳＩＰデータメッセージに対する他の任意の解析の処理を回避することができる。
【００７８】
事前廃棄ユニット３０７によって「廃棄」として分類されたＳＩＰメッセージは、それ以降のユニットによって解析されず、フィルタリングユニット３１０に直接渡される。関連付けられるコンテキストは、廃棄の理由をさらに示すことができる。
【００７９】
ＳＩＰメッセージに対して廃棄を適用する理由に関して、本発明には、何の制限も付随していない。たとえば、本発明の一実施形態では、事前廃棄ユニット３０７は、単位時間当たりあまりにも多くのＳＩＰメッセージが受信されると、ＳＩＰメッセージをランダムに廃棄するようにすることができる。そのために、しきい値を定義することができ、受信されたＳＩＰメッセージの個数がこのしきい値よりも高いとき、この事前廃棄ユニット３０７は、単位時間当たりしきい値よりも低い個数の受信パケットをハンドリングするために、文法事前パースユニット３０８を通過する前に、いくつかの受信メッセージをランダムに廃棄する。
【００８０】
事前廃棄ユニット３０７は、廃棄されないＳＩＰメッセージを文法事前パースユニット３０８に提供する。
【００８１】
この段階では、文法事前パースユニット３０８は、ＲＦＣ３２６１又はＲＦＣ２３３４で定義されたＳＩＰ ＡＢＮＦ文法のように、ＳＩＰアプリケーションレベル２３で適用される文法規則のセットと比較して、有利に削減することができるＳＩＰ文法規則のセットに基づきＳＩＰメッセージを事前パースすることを担当する。前処理ユニットは、ＳＩＰアプリケーションレベルで実行されるＳＩＰメッセージの解析に取って代わるように設計されていないことを思い起こされたい。
【００８２】
事前パースユニット３０８によって使用されるこのＳＩＰ文法規則のセットは、サポートされるＳＩＰアプリケーション２３のタイプに従って有利に能率化することができる。
【００８３】
この文法事前パースユニット３０８は、事前廃棄ユニット３０７によって提供されたＳＩＰメッセージが文法的に有効であるのか、又は文法的に無効であるのかを判断するようにすることができる。
【００８４】
文法事前パースユニット３０８は、以下で説明するように、ＳＩＰメッセージを処理することができる。
【００８５】
少なくともいくつかのＳＩＰヘッダは、事前にパースすることができる。より正確には、これらのＳＩＰヘッダのいくつかのフィールドを、関連のあるフィールドとして有利に判断することができ、これらの関連のあるフィールドのみを、文法規則のセットに従って、この文法事前パースユニット３０８でチェックする。たとえば、文法規則のセットは、関連のある各フィールドの認可された文字セット及びそれらの最大許容長を定義する。ＳＩＰメッセージは、そのすべての関連のあるフィールドが文法規則のセットを順守している場合に、文法的に有効とみなされる。
【００８６】
次に、ＳＩＰメッセージが文法的に有効として検出された場合、考慮されているＳＩＰメッセージの最初のラインがパースされる。最初のラインを処理することで現在のメッセージがＳＩＰメッセージであるか否かを検出することが可能になるので、ＳＩＰメッセージの最初のラインの処理は、他のラインの処理と有利に異なるものとすることができる。この検出は、最初のラインの「SIP/2.0」文字列の存在に基づいて行うことができる。
【００８７】
その後、最初のラインを処理することによって、メッセージがＳＩＰメッセージとしてチェックされると、このＳＩＰメッセージがＳＩＰ応答であるのか、又はＳＩＰ要求であるのかを意味するＳＩＰメッセージのタイプをチェックすることが可能である。
【００８８】
文法事前パースユニットレベルで行われるチェックは、ＳＩＰメッセージのメソッド名に関するチェックを考慮することができる。したがって、ＳＩＰメッセージにおいてメソッド名を識別することができ、要求ＵＲＩ（「Uniform Resource Identifier：統一資源識別子」を表す）を、最初のライン内で突き止めることができる。これは、オフセット及び長さを求めることができることを意味する。
【００８９】
たとえば、ＳＩＰ応答メッセージの場合、ＲＦＣ３２６１で戻りコード番号として参照されるフィールドを復号する。これは、対応するＡＳＣＩＩコード番号がデジタル値に変換されることを意味する。リーズンフレーズ（reason phrase：理由語句）（フィールド）のＡＳＣＩＩ文字列の開始のオフセットが返される。
【００９０】
最初のラインを処理した後、文法事前パースユニット３０８は、ＳＩＰメッセージの他のラインを処理するようになっている。これら他のラインはヘッダラインである。
【００９１】
一般に、各ヘッダラインは、ヘッダ名（Header Name）で始まり、ヘッダ名の後には、ＲＦＣ３２６１で定義されたＨＣＯＬＯＮ文法規則（最終的にはスペース又は表(tabulations)で囲まれる「：」）が続き、ラインの残りの部分はヘッダ値を含む。空のラインは、ヘッダの終端を示すことができる。
【００９２】
文法事前パースユニット３０８は、ＳＩＰメッセージのヘッダ名を突き止めて識別するようにすることができる。その結果、文法事前パースユニット３０８は、対応するオフセット及び長さで、ヘッダフィールドのロケーションを提供することができる。このオフセット及びこの長さが、共に予想通りであるか否かをチェックすることが可能である。
【００９３】
加えて、この文法事前パースユニット３０８は、考慮されているフィールドで使用される文字が、可能な文字(possible characters)の所定のセットに属するか否かをチェックすることもできる。たとえば、「コンテンツ長」ヘッダに使用される文字が以下の数字セット、すなわち、
（０；１；２；３；４；５；６；７；８；９）
に属することを設計することができる。
【００９４】
次に、文法事前パースユニット３０８は、ヘッダ名の所定のセットのみを解析することができる。そのために、ＳＩＰメッセージにおいて、このセットに属するヘッダ名のみについて、ヘッダ値を抽出する。このヘッダ名のセットは、ＳＩＰメッセージの本体サイズをチェックすることができるようにするために、少なくとも「コンテンツ長（Content-Length）」ヘッダを有利に含むことができる。
【００９５】
ヘッダ値は、たとえば、デジタル値に変換することができ、ＳＩＰメッセージに関連付けられるメッセージコンテキスト内にコピーすることができる。
【００９６】
また、ヘッダ名のセットは、応答メッセージのメソッド名をチェックすることができるようにするために、「CSeq」ヘッダを意味するＳＩＰメソッド名に対応するヘッダも含むことができる。
【００９７】
他のヘッダは、本発明の一実施形態に従ってＳＩＰ前処理が実行されるＳＩＰアプリケーションの必要性に応じて、具体的にパースすることができる。たとえば、ＲＦＣ３２６１の「ｗｗｗ認証（www-authenticate）」ヘッダとして参照されるフィールド内にアナウンスされた値を得ることは、いくつかのＳＩＰアプリケーションにとって有用であり得る。
【００９８】
文法事前パースユニット３０８はさらに、ＳＩＰメッセージの本体サイズをチェックするようにすることができる。理論的には、メッセージ本体サイズは、対応するヘッダのコンテンツ長フィールドにたとえばバイト数で公示されたサイズに対応するはずである。
【００９９】
ＴＣＰのようなレイヤ４トランスポートプロトコルが使用されるとき、コンテンツ長ヘッダフィールドは、すべてのＳＩＰ要求メッセージ及びＳＩＰ応答メッセージに存在するはずである。この情報が提供されない場合、端末は、ＴＣＰ接続がクローズされるまで、メッセージ本体が続くものと仮定することができ、メッセージ本体をエラーのあるＳＩＰメッセージとみなすことができる。
【０１００】
レイヤ４プロトコルがＵＤＰプロトコルである場合、この情報は、提供されない場合がある。この後者の場合、メッセージの本体は、ＳＩＰヘッダの後のデータメッセージの残りの部分を占有するはずである。本体がないとき、コンテンツ長は０に等しい。
【０１０１】
エラーがこの段階で検出された場合、メッセージは、「セマンティック的に無効」として分類される。これは、フレーミングエラーであり、現在のメッセージを破棄することができる。
【０１０２】
文法事前パースユニット３０８によって処理されたＳＩＰメッセージは、次に、追加のチェック及び処理（たとえば変換）を行うため、又は、ＳＩＰメッセージに関連付けられるメッセージコンテキスト構造体を満たすために、セマンティック処理ユニット３０９に提供される。この段階の出力として、メッセージは、セマンティック的に有効又は無効として分類される。
【０１０３】
セマンティック処理ユニット３０９は、ＳＩＰメッセージに対応するメソッド名を識別するようになっている。メソッド名は、上述したように、ＳＩＰ要求メッセージについては最初のラインにおいて、又は、ＳＩＰ応答メッセージについてはCSeqヘッダにおいて、文法事前パースユニット３０８によって突き止められる。このメソッド名は、次に、既知のメソッド名の定義されたセット内で識別され、対応するメソッド識別子MethodIDが求められる。
【０１０４】
既知のメソッド名のセットは有限であり、ＳＩＰアプリケーションによって定義することができる。未知のメソッド名がＳＩＰメッセージにおいて識別されたとき、そのＳＩＰメッセージは、セマンティック的に無効として分類される。
【０１０５】
たとえば、この既知のメソッド名のリストは、以下のものとすることができる。
【０１０６】
【表１】
【０１０７】
MethodIDの値は、メッセージのタイプ（要求又は応答）に依存することに気付くことができる。
【０１０８】
ヘッダ名は、ヘッダ名の定義されたセット内で識別することもできる。次に、ヘッダ名識別子HeaderIDを求めることができ、関連付けられるメッセージコンテキスト内に挿入することができる。単一のHeaderIDについて、いくつかのエイリアスを定義することができる。未知のヘッダを有するＳＩＰメッセージは、セマンティック的に無効として分類される。
【０１０９】
既知のヘッダのセットは有限であり、ＳＩＰアプリケーションによって定義することができる。
【０１１０】
たとえば、このヘッダ名のセットは、以下のものとすることができる。
【０１１１】
【表２】
【０１１２】
メソッド識別子MethodIDに従って、いくつかのヘッダは、ＳＩＰメッセージにおいて一意とすることができる。一意のヘッダ名のリストを、メソッド名のセットの各メソッド名について、ＳＩＰアプリケーションが定義することができる。
【０１１３】
複製されたヘッダを有するＳＩＰメッセージを、セマンティック的に無効として分類することができる。
【０１１４】
セマンティック処理ユニット３０９はさらに、ヘッダパラメータ長をチェックし、次いで各ヘッダパラメータの長さがＳＩＰアプリケーションによって定義することができる範囲内に含まれるか否かを判断するようにすることができる。
【０１１５】
セマンティック処理ユニット３０９はさらに、ヘッダ名をカウントすると共に、それらの発生回数をチェックするようにすることができる。そのために、各ヘッダ名の発生がカウントされる。各ヘッダの発生総数は、通常、各MethodIDについてＳＩＰアプリケーションが定義することができる所与の範囲内に含まれ得る。発生回数がこの所与の範囲外である場合、メッセージを「セマンティック的に無効」として分類することができる。
【０１１６】
【表３】
【０１１７】
最後に、ＳＩＰメッセージを、セマンティック処理ユニット３０９によって処理した後、セマンティック的に有効であるか又はセマンティック的に無効であるかのいずれかのステータスに関連付ける。その後、このＳＩＰメッセージが、フィルタリングユニット３１０に送信される。
【０１１８】
フィルタリングレベルでは、ＳＩＰメッセージを廃棄するか、又は、その関連付けられるメッセージコンテキストと共に対応するＳＩＰアプリケーション２３へＳＩＰメッセージを送信することができる。
【０１１９】
このフィルタリングユニット３１０は、廃棄マスクを有利に適用することができる。これは、このフィルタリングユニット３１０が、このＳＩＰメッセージに関連付けられるメッセージコンテキストにおいて示されたクラスに従ってＳＩＰメッセージを廃棄することができることを意味する。
【０１２０】
フィルタリングユニット３１０は、データパケットＦＩＦＯのキューイング解除をさらに担当することができる。
【０１２１】
以下の表は、フィルタリングマスクパラメータを説明している。
【０１２２】
【表４】
【０１２３】
たとえば、パラメータ「Filtering_mask（フィルタリングマスク）」が０１００に設定されているとき、このパラメータは、「文法的に無効」として分類されたメッセージのみがフィルタリングユニットによって廃棄されることを指定する。他のすべてのメッセージクラスは、さらなる解析のために維持される。
【０１２４】
本発明の一実施形態では、使用することができるプリミティブのセットを通じてコマンドインターフェースを介してＳＩＰソケット２２をロード及び構成することができる。これらのプリミティブは、「open（オープン）」、「bind（バインド）」、「listen（リスン）」、「accept（受理）」、「write（書き込み）」、「read（読み出し）」のような、ＰＯＳＩＸ環境で定義された標準的なソケットプリミティブと同様のものとすることができる。
【０１２５】
以下のセクションは、入力として受信された、一実施形態によるＳＩＰソケット２２の構成を説明する。
【０１２６】
ＳＩＰソケットをバインドするために、ＴＣＰ／ＵＤＰポートは、ＴＣＰパケット又はＵＤＰパケットの受信用に予約される。ＴＣＰの場合、このポートは、着信する新しいＴＣＰ接続をリスンするのに使用することができる。
【０１２７】
以下のパラメータを設定することができる。すなわち、
−プロトコル（ＵＤＰ又はＴＣＰ）、
−ローカルポート番号（たとえば５０６０）、
−ＳＩＰメソッド名のリスト、
−各ＳＩＰメソッド名について、
○要求及び応答のような有効なヘッダ名のリスト、
○各ヘッダ名について、
・最小発生回数及び最大発生回数、並びに
・パラメータの最小長及び最大長、
−認証されていない送信元ＩＰアドレスのリスト
−メッセージの分類による廃棄マスク
を設定することができる。
【０１２８】
以下のセクションは、特に、ＳＩＰメッセージ前処理中に生成されるメッセージコンテキストのコンテンツを詳しく述べることによって、一実施形態によるＳＩＰソケットの出力を説明する。
【０１２９】
メッセージコンテキストは、メッセージの前処理中に生成される３つのタイプの報告を含むことができる。すなわち、
−「メソッド説明報告」を示す最初のライン報告、
−連続した各ヘッダラインの複数のヘッダライン報告、及び
−メッセージが全体的に処理されたときに生成される最終報告、
を含むことができる。
【０１３０】
ＳＩＰメッセージのメッセージコンテキストに含まれるグローバル報告に対応するように、異なる報告を連結することができる。
【０１３１】
たとえば、ＳＩＰメッセージがＳＩＰメッセージの最初のラインからエラーのあるメッセージとして識別された場合、最終報告のみを書き込むことができる。
【０１３２】
そのために、フィールド「Report_type（報告タイプ）」は、報告タイプを符号化することができる。このフィールドは、
−method_report（メソッド報告）、
−header_report（ヘッダ報告）、及び
−final_report（最終報告）
に設定することができる。
【０１３３】
一実施形態によるＳＩＰメッセージに関連付けられるメッセージコンテキストに含まれる異なる報告をデリニエートするためには、異なる方法がある。たとえば、すべての報告について固定サイズを決定することも可能であるし、任意の記号又は空白によってすべての報告を分離することも可能であるし、リンクリストとして報告を管理することも可能である。
【０１３４】
この報告のコンテンツは、メッセージがＳＩＰ要求メッセージとして識別されるのか、又はＳＩＰ応答メッセージとして識別されるのかに依存し得る。
【０１３５】
メッセージが、ＳＩＰ要求メッセージとして識別される場合、報告は、以下の情報、すなわち、
○method_reportに対応するReport_type（報告タイプ）、
○要求又はMethodID又はRequestURI_Idx（要求ＵＲＩインデックス）又はURI_Length（ＵＲＩ長）又はLine_Length（ライン長）に対応するMsg_type（メッセージタイプ）、
を含むことができる。
【０１３６】
たとえば、データ「INVITE sip:bob@192.0.2.4 SIP/2.0 <CR><LF>」を含むＳＩＰメッセージは、以下の情報、すなわち、
Msg_type = 要求、
MethodID = INVITE、
RequestURI_ldx =7、
URI_Length = 17、
Line_Length = 34（ライン終端セパレータのとき）
を含む報告に関連付けられる。
【０１３７】
そうではなく、ＳＩＰメッセージがＳＩＰ応答メッセージとして識別される場合、関連付けられる報告は、以下の情報、すなわち、
○Report_type = method_report、
○Msg_type = 応答／MethodID／CodeID（コードＩＤ）／ReasonPhrase_Idx（リーズンフレーズインデックス）／Line_Length
を含む。
【０１３８】
たとえば、ＳＩＰメッセージ「SIP/2.0 200 OK」は、以下の情報、すなわち、
Msg_type = 応答、
CodeID = 200、
ReasonPhrase_Idx = 12、
Line_Length = 16（ライン終端セパレータがカウントされたとき）
を含む報告に関連付けられる。
【０１３９】
以下の情報を、ヘッダ報告の各ライン（最初のラインを除く）に含めることができる。
○Report_type = header_report
○HeaderID／HeaderValue_Idx（ヘッダ値インデックス）／LineLen（リスン長）／HeaderValueLen（ヘッダ値長）。
【０１４０】
一実施形態では、メッセージコンテキストには１つの最終報告のみがある。この最終報告は、対応するＳＩＰメッセージの前処理の要約を含む。
【０１４１】
この最終報告において、以下の情報が提供される。すなわち、
−Report_type = final_report（最終報告）
−MsgStatus（メッセージステータス）：廃棄又は文法的に無効又はセマンティック的に無効又はメッセージ有効
−Content-Length値（コンテンツ長値）
−他の値（指定された場合）：たとえばCSeq
が提供される。
【０１４２】
ＳＩＰ前処理モジュール２４は、ソフトウェアモジュールで実施することもできるし、ハードウェアモジュールで実施することもできる。
【０１４３】
図４は、ハードウェア端末におけるＳＩＰ前処理モジュール２４の使用を示している。
【０１４４】
ネットワークプロセッサ４１は、レイヤ４までのプロトコルスタック２１をハンドリングする。このネットワークプロセッサモジュール２１は、イーサネット（登録商標）ＭＡＣインターフェースに直接接続することができる。
【０１４５】
アプリケーションプロセッサ４３は、オペレーティングシステムのもとで、そのネットワークスタックハンドリングがネットワークプロセッサにおいてオフロードされた状態で、アプリケーション２３を実行するようにすることができる。
【０１４６】
予約されたポート（たとえば、ポート５０６０上でバインドされたソケット）で受信されたデータパケットは、ＳＩＰソケット＃１へ送信される。予約されたポート（たとえば、ポート５０６１上でバインドされたソケット）で受信されたデータパケットは、ＳＩＰソケット＃２へ送信される。データパケットの残りは、アプリケーションプロセッサによって直接ハンドリングされる。
【０１４７】
ＳＩＰ前処理モジュールは、たとえば、パースする特定のフィールド、過負荷検出用の最大しきい値等に関して、アプリケーションプロセッサによって有利に構成され得る。
【０１４８】
一実施形態に従ってＳＩＰメッセージを前処理した後、ＳＩＰメッセージが有効である場合には、ＳＩＰメッセージは、アプリケーションプロセッサ４３に渡される。有利なことに、アプリケーションは、その後、そのレベルで必要とされる場合に、関連付けられるメッセージコンテキストを利用し、他のすべてのパースタスク及びメッセージ解釈タスクを行う。ＳＩＰメッセージが有効でない場合には、上述したように、ＳＩＰメッセージは、フィルタリングレベルで、廃棄マスクの分類に従って破棄され得る。この最後の場合に、一実施形態では、より短いメッセージコンテキストのみが、アプリケーションプロセッサ４３へ転送される。
【０１４９】
ネットワークプロセッサ４１からアプリケーションプロセッサ４３への送信パスは、任意のタイプのトラフィックを送信するようにすることができる。アプリケーションプロセッサ４３からネットワークプロセッサ４１へいくつかの情報を送信するのに、別のパスを使用することができる。
【０１５０】
この種の前処理では、メッセージを連続して処理することができる。好ましくは、従来のソフトウェアパースのようにバックトラッキングをハンドリングする必要がないので、各文字は１回だけ読み出される。
【０１５１】
同じ入力シンボルを使用するいくつかの状態マシンを並列に評価することができる。たとえば、文字列終端セパレータが検索されている間、文字列マッチャ（string matcher）が評価され、セパレータが見つかったときに文字列マッチャの結果が検討される。
【０１５２】
いくつかの「ルックアヘッド（look-ahead）」機能を実施するために、事前にいくつかの文字を読み出すことも有用であり得る。解析する次のいくつかの文字を知ることによって、これは、ラインシーケンスの終端を決定したり、ヘッダの終端を識別したりするのに有用である。読み出された文字を、或る深さのシフトレジスタにプッシュし、必要とされるルックアヘッドが提供される。
【０１５３】
文字列マッチング機能は、メソッドの識別又は異なる可能なヘッダの識別を行うために実行することができる。このコンテキストでは、たとえば、既知の「Aho-corasick」複数文字列マッチングアルゴリズムを使用することができる。決定性有限オートマトン(Deterministic Finite Automata)（ＤＦＡ）をこのアルゴリズムで生成することができ、各オートマトンは、認識された文字列に対応するＤＦＡの状態を受理する。
【０１５４】
ＳＩＰ文法は、大文字であるMETHODの符号化を除いて、通常、文字について大文字と小文字とを区別しない。Aho Corasick ＤＦＡに記憶されている文字列は、大文字に正規化される。入力ストリームは、文字列マッチャに提示される前に、大文字に正規化される。通常のストリームは、チェックを可能にするように保存することができる。
【０１５５】
特定の機能又は特定の機能のセットを使用して、特定のフィールドで用いられる文字が許容されるか否かをチェックすることができる。これは、入力アルファベットの各可能な値について異なるセットの機能（文字セット）の事前に計算された値を含むルックアップテーブルを使用して実施することができる。小さなメモリを使用して非常に効率的且つコンパクトなルックアップテーブルを実施することが可能である。
【０１５６】
以下のパラグラフは、ハードウェアで実施することができるような事前パースの主要なステップを示している。
【０１５７】
メッセージの最初のラインの処理は、他のラインの処理とは異なっている。その処理は、非常に単純であり、メッセージが要求メッセージであるのか、又は応答メッセージであるのかを非常に容易に識別することを可能にする。最初のワードが解析されて、そのワードが既知のメソッドであるのか、又は文字列「SIP/2.0」であるのかがチェックされる。この文字列が見つかった場合、メッセージは、応答であると仮定され、そうでない場合、メッセージは要求であると仮定される。
【０１５８】
METHOD又はSIP/2.0の文字列の識別は、Aho-Corasick ＤＦＡを使用することによって行うことができる。
【０１５９】
ラインセパレータが見つかったときを意味する最初のラインの処理の終わりに、メソッドの説明を生成することができる。
【０１６０】
後続のラインの前処理は、各ラインがHeaderIDで始まり、その後にHCOLON（最終的にはスペース又はＨＴＡＢによって囲まれる「：」）が続くことに基づくことができる。ラインの残りの部分は、パラメータを含むことができる。
【０１６１】
後続のラインの各最初のワードは、Aho-Corasick等の複数文字列マッチングアルゴリズムによって識別することができる。セパレータが検出されると、文字列マッチャの結果を評価して、ヘッダ名が認識されるか否かがチェックされる。
【０１６２】
各ラインの解析の終わりに、≪ヘッダ報告≫を生成する。処理は、空白ライン、すなわちシーケンスCR LF CR LFを識別することによって「ヘッダ終端（end of header）」が検出されると、終了する。
【０１６３】
その後、最終報告を生成する。
【０１６４】
このメカニズムは、ＳＩＰシグナリングプロトコルに基づく住宅ゲートウェイ又はビジネスゲートウェイ及びいわゆるＩＰ電話等の端末機器で有利に実施することができる。このメカニズムは、ＳＩＰアプリケーションまでＳＩＰシグナリングチャネルを通じて注入される可能性のある無用なデータ処理のための過剰な量の処理資源の先取りを防止する。
【技術分野】
【０００１】
本発明は、包括的には、ＳＩＰプロトコル（「セッション開始プロトコル」を表す）又はＨＴＴＰプロトコル（「ハイパーテキスト転送プロトコル」を表す）又はＳＭＴＰプロトコル（「シンプルメール転送プロトコル」を表す）のようなテキストベースプロトコルに関し、より詳細には、このタイプのプロトコルに基づくアプリケーションを使用する端末の保護に関する。
【背景技術】
【０００２】
いくつかのテキストベースのプロトコルは、多くのネットワークで使用される。ＩＥＴＦ（「インターネットエンジニアリングタスクフォース」を表す）によって標準化されたプロトコルＳＩＰがこれに該当する。このテキストベースのプロトコルは、特に、アプリケーションＶｏＩＰ（「ボイスオーバインターネットプロトコル」を表す）に使用される。
【０００３】
このようなテキストベースのプロトコルは、高水準プログラミング言語のように、文法規則セットによって定義されたシンタックスを有する。その結果、ＳＩＰメッセージの復号は、複雑なタスクとなる可能性があり、このような復号オペレーションを担当するエンティティは、大量のメモリ及び計算資源を有する。
【０００４】
図１は、ＳＩＰメッセージ１４がＴＣＰ（「転送制御プロトコル」を表す）レイヤ又はＵＤＰ（「ユーザデータグラムプロトコル」を表す）レイヤを通じて送信される従来のアーキテクチャにおけるＳＩＰメッセージの処理を示している。メッセージＳＩＰ１４が、ＴＣＰ／ＵＤＰスタック１１を通じて端末のＵＤＰポート又はＴＣＰポート上で受信されると、メッセージＳＩＰ１４はＳＩＰパーサ１２によって解析される。このパーサは、このＳＩＰメッセージのシンタックスをチェックし、対応するＳＩＰアプリケーション１３に適合するＳＩＰ構造体１５を生成する。
【０００５】
この処理中、受信されたＳＩＰメッセージは、２回チェックされる。最初はＳＩＰパーサ１２のレベルでチェックされ、後にＳＩＰアプリケーション１３のレベルでチェックされる。一般に、ＳＩＰパーサ又はＳＩＰアプリケーションによってＳＩＰメッセージにエラーが検出されると、そのＳＩＰメッセージは廃棄される。
【０００６】
ＳＩＰパーサ１２において実行されるチェックのステップは、複雑であり、多くの時間を費やす。確かに、ＳＩＰメッセージの廃棄を決定する前に、ＳＩＰパーサは、このメッセージをかなり完全にパース(構文解析)する必要がある。その結果、処理電力は、不必要に消費される可能性がある。
【０００７】
加えて、一般に、端末は、フォームファクタ又はコストのようなさまざまな理由によって処理資源を制限される可能性があり、そのため、処理資源は通常の動作状態に適合するように決定される。その結果、このような端末が、たとえば、ＳＩＰパーサレベルにおける多くのチェックタスクが原因で異常な動作状態で動作すると、端末は、この場合に十分な処理資源を有しないので、その基本タスクを正しく実行することができない。
【０００８】
したがって、多くのＳＩＰメッセージをいくつかの端末へ送信することは、このプロトコルに基づくネットワークサービスに対する効率的な攻撃になる可能性がある。特に、ＳＩＰメッセージを処理するいくつかのソフトウェア機能は、端末があらゆる通常のオペレーションを実行することを妨げる効率的な攻撃のターゲットになる可能性がある。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明は、端末上で実行されるテキストベースのプロトコルに基づくアプリケーションのロバスト性及び性能を向上させることを目的とする。
【００１０】
上記に鑑み、性能、及び攻撃に対する保護を増大させることができる、テキストベースのプロトコルに従って受信されたデータメッセージをハンドリングする方法を強化する必要性がある。
【課題を解決するための手段】
【００１１】
本発明の第１の態様は、端末においてテキストベースのプロトコルに従って受信データメッセージをハンドリングする方法を提案し、
当該方法は、以下のステップ、すなわち、
／１／事前パース（pre parcing）基準のセットに従って、上記受信データメッセージを事前パースするステップと、
／２／データメッセージに関連付けられるメッセージコンテキストを生成するステップであって、上記メッセージコンテキストは、事前パースするステップから取得された情報を示す、生成するステップと、
／３／データメッセージ及び上記関連付けられるメッセージコンテキストを端末上で実行されているアプリケーションに提供するステップと、
を含む。
【００１２】
端末上で実行されるアプリケーションに、受信データメッセージに関連したメッセージコンテキストを提供することによって、アプリケーションレベルで当該データメッセージに対して行われる解析の上流側で、受信メッセージに対してチェックを行ういくつかのステップを実行することが可能である。したがって、いくつかのチェックステップを先取りして、アプリケーションレベルでデータメッセージをチェックすることに起因する負荷を削減すると共に、端末レベルでの受信データメッセージのチェックを最適化することが可能である。
【００１３】
これらの状況では、多くのデータメッセージを送信して対応するアプリケーションを過負荷にすることに基づくいくつかの攻撃を防止することができる。ＳＩＰアプリケーションに対してこのような方法を実行することは、特に有利となり得る。
【００１４】
一実施の形態では、事前パース基準のセットは、文法規則のセット(a set of grammatical rules)及び／又はセマンティック規則のセット(a set of semantic rules)を含む。
【００１５】
文法規則のセットは、解析されたテキストベースのプロトコルに従って有利に定めることができ、いくつかの決定された関連のあるフィールドに対する部分解析に対応することができる。
【００１６】
いくつかの決定された関連のあるフィールドは、完全な文法解析によって提供されるロバスト性とハンドリングの効率性との間の良好な妥協を有するように選択することができる。
【００１７】
ＳＩＰプロトコルの場合、このセットは、対応するＩＥＴＦ ＲＦＣ３２６１で定義されたＡＢＮＦ文法（「拡張バックス・ナウア記法（Augmented Backus-Naur form）」を表す）に基づくことができ、効率性及びロバスト性を向上させるために簡単化することができる。
【００１８】
セマンティック規則のセットは、いくつかの決定された関連のあるフィールドの有効性をチェックする部分解析に対応することができる。
【００１９】
この規則のセットは、効率性とロバスト性との間の妥協を可能にすることができる。この部分解析は、たとえば、関連のあるフィールドのうちの１つのコンテンツをチェックすることに対応することができ、且つデータメッセージのこのようなフィールドの長さをチェックすることに対応することができる。
【００２０】
事前パースするステップにおいて、データメッセージを、以下のクラス、すなわち、
文法規則のセットに基づき文法的に無効（grammatically invalid）、又は
セマンティック規則のセットに基づきセマンティック的に無効（semantically invalid）、又は
事前パース基準に関して有効、
のうちの１つに有利に分類することができ、関連付けられるメッセージコンテキストは上記クラスを示すことができる。
【００２１】
この情報は、データメッセージ及びそれに関連付けられるメッセージコンテキストを受信する対応するアプリケーションにとって非常に有用であることができる。
【００２２】
事前パースするステップの前に、事前廃棄ステップを有利に実行することができる。当該事前廃棄ステップは、メッセージが、事前廃棄基準のセットに基づいて廃棄されるものとみなされるか否かを判断することを担当する。このような事前廃棄基準は、たとえば、受信メッセージのスループットのしきい値に基づくことができる。
【００２３】
本発明の一実施の形態では、事前廃棄として分類されるデータメッセージは、前処理の他のステップを通じて処理されない。
【００２４】
受信データメッセージがデータパケットで受信されるとき、ステップ／１／の前に、連続したデータメッセージを受信データパケットからデリニエート(delineating)するステップを有利に実行することができる。このステップは、使用されるトランスポートプロトコルがＴＣＰプロトコルであるときに有用であることができる。
【００２５】
データメッセージ及び関連付けられるメッセージコンテキストをアプリケーションに提供するステップの前に、事前パースステップの結果に基づいて上記データメッセージをフィルタリングするステップをさらに実行することができる。
【００２６】
テキストベースのプロトコルは、ＳＩＰプロトコル、ＨＴＴＰプロトコル、及びＳＭＴＰプロトコル等の、ＩＥＴＦによって定義されたプロトコルのうちの１つとすることができる。
【００２７】
メッセージコンテキストは、事前パースステップ中に満たす(fill)ことができる。
【００２８】
本発明の第２の態様は、端末においてテキストベースプロトコルに従って受信データメッセージをハンドリングするようになっている前処理モジュールを提案し、
当該前処理モジュールは、以下のユニットから成るセット、すなわち、
−事前パース基準のセットに従って、上記受信データメッセージを事前パースするようになっている事前パースユニットと、
−上記データメッセージに関連付けられるメッセージコンテキストを生成するようになっている生成ユニットであって、当該メッセージコンテキストは、事前パースユニットから取得された情報を示す、生成ユニットと、
−上記データメッセージ及び上記関連付けられるメッセージコンテキストを端末上で実行されるアプリケーションに提供するようになっているフィルタリングユニットと、
から成るセットを備える。
【００２９】
この前処理モジュールは、端末レベルでハンドリングされる接続ごとに１つのユニットのセットを備えることができる。
【００３０】
この前処理モジュールは、ユニットのセットから少なくとも１つのユニットに関する構成情報を受信するようになっている構成インターフェースをさらに備えることができる。
【００３１】
このような前処理モジュールは、オフロードモジュールとすることができる。これは、前処理をメインプロセッサとは別のプロセッサが実行することができることを意味する。
【００３２】
本発明の第３の態様は、本発明の第２の態様による前処理モジュールを備える端末を提案する。
【００３３】
本発明のさらなる特徴及び利点は、以下の説明からより明らかになるであろう。以下の説明は、単に例示として与えられ、添付図面と共に読まれるべきである。
【図面の簡単な説明】
【００３４】
【図１】従来技術によるＳＩＰメッセージハンドリングのアーキテクチャの図である。
【図２】本発明の一実施形態による端末のアーキテクチャにおける、受信されたＳＩＰメッセージの処理を示す図である。
【図３】本発明の一実施形態によるＳＩＰソケットを詳細に示す図である。
【図４】ハードウェア端末のＳＩＰ前処理モジュールの使用を示す図である。
【発明を実施するための形態】
【００３５】
本発明は、以下の本明細書において、ＳＩＰプロトコルに対する一例示の適用で説明される。しかし、同じ原理を他の任意のテキストベースのプロトコルに適用することは容易である。
【００３６】
ＳＩＰプロトコルのパースは、特に組み込み環境で、ＣＰＵ及びメモリ資源を必要とする特に複雑なタスクである。これは、ＳＩＰプロトコルが受信側で多くの制御を伴う複雑な記述言語に基づいているからである。
【００３７】
本発明の一実施形態は、端末側で実行されるＳＩＰアプリケーションによって行われるパース及びチェックのタスクを容易にすることを可能にする。そのために、本発明の一実施形態では、受信されたＳＩＰシグナリングメッセージ内部の主要なアイテムを発見及びチェックするために、前処理が行われる。
【００３８】
このような前処理は、いくつかの場合にはＳＩＰメッセージを廃棄可能にするために、又は、ＳＩＰアプリケーションレベルのチェック段階に有用であるいくつかの情報を取り出すために、いくつかの主要なアイテムのみをチェックすることによって、受信されたＳＩＰメッセージを高速且つ効率的にチェックすることを可能にする。そのために、いくつかの情報が、本発明に従い、関連付けられるメッセージコンテキストにおいて、ＳＩＰアプリケーションに提供されるＳＩＰメッセージに関連付けられる。
【００３９】
したがって、このような前処理を行うことによって、ＳＩＰアプリケーションに情報を通知することができ、それによってアプリケーションレベルで行われるチェックステップが容易になる。
【００４０】
この前処理は、ＳＩＰアプリケーションによって行われるパースに取って代わるものではない。しかしながら、前処理は、アプリケーションレベルで実行されるパースの効率性を向上させるために、受信された各ＳＩＰメッセージについて、ＳＩＰアプリケーションに有用である情報を含む関連付けられるメッセージコンテキストを提供する。その上、この前処理は、たとえばエラーのあるＳＩＰメッセージに起因する過負荷を防止することによって、ＳＩＰアプリケーションのロバスト性を有利に高めることができる。
【００４１】
このようなメッセージコンテキストは、その関連付けられるメッセージコンテキストに含まれる情報に基づいて前処理によって無効とみなされたＳＩＰメッセージを廃棄するために、又は、ＳＩＰメッセージ全体をパースすることなくＳＩＰメッセージによって伝達された幾つかの特定の情報に直接アクセスするために、ＳＩＰアプリケーションレベルで有利に使用することができる。なお、このような特定の情報は、関連付けられるメッセージコンテキスト上に示されている。
【００４２】
その結果、このメッセージコンテキストは、いくつかのＳＩＰメッセージの廃棄を提案すること、又は、ＳＩＰアプリケーションレベルでパースするのに有用であるいくつかの情報を示すことのいずれかによって、ＳＩＰアプリケーションの負荷を低減することを可能にする。
【００４３】
これらの状況では、ＳＩＰプロトコルを実施する端末においてＳＩＰシグナリングチャネルの悪用の影響を低減又は防止することが可能である。
【００４４】
一実施形態では、ＳＩＰシグナリングチャネルの悪用は、以下のように定義することができる。すなわち、
−非ＳＩＰデータパケットをＳＩＰシグナリングチャネルによって送信すること、
−エラーのあるＳＩＰメッセージをＳＩＰシグナリングチャネルによって送信すること、又は
−適合していないレートでＳＩＰシグナリングチャネルによってデータパケットを送信すること、
と定義することができる。
【００４５】
本発明の一実施形態では、ＳＩＰアプリケーションは、ＳＩＰメッセージに関連して提供されたメッセージコンテキストに含まれる情報を正しく且つ効率的に利用するように設計される。しかしながら、たとえ前処理が本発明に従って実行されても、既存のＳＩＰアプリケーションを実行することができる。
【００４６】
本発明によるＳＩＰ前処理の技術的な実施には、何の制限も付随していない。たとえば、ＳＩＰ前処理は、ＳＩＰアプリケーションレベルで実行されるＳＩＰ処理ステップの上流側で、ソフトウェアモジュール又はハードウェアモジュールのいずれとしてでも端末機器において実施することができる。
【００４７】
図２は、本発明の一実施形態による端末のアーキテクチャにおける受信されたＳＩＰメッセージの処理を示している。
【００４８】
ＳＩＰシグナリングセッションは、発呼側端末と着呼側端末との間に確立することができる。発呼側端末は、呼セッション要求を着呼側端末へ送信することによって呼セッションを開始することができる。
【００４９】
このようなＳＩＰシグナリングセッションは、ＵＤＰプロトコル又はＴＣＰプロトコルに対応することができるレイヤ４フローの上に確立することができる。この場合、ＳＩＰシグナリングセッションは、
−発呼側端末及び着呼側端末のそれぞれのＩＰアドレス、
−発呼側端末によって選択された所与の送信元ポート番号、及び
−ＲＦＣ３２６１（「コメント要求(Request For Comments)」を表す）で定義された５０６０のような標準値とすることができる宛先ポート番号、
によって一意に識別される。
【００５０】
使用されるレイヤ４プロトコルがＴＣＰプロトコルであるとき、ＴＣＰ接続は、ＳＩＰシグナリングセッションの確立よりも前に発呼側端末と着呼側端末との間に確立され、このＳＩＰシグナリングセッションの終了後に切断される。
【００５１】
その場合、ＴＣＰ接続の一方向によって送信されたＳＩＰメッセージは、たとえば、各ＳＩＰメッセージヘッダの特定のフィールドに示されたコンテンツ長の表示、ＳＩＰ要求メッセージのメソッド名の表示、又はＳＩＰ応答メッセージのステータスライン上の表示のような、ＳＩＰメッセージ内に設けられた情報を使用することによって区切られる。
【００５２】
使用されるレイヤ４プロトコルがＵＤＰプロトコルであるとき、各ＳＩＰメッセージは、単に、単一のＵＤＰデータグラムにカプセル化される。ＳＩＰメッセージの区切りは、この場合、ＵＤＰによって暗黙的に行われる。
【００５３】
本発明の一実施形態では、前処理が、特定の宛先ポートのセットのレイヤ４フローによって受信されたデータパケットに適用される。
【００５４】
例示として、図２において、端末２０は、
−データパケットが受信されるネットワークとのインターフェースであるようになっているプロトコルスタック２１（ＴＣＰ／ＩＰスタック）、
−ＳＩＰソケット２２と呼ばれる複数の前処理エンティティを含むＳＩＰ前処理モジュール２４、並びに
−第１及び第２のＳＩＰアプリケーション２３、
を備える。
【００５５】
図示されたケースでは、ソケット＃１、ソケット＃２、及びソケット＃３の３つの異なるＳＩＰソケットが、本発明の一実施形態に従って端末レベルで管理される。
【００５６】
これらのＳＩＰソケット２２のそれぞれの内部では、最初にデータパケットがデータパケットＦＩＦＯ２０１で受信される。次に、受信されたデータパケットは、前処理ユニット２０２で処理される。この前処理ユニット２０２の出力では、受信された各データメッセージについて、メッセージコンテキストが生成される。データメッセージ及びその関連付けられるメッセージコンテキストは、ＳＩＰアプリケーションレベル２３へ送信される。
【００５７】
有利なことに、次に、この対応するＳＩＰアプリケーションは、関連付けられるメッセージコンテキストに含まれている情報に基づき、受信された各ＳＩＰメッセージに対してパースステップを実行するようになっている。
【００５８】
ＳＩＰアプリケーションレベルで実行される解析をより効率的にするために、パケット前処理レベルにおいて、受信されたＳＩＰメッセージを異なるクラスに分類することが有用であり得る。異なるクラスは、以下のものとすることができる。
−廃棄（Discarded）：たとえば、ネットワークインターフェース上に着信するメッセージがあまりにも多いため、又は、送信元ＩＰアドレスがブラックアドレスリストに属するために、ＳＩＰメッセージを事前パースすることができないことを意味する。
−文法的に無効(Grammatically invalid)：ＳＩＰメッセージが、文法規則のセットに基づいて検出されるシンタックスエラー又は文法エラーを有することを意味する。
−セマンティック的に無効(Semantically invalid)：ＳＩＰメッセージが、セマンティック的に正しくないか又はセマンティック規則のセットに関して欠落しているいくつかの情報を含むことを意味する。
−メッセージ有効（Message valid）：ＳＩＰメッセージが事前パース基準のセットに関して正しいことを意味する。この事前パース基準のセットは、上記文法規則のセット及び／又は上記文法規則のセットに対応することができる。
【００５９】
そのために、前処理ユニット２０２は、事前パース基準のセット、及び／又は文法規則のセット及び／又は上記セマンティック規則のセットにアクセスする。
【００６０】
これらの状況では、本発明の一実施形態によれば、本発明に従って、事前パースされた各ＳＩＰメッセージにクラスが関連付けられる。この関連付けは、事前パースされた各ＳＩＰメッセージについて、決定されたクラスを含むメッセージコンテキストを生成することによって行われる。
【００６１】
したがって、このＳＩＰ前処理は、一実施形態によれば、ＳＩＰアプリケーションに、受信されたＳＩＰメッセージ、及び前処理ユニットレベルで提供されたクラスを示す関連付けられるコンテキストを提供する。
【００６２】
この関連付けられるコンテキストは、ＳＩＰアプリケーションのパースプロセス及び決定プロセスを加速することを可能にする他のいくつかの有用である情報も示すことができる。
【００６３】
例示として、各ＳＩＰアプリケーションは、それぞれのＴＣＰ／ＵＤＰポートにバインド(bind)され、このポート上で着信するＴＣＰ／ＵＤＰデータパケットをリスン(listen)する。
【００６４】
ＳＩＰ前処理モジュール２４の内部では、ＳＩＰソケット２２と呼ばれる１つのＳＩＰ前処理エンティティが、１つの管理されたＴＣＰ接続に専用化されている。しかしながら、単一のＳＩＰユーザアプリケーションを宛先とした着信するすべてのＵＤＰメッセージを処理するのに必要とされるソケットは、１つのみとすることができる。
【００６５】
ＳＩＰソケット２２は、受信されたトラフィックを解析するが、有利に、上位のＳＩＰアプリケーションによって送信されたデータに対してトランスペアレントのままとすることができる。
【００６６】
たとえば、２つのＳＩＰアプリケーションがポート番号５０６０及びポート番号５０６１上でそれぞれ実行されている場合、ポート５０６０及び５０６１で受信されたＵＤＰメッセージを処理するために、２つの別個のＳＩＰソケット２２をそれぞれ割り当てることができる。その後、好ましくは、新しいＴＣＰ接続ごとに新しいＳＩＰアプリケーションを割り当てる。
【００６７】
たとえば、ＰＯＳＩＸ（「ＵＮＩＸ（登録商標）用ポータブルオペレーティングシステムインターフェース(Portable Operating System Interface for UNIX)」を表す）環境では、ＴＣＰ／ＵＤＰソケットと同じ方法で、新しいＳＩＰソケット２２をオープン及びクローズすることができる。
【００６８】
図３は、本発明の一実施形態によるＳＩＰソケット２２を詳細に示している。
【００６９】
ＳＩＰソケット２２は、
−データパケットＦＩＦＯ２０１、並びに
−ＳＩＰ前処理ユニット２０２であって、
−デリニエーション（delineation）ユニット３０６、
−事前廃棄ユニット３０７、
−文法事前パースユニット３０８、
−セマンティック事前パースユニット３０９、及び
−フィルタリングユニット３１０、
を含む、ＳＩＰ前処理ユニット２０２、
を備えることができる。
【００７０】
事前廃棄ユニット３０７は、いくつかの事前廃棄基準に基づいて、いくつかのデータメッセージを早期に廃棄するようになっている。
【００７１】
ＳＩＰシグナリングセッションは、ＴＣＰ／ＩＰスタック２１によって端末２０のＳＩＰポートへ伝達される。データパケットは、このＳＩＰポート上で受信され、ＦＩＦＯ２０１内にキューイングされる。
【００７２】
次に、受信データパケットから、連続したＳＩＰメッセージが、デリニエーションユニット３０６によってデリニエートされる。
【００７３】
理論的には、連続した有効なＳＩＰメッセージが受信されると、前のＳＩＰメッセージの終了及び次のＳＩＰメッセージの開始を見つけることを意味する、これらのＳＩＰメッセージの連続を規定するのに何ら問題はない。確かに、各ＳＩＰメッセージにおいて、コンテンツ長ヘッダは、対応するＳＩＰメッセージの正確なサイズを示す。
【００７４】
しかし、無効なＳＩＰメッセージが受信されると、たとえば、受信されたＳＩＰメッセージのコンテンツ長ヘッダが間違った情報を示しているとき、このＳＩＰメッセージを廃棄することができ、デリニエーションユニットは、新しいＳＩＰメッセージの最初のラインを見つけるまで、データを消費する。ＳＩＰ応答メッセージのこの最初のラインは、たとえば、文字列「SIP/2.0」に基づいて判断することができる。
【００７５】
したがって、ＦＩＦＯ２０１に記憶されているデータパケットは、事前廃棄ユニット３０７に送信されるために、デリニエートユニット３０６の出力で連続したＳＩＰメッセージを通じて示される。確かに、デリニエーションユニット３０６は、各ＳＩＰメッセージを事前廃棄ユニット３０７へ送信する。
【００７６】
この事前廃棄ユニット３０７は、たとえば、ＳＩＰメッセージのフラッディング(flooding)を回避するようになっているか、又は、有害なアドレス若しくは悪意のあるアドレスとして知られている送信元アドレスから到着したＳＩＰメッセージの受信を防止するようになっている。そのため、事前廃棄ユニット３０７は、送信元アドレスのブラックリストにアクセスすることができる。
【００７７】
前処理ユニット２０２でメッセージを廃棄するこのステップによって、受信されたＳＩＰデータメッセージのハンドリングをより効率的にすることができ、いくつかの場合には、廃棄されたＳＩＰデータメッセージに対する他の任意の解析の処理を回避することができる。
【００７８】
事前廃棄ユニット３０７によって「廃棄」として分類されたＳＩＰメッセージは、それ以降のユニットによって解析されず、フィルタリングユニット３１０に直接渡される。関連付けられるコンテキストは、廃棄の理由をさらに示すことができる。
【００７９】
ＳＩＰメッセージに対して廃棄を適用する理由に関して、本発明には、何の制限も付随していない。たとえば、本発明の一実施形態では、事前廃棄ユニット３０７は、単位時間当たりあまりにも多くのＳＩＰメッセージが受信されると、ＳＩＰメッセージをランダムに廃棄するようにすることができる。そのために、しきい値を定義することができ、受信されたＳＩＰメッセージの個数がこのしきい値よりも高いとき、この事前廃棄ユニット３０７は、単位時間当たりしきい値よりも低い個数の受信パケットをハンドリングするために、文法事前パースユニット３０８を通過する前に、いくつかの受信メッセージをランダムに廃棄する。
【００８０】
事前廃棄ユニット３０７は、廃棄されないＳＩＰメッセージを文法事前パースユニット３０８に提供する。
【００８１】
この段階では、文法事前パースユニット３０８は、ＲＦＣ３２６１又はＲＦＣ２３３４で定義されたＳＩＰ ＡＢＮＦ文法のように、ＳＩＰアプリケーションレベル２３で適用される文法規則のセットと比較して、有利に削減することができるＳＩＰ文法規則のセットに基づきＳＩＰメッセージを事前パースすることを担当する。前処理ユニットは、ＳＩＰアプリケーションレベルで実行されるＳＩＰメッセージの解析に取って代わるように設計されていないことを思い起こされたい。
【００８２】
事前パースユニット３０８によって使用されるこのＳＩＰ文法規則のセットは、サポートされるＳＩＰアプリケーション２３のタイプに従って有利に能率化することができる。
【００８３】
この文法事前パースユニット３０８は、事前廃棄ユニット３０７によって提供されたＳＩＰメッセージが文法的に有効であるのか、又は文法的に無効であるのかを判断するようにすることができる。
【００８４】
文法事前パースユニット３０８は、以下で説明するように、ＳＩＰメッセージを処理することができる。
【００８５】
少なくともいくつかのＳＩＰヘッダは、事前にパースすることができる。より正確には、これらのＳＩＰヘッダのいくつかのフィールドを、関連のあるフィールドとして有利に判断することができ、これらの関連のあるフィールドのみを、文法規則のセットに従って、この文法事前パースユニット３０８でチェックする。たとえば、文法規則のセットは、関連のある各フィールドの認可された文字セット及びそれらの最大許容長を定義する。ＳＩＰメッセージは、そのすべての関連のあるフィールドが文法規則のセットを順守している場合に、文法的に有効とみなされる。
【００８６】
次に、ＳＩＰメッセージが文法的に有効として検出された場合、考慮されているＳＩＰメッセージの最初のラインがパースされる。最初のラインを処理することで現在のメッセージがＳＩＰメッセージであるか否かを検出することが可能になるので、ＳＩＰメッセージの最初のラインの処理は、他のラインの処理と有利に異なるものとすることができる。この検出は、最初のラインの「SIP/2.0」文字列の存在に基づいて行うことができる。
【００８７】
その後、最初のラインを処理することによって、メッセージがＳＩＰメッセージとしてチェックされると、このＳＩＰメッセージがＳＩＰ応答であるのか、又はＳＩＰ要求であるのかを意味するＳＩＰメッセージのタイプをチェックすることが可能である。
【００８８】
文法事前パースユニットレベルで行われるチェックは、ＳＩＰメッセージのメソッド名に関するチェックを考慮することができる。したがって、ＳＩＰメッセージにおいてメソッド名を識別することができ、要求ＵＲＩ（「Uniform Resource Identifier：統一資源識別子」を表す）を、最初のライン内で突き止めることができる。これは、オフセット及び長さを求めることができることを意味する。
【００８９】
たとえば、ＳＩＰ応答メッセージの場合、ＲＦＣ３２６１で戻りコード番号として参照されるフィールドを復号する。これは、対応するＡＳＣＩＩコード番号がデジタル値に変換されることを意味する。リーズンフレーズ（reason phrase：理由語句）（フィールド）のＡＳＣＩＩ文字列の開始のオフセットが返される。
【００９０】
最初のラインを処理した後、文法事前パースユニット３０８は、ＳＩＰメッセージの他のラインを処理するようになっている。これら他のラインはヘッダラインである。
【００９１】
一般に、各ヘッダラインは、ヘッダ名（Header Name）で始まり、ヘッダ名の後には、ＲＦＣ３２６１で定義されたＨＣＯＬＯＮ文法規則（最終的にはスペース又は表(tabulations)で囲まれる「：」）が続き、ラインの残りの部分はヘッダ値を含む。空のラインは、ヘッダの終端を示すことができる。
【００９２】
文法事前パースユニット３０８は、ＳＩＰメッセージのヘッダ名を突き止めて識別するようにすることができる。その結果、文法事前パースユニット３０８は、対応するオフセット及び長さで、ヘッダフィールドのロケーションを提供することができる。このオフセット及びこの長さが、共に予想通りであるか否かをチェックすることが可能である。
【００９３】
加えて、この文法事前パースユニット３０８は、考慮されているフィールドで使用される文字が、可能な文字(possible characters)の所定のセットに属するか否かをチェックすることもできる。たとえば、「コンテンツ長」ヘッダに使用される文字が以下の数字セット、すなわち、
（０；１；２；３；４；５；６；７；８；９）
に属することを設計することができる。
【００９４】
次に、文法事前パースユニット３０８は、ヘッダ名の所定のセットのみを解析することができる。そのために、ＳＩＰメッセージにおいて、このセットに属するヘッダ名のみについて、ヘッダ値を抽出する。このヘッダ名のセットは、ＳＩＰメッセージの本体サイズをチェックすることができるようにするために、少なくとも「コンテンツ長（Content-Length）」ヘッダを有利に含むことができる。
【００９５】
ヘッダ値は、たとえば、デジタル値に変換することができ、ＳＩＰメッセージに関連付けられるメッセージコンテキスト内にコピーすることができる。
【００９６】
また、ヘッダ名のセットは、応答メッセージのメソッド名をチェックすることができるようにするために、「CSeq」ヘッダを意味するＳＩＰメソッド名に対応するヘッダも含むことができる。
【００９７】
他のヘッダは、本発明の一実施形態に従ってＳＩＰ前処理が実行されるＳＩＰアプリケーションの必要性に応じて、具体的にパースすることができる。たとえば、ＲＦＣ３２６１の「ｗｗｗ認証（www-authenticate）」ヘッダとして参照されるフィールド内にアナウンスされた値を得ることは、いくつかのＳＩＰアプリケーションにとって有用であり得る。
【００９８】
文法事前パースユニット３０８はさらに、ＳＩＰメッセージの本体サイズをチェックするようにすることができる。理論的には、メッセージ本体サイズは、対応するヘッダのコンテンツ長フィールドにたとえばバイト数で公示されたサイズに対応するはずである。
【００９９】
ＴＣＰのようなレイヤ４トランスポートプロトコルが使用されるとき、コンテンツ長ヘッダフィールドは、すべてのＳＩＰ要求メッセージ及びＳＩＰ応答メッセージに存在するはずである。この情報が提供されない場合、端末は、ＴＣＰ接続がクローズされるまで、メッセージ本体が続くものと仮定することができ、メッセージ本体をエラーのあるＳＩＰメッセージとみなすことができる。
【０１００】
レイヤ４プロトコルがＵＤＰプロトコルである場合、この情報は、提供されない場合がある。この後者の場合、メッセージの本体は、ＳＩＰヘッダの後のデータメッセージの残りの部分を占有するはずである。本体がないとき、コンテンツ長は０に等しい。
【０１０１】
エラーがこの段階で検出された場合、メッセージは、「セマンティック的に無効」として分類される。これは、フレーミングエラーであり、現在のメッセージを破棄することができる。
【０１０２】
文法事前パースユニット３０８によって処理されたＳＩＰメッセージは、次に、追加のチェック及び処理（たとえば変換）を行うため、又は、ＳＩＰメッセージに関連付けられるメッセージコンテキスト構造体を満たすために、セマンティック処理ユニット３０９に提供される。この段階の出力として、メッセージは、セマンティック的に有効又は無効として分類される。
【０１０３】
セマンティック処理ユニット３０９は、ＳＩＰメッセージに対応するメソッド名を識別するようになっている。メソッド名は、上述したように、ＳＩＰ要求メッセージについては最初のラインにおいて、又は、ＳＩＰ応答メッセージについてはCSeqヘッダにおいて、文法事前パースユニット３０８によって突き止められる。このメソッド名は、次に、既知のメソッド名の定義されたセット内で識別され、対応するメソッド識別子MethodIDが求められる。
【０１０４】
既知のメソッド名のセットは有限であり、ＳＩＰアプリケーションによって定義することができる。未知のメソッド名がＳＩＰメッセージにおいて識別されたとき、そのＳＩＰメッセージは、セマンティック的に無効として分類される。
【０１０５】
たとえば、この既知のメソッド名のリストは、以下のものとすることができる。
【０１０６】
【表１】
【０１０７】
MethodIDの値は、メッセージのタイプ（要求又は応答）に依存することに気付くことができる。
【０１０８】
ヘッダ名は、ヘッダ名の定義されたセット内で識別することもできる。次に、ヘッダ名識別子HeaderIDを求めることができ、関連付けられるメッセージコンテキスト内に挿入することができる。単一のHeaderIDについて、いくつかのエイリアスを定義することができる。未知のヘッダを有するＳＩＰメッセージは、セマンティック的に無効として分類される。
【０１０９】
既知のヘッダのセットは有限であり、ＳＩＰアプリケーションによって定義することができる。
【０１１０】
たとえば、このヘッダ名のセットは、以下のものとすることができる。
【０１１１】
【表２】
【０１１２】
メソッド識別子MethodIDに従って、いくつかのヘッダは、ＳＩＰメッセージにおいて一意とすることができる。一意のヘッダ名のリストを、メソッド名のセットの各メソッド名について、ＳＩＰアプリケーションが定義することができる。
【０１１３】
複製されたヘッダを有するＳＩＰメッセージを、セマンティック的に無効として分類することができる。
【０１１４】
セマンティック処理ユニット３０９はさらに、ヘッダパラメータ長をチェックし、次いで各ヘッダパラメータの長さがＳＩＰアプリケーションによって定義することができる範囲内に含まれるか否かを判断するようにすることができる。
【０１１５】
セマンティック処理ユニット３０９はさらに、ヘッダ名をカウントすると共に、それらの発生回数をチェックするようにすることができる。そのために、各ヘッダ名の発生がカウントされる。各ヘッダの発生総数は、通常、各MethodIDについてＳＩＰアプリケーションが定義することができる所与の範囲内に含まれ得る。発生回数がこの所与の範囲外である場合、メッセージを「セマンティック的に無効」として分類することができる。
【０１１６】
【表３】
【０１１７】
最後に、ＳＩＰメッセージを、セマンティック処理ユニット３０９によって処理した後、セマンティック的に有効であるか又はセマンティック的に無効であるかのいずれかのステータスに関連付ける。その後、このＳＩＰメッセージが、フィルタリングユニット３１０に送信される。
【０１１８】
フィルタリングレベルでは、ＳＩＰメッセージを廃棄するか、又は、その関連付けられるメッセージコンテキストと共に対応するＳＩＰアプリケーション２３へＳＩＰメッセージを送信することができる。
【０１１９】
このフィルタリングユニット３１０は、廃棄マスクを有利に適用することができる。これは、このフィルタリングユニット３１０が、このＳＩＰメッセージに関連付けられるメッセージコンテキストにおいて示されたクラスに従ってＳＩＰメッセージを廃棄することができることを意味する。
【０１２０】
フィルタリングユニット３１０は、データパケットＦＩＦＯのキューイング解除をさらに担当することができる。
【０１２１】
以下の表は、フィルタリングマスクパラメータを説明している。
【０１２２】
【表４】
【０１２３】
たとえば、パラメータ「Filtering_mask（フィルタリングマスク）」が０１００に設定されているとき、このパラメータは、「文法的に無効」として分類されたメッセージのみがフィルタリングユニットによって廃棄されることを指定する。他のすべてのメッセージクラスは、さらなる解析のために維持される。
【０１２４】
本発明の一実施形態では、使用することができるプリミティブのセットを通じてコマンドインターフェースを介してＳＩＰソケット２２をロード及び構成することができる。これらのプリミティブは、「open（オープン）」、「bind（バインド）」、「listen（リスン）」、「accept（受理）」、「write（書き込み）」、「read（読み出し）」のような、ＰＯＳＩＸ環境で定義された標準的なソケットプリミティブと同様のものとすることができる。
【０１２５】
以下のセクションは、入力として受信された、一実施形態によるＳＩＰソケット２２の構成を説明する。
【０１２６】
ＳＩＰソケットをバインドするために、ＴＣＰ／ＵＤＰポートは、ＴＣＰパケット又はＵＤＰパケットの受信用に予約される。ＴＣＰの場合、このポートは、着信する新しいＴＣＰ接続をリスンするのに使用することができる。
【０１２７】
以下のパラメータを設定することができる。すなわち、
−プロトコル（ＵＤＰ又はＴＣＰ）、
−ローカルポート番号（たとえば５０６０）、
−ＳＩＰメソッド名のリスト、
−各ＳＩＰメソッド名について、
○要求及び応答のような有効なヘッダ名のリスト、
○各ヘッダ名について、
・最小発生回数及び最大発生回数、並びに
・パラメータの最小長及び最大長、
−認証されていない送信元ＩＰアドレスのリスト
−メッセージの分類による廃棄マスク
を設定することができる。
【０１２８】
以下のセクションは、特に、ＳＩＰメッセージ前処理中に生成されるメッセージコンテキストのコンテンツを詳しく述べることによって、一実施形態によるＳＩＰソケットの出力を説明する。
【０１２９】
メッセージコンテキストは、メッセージの前処理中に生成される３つのタイプの報告を含むことができる。すなわち、
−「メソッド説明報告」を示す最初のライン報告、
−連続した各ヘッダラインの複数のヘッダライン報告、及び
−メッセージが全体的に処理されたときに生成される最終報告、
を含むことができる。
【０１３０】
ＳＩＰメッセージのメッセージコンテキストに含まれるグローバル報告に対応するように、異なる報告を連結することができる。
【０１３１】
たとえば、ＳＩＰメッセージがＳＩＰメッセージの最初のラインからエラーのあるメッセージとして識別された場合、最終報告のみを書き込むことができる。
【０１３２】
そのために、フィールド「Report_type（報告タイプ）」は、報告タイプを符号化することができる。このフィールドは、
−method_report（メソッド報告）、
−header_report（ヘッダ報告）、及び
−final_report（最終報告）
に設定することができる。
【０１３３】
一実施形態によるＳＩＰメッセージに関連付けられるメッセージコンテキストに含まれる異なる報告をデリニエートするためには、異なる方法がある。たとえば、すべての報告について固定サイズを決定することも可能であるし、任意の記号又は空白によってすべての報告を分離することも可能であるし、リンクリストとして報告を管理することも可能である。
【０１３４】
この報告のコンテンツは、メッセージがＳＩＰ要求メッセージとして識別されるのか、又はＳＩＰ応答メッセージとして識別されるのかに依存し得る。
【０１３５】
メッセージが、ＳＩＰ要求メッセージとして識別される場合、報告は、以下の情報、すなわち、
○method_reportに対応するReport_type（報告タイプ）、
○要求又はMethodID又はRequestURI_Idx（要求ＵＲＩインデックス）又はURI_Length（ＵＲＩ長）又はLine_Length（ライン長）に対応するMsg_type（メッセージタイプ）、
を含むことができる。
【０１３６】
たとえば、データ「INVITE sip:bob@192.0.2.4 SIP/2.0 <CR><LF>」を含むＳＩＰメッセージは、以下の情報、すなわち、
Msg_type = 要求、
MethodID = INVITE、
RequestURI_ldx =7、
URI_Length = 17、
Line_Length = 34（ライン終端セパレータのとき）
を含む報告に関連付けられる。
【０１３７】
そうではなく、ＳＩＰメッセージがＳＩＰ応答メッセージとして識別される場合、関連付けられる報告は、以下の情報、すなわち、
○Report_type = method_report、
○Msg_type = 応答／MethodID／CodeID（コードＩＤ）／ReasonPhrase_Idx（リーズンフレーズインデックス）／Line_Length
を含む。
【０１３８】
たとえば、ＳＩＰメッセージ「SIP/2.0 200 OK」は、以下の情報、すなわち、
Msg_type = 応答、
CodeID = 200、
ReasonPhrase_Idx = 12、
Line_Length = 16（ライン終端セパレータがカウントされたとき）
を含む報告に関連付けられる。
【０１３９】
以下の情報を、ヘッダ報告の各ライン（最初のラインを除く）に含めることができる。
○Report_type = header_report
○HeaderID／HeaderValue_Idx（ヘッダ値インデックス）／LineLen（リスン長）／HeaderValueLen（ヘッダ値長）。
【０１４０】
一実施形態では、メッセージコンテキストには１つの最終報告のみがある。この最終報告は、対応するＳＩＰメッセージの前処理の要約を含む。
【０１４１】
この最終報告において、以下の情報が提供される。すなわち、
−Report_type = final_report（最終報告）
−MsgStatus（メッセージステータス）：廃棄又は文法的に無効又はセマンティック的に無効又はメッセージ有効
−Content-Length値（コンテンツ長値）
−他の値（指定された場合）：たとえばCSeq
が提供される。
【０１４２】
ＳＩＰ前処理モジュール２４は、ソフトウェアモジュールで実施することもできるし、ハードウェアモジュールで実施することもできる。
【０１４３】
図４は、ハードウェア端末におけるＳＩＰ前処理モジュール２４の使用を示している。
【０１４４】
ネットワークプロセッサ４１は、レイヤ４までのプロトコルスタック２１をハンドリングする。このネットワークプロセッサモジュール２１は、イーサネット（登録商標）ＭＡＣインターフェースに直接接続することができる。
【０１４５】
アプリケーションプロセッサ４３は、オペレーティングシステムのもとで、そのネットワークスタックハンドリングがネットワークプロセッサにおいてオフロードされた状態で、アプリケーション２３を実行するようにすることができる。
【０１４６】
予約されたポート（たとえば、ポート５０６０上でバインドされたソケット）で受信されたデータパケットは、ＳＩＰソケット＃１へ送信される。予約されたポート（たとえば、ポート５０６１上でバインドされたソケット）で受信されたデータパケットは、ＳＩＰソケット＃２へ送信される。データパケットの残りは、アプリケーションプロセッサによって直接ハンドリングされる。
【０１４７】
ＳＩＰ前処理モジュールは、たとえば、パースする特定のフィールド、過負荷検出用の最大しきい値等に関して、アプリケーションプロセッサによって有利に構成され得る。
【０１４８】
一実施形態に従ってＳＩＰメッセージを前処理した後、ＳＩＰメッセージが有効である場合には、ＳＩＰメッセージは、アプリケーションプロセッサ４３に渡される。有利なことに、アプリケーションは、その後、そのレベルで必要とされる場合に、関連付けられるメッセージコンテキストを利用し、他のすべてのパースタスク及びメッセージ解釈タスクを行う。ＳＩＰメッセージが有効でない場合には、上述したように、ＳＩＰメッセージは、フィルタリングレベルで、廃棄マスクの分類に従って破棄され得る。この最後の場合に、一実施形態では、より短いメッセージコンテキストのみが、アプリケーションプロセッサ４３へ転送される。
【０１４９】
ネットワークプロセッサ４１からアプリケーションプロセッサ４３への送信パスは、任意のタイプのトラフィックを送信するようにすることができる。アプリケーションプロセッサ４３からネットワークプロセッサ４１へいくつかの情報を送信するのに、別のパスを使用することができる。
【０１５０】
この種の前処理では、メッセージを連続して処理することができる。好ましくは、従来のソフトウェアパースのようにバックトラッキングをハンドリングする必要がないので、各文字は１回だけ読み出される。
【０１５１】
同じ入力シンボルを使用するいくつかの状態マシンを並列に評価することができる。たとえば、文字列終端セパレータが検索されている間、文字列マッチャ（string matcher）が評価され、セパレータが見つかったときに文字列マッチャの結果が検討される。
【０１５２】
いくつかの「ルックアヘッド（look-ahead）」機能を実施するために、事前にいくつかの文字を読み出すことも有用であり得る。解析する次のいくつかの文字を知ることによって、これは、ラインシーケンスの終端を決定したり、ヘッダの終端を識別したりするのに有用である。読み出された文字を、或る深さのシフトレジスタにプッシュし、必要とされるルックアヘッドが提供される。
【０１５３】
文字列マッチング機能は、メソッドの識別又は異なる可能なヘッダの識別を行うために実行することができる。このコンテキストでは、たとえば、既知の「Aho-corasick」複数文字列マッチングアルゴリズムを使用することができる。決定性有限オートマトン(Deterministic Finite Automata)（ＤＦＡ）をこのアルゴリズムで生成することができ、各オートマトンは、認識された文字列に対応するＤＦＡの状態を受理する。
【０１５４】
ＳＩＰ文法は、大文字であるMETHODの符号化を除いて、通常、文字について大文字と小文字とを区別しない。Aho Corasick ＤＦＡに記憶されている文字列は、大文字に正規化される。入力ストリームは、文字列マッチャに提示される前に、大文字に正規化される。通常のストリームは、チェックを可能にするように保存することができる。
【０１５５】
特定の機能又は特定の機能のセットを使用して、特定のフィールドで用いられる文字が許容されるか否かをチェックすることができる。これは、入力アルファベットの各可能な値について異なるセットの機能（文字セット）の事前に計算された値を含むルックアップテーブルを使用して実施することができる。小さなメモリを使用して非常に効率的且つコンパクトなルックアップテーブルを実施することが可能である。
【０１５６】
以下のパラグラフは、ハードウェアで実施することができるような事前パースの主要なステップを示している。
【０１５７】
メッセージの最初のラインの処理は、他のラインの処理とは異なっている。その処理は、非常に単純であり、メッセージが要求メッセージであるのか、又は応答メッセージであるのかを非常に容易に識別することを可能にする。最初のワードが解析されて、そのワードが既知のメソッドであるのか、又は文字列「SIP/2.0」であるのかがチェックされる。この文字列が見つかった場合、メッセージは、応答であると仮定され、そうでない場合、メッセージは要求であると仮定される。
【０１５８】
METHOD又はSIP/2.0の文字列の識別は、Aho-Corasick ＤＦＡを使用することによって行うことができる。
【０１５９】
ラインセパレータが見つかったときを意味する最初のラインの処理の終わりに、メソッドの説明を生成することができる。
【０１６０】
後続のラインの前処理は、各ラインがHeaderIDで始まり、その後にHCOLON（最終的にはスペース又はＨＴＡＢによって囲まれる「：」）が続くことに基づくことができる。ラインの残りの部分は、パラメータを含むことができる。
【０１６１】
後続のラインの各最初のワードは、Aho-Corasick等の複数文字列マッチングアルゴリズムによって識別することができる。セパレータが検出されると、文字列マッチャの結果を評価して、ヘッダ名が認識されるか否かがチェックされる。
【０１６２】
各ラインの解析の終わりに、≪ヘッダ報告≫を生成する。処理は、空白ライン、すなわちシーケンスCR LF CR LFを識別することによって「ヘッダ終端（end of header）」が検出されると、終了する。
【０１６３】
その後、最終報告を生成する。
【０１６４】
このメカニズムは、ＳＩＰシグナリングプロトコルに基づく住宅ゲートウェイ又はビジネスゲートウェイ及びいわゆるＩＰ電話等の端末機器で有利に実施することができる。このメカニズムは、ＳＩＰアプリケーションまでＳＩＰシグナリングチャネルを通じて注入される可能性のある無用なデータ処理のための過剰な量の処理資源の先取りを防止する。
【特許請求の範囲】
【請求項１】
端末（２０）においてテキストベースのプロトコルに従って受信データメッセージをハンドリングする方法であって、
該方法は、以下のステップ、すなわち、
／１／事前パース基準のセットに従って、前記受信データメッセージを事前パースするステップ（３０８、３０９）と、
／２／前記データメッセージに関連付けられるメッセージコンテキストを生成するステップであって、該メッセージコンテキストは、前記事前パースするステップから取得された情報を示す、生成するステップと、
／３／前記データメッセージ及び前記関連付けられるメッセージコンテキストを前記端末上で実行されているアプリケーションに提供するステップと、
を含み、
前記事前パースするステップにおいて、前記データメッセージは、以下のクラス、すなわち、
文法規則のセットに基づき文法的に無効、又は
セマンティック規則のセットに基づきセマンティック的に無効、又は
事前パース基準に関して有効、
のうちの１つに分類され、
前記関連付けられるメッセージコンテキストは前記クラスを示す、方法。
【請求項２】
前記事前パース基準のセットは、文法規則のセット及び／又はセマンティック規則のセットを含む、請求項１に記載の受信データメッセージをハンドリングする方法。
【請求項３】
前記文法規則のセットは、前記テキストベースのプロトコルに従って定められ、いくつかの決定された関連のあるフィールドに対する部分解析に対応する、請求項２に記載の受信データメッセージをハンドリングする方法。
【請求項４】
前記セマンティック規則のセットは、前記いくつかの決定された関連のあるフィールドの有効性をチェックする部分解析に対応する、請求項３に記載の受信データメッセージをハンドリングする方法。
【請求項５】
前記事前パースするステップの前に、事前廃棄するステップが実行され、該事前廃棄するステップは、或るメッセージが、事前廃棄基準のセットに基づき事前廃棄されるものとして分類されるか否かを判断することを担当する、請求項１から４までのいずれか１項に記載の受信データメッセージをハンドリングする方法。
【請求項６】
受信データメッセージがデータパケットで受信されるとき、前記ステップ／１／の前に、受信データパケットから連続したデータメッセージをデリニエートするステップ（３０６）が実行される、請求項１から５までのいずれか１項に記載の受信データメッセージをハンドリングする方法。
【請求項７】
前記データメッセージ及び前記関連付けられるメッセージコンテキストを前記アプリケーションに提供するステップの前に、少なくとも前記事前パースするステップの結果に基づいて、前記データメッセージをフィルタリングするステップ（３１０）をさらに含む、請求項１から６までのいずれか１項に記載の受信データメッセージをハンドリングする方法。
【請求項８】
前記メッセージコンテキストは、前記事前パースするステップの間に満たされる、請求項１から７までのいずれか１項に記載の受信データメッセージをハンドリングする方法。
【請求項９】
端末（２０）においてテキストベースのプロトコルに従って受信データメッセージをハンドリングするようになっている前処理モジュール（２４）であって、
該前処理モジュールは、以下のユニットから成るセット、すなわち、
事前パース基準のセットに従って、前記受信データメッセージを事前パースするようになっている事前パースユニット（３０８、３０９）であって、該データメッセージは、以下のクラス、すなわち、
文法規則のセットに基づき文法的に無効、又は
セマンティック規則のセットに基づきセマンティック的に無効、又は
事前パース基準に関して有効、
のうちの１つに分類され、関連付けられるメッセージコンテキストは前記クラスを示す、事前パースユニット（３０８、３０９）と、
前記データメッセージに関連付けられる前記メッセージコンテキストを生成するようになっている生成ユニットであって、該メッセージコンテキストは、前記事前パースユニットから取得された情報を示す、生成ユニットと、
前記データメッセージ及び前記関連付けられるメッセージコンテキストを前記端末上で実行されているアプリケーションに提供するようになっているフィルタリングユニット（３１０）と、
から成るセットを備える、前処理モジュール。
【請求項１０】
前処理モジュール（２４）であって、前記端末レベルでハンドリングされる接続ごとに、１つのユニットのセットを備える、請求項９に記載の前処理モジュール。
【請求項１１】
前処理モジュール（２４）であって、少なくとも１つのユニットに関する構成情報を前記ユニットのセットから受信するようになっている構成インターフェースをさらに備える、請求項９又は１０に記載の前処理モジュール。
【請求項１２】
端末（２０）であって、請求項９から１１までのいずれか１項に記載の前処理モジュールを備える端末。
【請求項１】
端末（２０）においてテキストベースのプロトコルに従って受信データメッセージをハンドリングする方法であって、
該方法は、以下のステップ、すなわち、
／１／事前パース基準のセットに従って、前記受信データメッセージを事前パースするステップ（３０８、３０９）と、
／２／前記データメッセージに関連付けられるメッセージコンテキストを生成するステップであって、該メッセージコンテキストは、前記事前パースするステップから取得された情報を示す、生成するステップと、
／３／前記データメッセージ及び前記関連付けられるメッセージコンテキストを前記端末上で実行されているアプリケーションに提供するステップと、
を含み、
前記事前パースするステップにおいて、前記データメッセージは、以下のクラス、すなわち、
文法規則のセットに基づき文法的に無効、又は
セマンティック規則のセットに基づきセマンティック的に無効、又は
事前パース基準に関して有効、
のうちの１つに分類され、
前記関連付けられるメッセージコンテキストは前記クラスを示す、方法。
【請求項２】
前記事前パース基準のセットは、文法規則のセット及び／又はセマンティック規則のセットを含む、請求項１に記載の受信データメッセージをハンドリングする方法。
【請求項３】
前記文法規則のセットは、前記テキストベースのプロトコルに従って定められ、いくつかの決定された関連のあるフィールドに対する部分解析に対応する、請求項２に記載の受信データメッセージをハンドリングする方法。
【請求項４】
前記セマンティック規則のセットは、前記いくつかの決定された関連のあるフィールドの有効性をチェックする部分解析に対応する、請求項３に記載の受信データメッセージをハンドリングする方法。
【請求項５】
前記事前パースするステップの前に、事前廃棄するステップが実行され、該事前廃棄するステップは、或るメッセージが、事前廃棄基準のセットに基づき事前廃棄されるものとして分類されるか否かを判断することを担当する、請求項１から４までのいずれか１項に記載の受信データメッセージをハンドリングする方法。
【請求項６】
受信データメッセージがデータパケットで受信されるとき、前記ステップ／１／の前に、受信データパケットから連続したデータメッセージをデリニエートするステップ（３０６）が実行される、請求項１から５までのいずれか１項に記載の受信データメッセージをハンドリングする方法。
【請求項７】
前記データメッセージ及び前記関連付けられるメッセージコンテキストを前記アプリケーションに提供するステップの前に、少なくとも前記事前パースするステップの結果に基づいて、前記データメッセージをフィルタリングするステップ（３１０）をさらに含む、請求項１から６までのいずれか１項に記載の受信データメッセージをハンドリングする方法。
【請求項８】
前記メッセージコンテキストは、前記事前パースするステップの間に満たされる、請求項１から７までのいずれか１項に記載の受信データメッセージをハンドリングする方法。
【請求項９】
端末（２０）においてテキストベースのプロトコルに従って受信データメッセージをハンドリングするようになっている前処理モジュール（２４）であって、
該前処理モジュールは、以下のユニットから成るセット、すなわち、
事前パース基準のセットに従って、前記受信データメッセージを事前パースするようになっている事前パースユニット（３０８、３０９）であって、該データメッセージは、以下のクラス、すなわち、
文法規則のセットに基づき文法的に無効、又は
セマンティック規則のセットに基づきセマンティック的に無効、又は
事前パース基準に関して有効、
のうちの１つに分類され、関連付けられるメッセージコンテキストは前記クラスを示す、事前パースユニット（３０８、３０９）と、
前記データメッセージに関連付けられる前記メッセージコンテキストを生成するようになっている生成ユニットであって、該メッセージコンテキストは、前記事前パースユニットから取得された情報を示す、生成ユニットと、
前記データメッセージ及び前記関連付けられるメッセージコンテキストを前記端末上で実行されているアプリケーションに提供するようになっているフィルタリングユニット（３１０）と、
から成るセットを備える、前処理モジュール。
【請求項１０】
前処理モジュール（２４）であって、前記端末レベルでハンドリングされる接続ごとに、１つのユニットのセットを備える、請求項９に記載の前処理モジュール。
【請求項１１】
前処理モジュール（２４）であって、少なくとも１つのユニットに関する構成情報を前記ユニットのセットから受信するようになっている構成インターフェースをさらに備える、請求項９又は１０に記載の前処理モジュール。
【請求項１２】
端末（２０）であって、請求項９から１１までのいずれか１項に記載の前処理モジュールを備える端末。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２００９−２８４４７１（Ｐ２００９−２８４４７１Ａ）
【公開日】平成２１年１２月３日（２００９．１２．３）
【国際特許分類】
【外国語出願】
【出願番号】特願２００９−８５１２７（Ｐ２００９−８５１２７）
【出願日】平成２１年３月３１日（２００９．３．３１）
【出願人】（５０３１６３５２７）ミツビシ・エレクトリック・アールアンドディー・センター・ヨーロッパ・ビーヴィ (175)
【氏名又は名称原語表記】ＭＩＴＳＵＢＩＳＨＩ ＥＬＥＣＴＲＩＣ Ｒ＆Ｄ ＣＥＮＴＲＥ ＥＵＲＯＰＥ Ｂ．Ｖ．
【住所又は居所原語表記】Ｃａｐｒｏｎｉｌａａｎ ４６， １１１９ ＮＳ Ｓｃｈｉｐｈｏｌ Ｒｉｊｋ， Ｔｈｅ Ｎｅｔｈｅｒｌａｎｄｓ
【Ｆターム（参考）】
【公開日】平成２１年１２月３日（２００９．１２．３）
【国際特許分類】
【出願番号】特願２００９−８５１２７（Ｐ２００９−８５１２７）
【出願日】平成２１年３月３１日（２００９．３．３１）
【出願人】（５０３１６３５２７）ミツビシ・エレクトリック・アールアンドディー・センター・ヨーロッパ・ビーヴィ (175)
【氏名又は名称原語表記】ＭＩＴＳＵＢＩＳＨＩ ＥＬＥＣＴＲＩＣ Ｒ＆Ｄ ＣＥＮＴＲＥ ＥＵＲＯＰＥ Ｂ．Ｖ．
【住所又は居所原語表記】Ｃａｐｒｏｎｉｌａａｎ ４６， １１１９ ＮＳ Ｓｃｈｉｐｈｏｌ Ｒｉｊｋ， Ｔｈｅ Ｎｅｔｈｅｒｌａｎｄｓ
【Ｆターム（参考）】
[ Back to top ]