(57)【要約】  制御メッセージおよび他の情報をＳＩＰメッセージ内に埋め込むことにより、ＳＩＰネットワークを介してこの情報を渡す方法が提供される。情報を暗号化し、暗号化された情報を１つまたは複数の実装時定義のＳＩＰヘッダフィールド内に埋め込み、情報が埋め込まれたフィールドまたはフィールド群を含むＳＩＰメッセージを送信することにより、この情報は１つのＳＩＰエージェントから他へ送信される。
2009518958.tif 000002
【特許請求の範囲】
【請求項１】
１つのＳＩＰエージェントから他へ情報を送信する方法であって、
情報を暗号化するステップ（２０）と、
１つまたは複数の実装時定義のＳＩＰヘッダフィールド内に暗号化された情報を埋め込むステップ（３０）と、
前記フィールドまたはフィールド群を含むＳＩＰメッセージを送信するステップ（４０）と
を含む、方法。
【請求項２】
少なくとも１つのＳＩＰエージェントが情報を他のＳＩＰエージェントから受信する方法であって、
ＳＩＰヘッダフィールド群を含むＳＩＰメッセージを受信するステップであって、少なくとも１つのＳＩＰヘッダフィールドが実装時定義である、ステップと、
埋め込み情報を１つまたは複数の前記実装時定義のＳＩＰヘッダフィールドから抽出するステップと、
抽出された情報を復号化するステップと
を含む、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットを介して情報を送信する方法に関し、より詳細にはＳＩＰプロトコルに準拠する送信方法に関する。
【背景技術】
【０００２】
ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）は、他のプロトコルと協力し、インターネットエンドポイント間の通信を容易にするアプリケーション層制御（シグナリング）プロトコルであり、この点において「ユーザエージェント」とも呼ばれる。より具体的には、ＳＩＰは、インターネット電話通信通話および他のマルチメディアセッションを確立、変更、および終了することができる。ＳＩＰは、とりわけ通信のためにエンドポイントの位置を捜し、通話の相手先が使用可能かを確認し、使用すべき媒体および対応する媒体パラメータを決定し、セッションをセットアップおよび管理することによりこの種のサポートを行なう。ＳＩＰの詳細な説明は、Ｊ．ＲｏｓｅｎｂｅｒｇらによるＲＦＣ３２６１、Ｔｈｅ  Ｉｎｔｅｒｎｅｔ  Ｓｏｃｉｅｔｙ（２００２）（ｗｗｗ．ｆａｑｓ．ｏｒｇ／ｒｆｃｓ／ｒｆｃ３２６１．ｈｔｍｌ）に見ることができる。
【０００３】
ＳＩＰプロトコルにより定められる規則を実装する論理要素は、「ＳＩＰ要素」または「ＳＩＰエージェント」と呼ばれる。ＳＩＰ要素は、ユーザエージェント（ＵＡ：ｕｓｅｒ  ａｇｅｎｔ）クライアント、ＵＡサーバ、ステートレスプロキシ、ステートフルプロキシ、およびレジストラを含む。ＳＩＰエージェント間でＳＩＰプロトコルの一部として送信されるデータは、「ＳＩＰメッセージ」と呼ばれる。ＳＩＰメッセージは、リクエストまたはレスポンスのどちらかである。
【０００４】
ＳＩＰメッセージはヘッダを含み、メッセージ本体も含んでよい。ヘッダは、メッセージに関する情報を含む一連の１つまたは複数のヘッダフィールドとして組み立てられる。典型的なヘッダフィールドには、ヘッダフィールド名が設定され、１つまたは複数のヘッダフィールド値のリストも含んでよい。
【０００５】
ＳＩＰメッセージがメッセージ本体を含む場合、適切なヘッダフィールドは、メッセージ本体のインターネット媒体の種類および長さ、ならびにそれがなんらかの圧縮または他の暗号化を行なっているかを特定する。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
様々な理由で、仲介ＳＩＰエージェントによるそれらのメッセージの処理なしに、または検知さえなしに、ＳＩＰネットワーク内の特定のエージェント間で制御メッセージおよび他のデータを送信可能であることが望ましい。例えば、エージェントがヘッダを認識しない場合、ＳＩＰエージェントは、ＳＩＰエージェントを通過するメッセージからヘッダを落とす可能性がある。しかし、新しいＳＩＰの機能およびＳＩＰに対する新しい拡張は、概して新しいヘッダを必要とする。新しいヘッダがネットワークの適切なエンドポイントでエージェントにより処理可能である場合でさえ、ネットワーク全体がオーバホールされていなければ送信の際にヘッダ情報を失う危険が存在する可能性がある。したがって、仲介エージェントによる処理を免れるように新しいヘッダが組み込み可能であるならば、運用者がネットワークオーバホールに投資する前に新しいＳＩＰ機能の早期の導入を促すことになる。
【０００７】
このような埋め込み情報の他の使用法は、その情報へのアクセスから他のプロキシおよびエージェントを排除しながら、トランザクションまたは請求の情報の特定されたＳＩＰプロキシまたはエージェント間のピアツーピア通信、後続の処理のためのエージェント間の特定のセッションに対するシグナリング情報の記録、あるいはネットワーク操作を監視する情報の通信を含む可能性がある。
【課題を解決するための手段】
【０００８】
発明者らは、情報をＳＩＰメッセージ内に埋め込む方法を考案した。一態様では、発明者らの新しい方法は、情報を暗号化し、暗号化された情報を１つまたは複数のＳＩＰヘッダフィールド内に埋め込み、情報が埋め込まれたフィールドまたはフィールド群を含むＳＩＰメッセージを送信することにより、情報を１つのＳＩＰエージェントから他へ送信することを含む。具体的には、この目的に用いられるヘッダフィールドは、ヘッダフィールドの値が一意的で、ダイアログＩＤ、通話ＩＤ、または他の識別情報を確認するために用いることができる範囲のみで、ヘッダフィールドの値がＳＩＰプロトコルの機能に必須であるものである。このような特性は、発明者らがこれらのフィールドを用いて一意的な情報を挿入し、次にその情報を通話ＩＤ、ダイアログＩＤ等として用いる余地を与えている。このようなフィールドは、本明細書では「実装時定義」と呼ばれる。この「実装時定義」という用語は、以下の説明全体を通してその意味を有する。
【０００９】
第２の態様では、発明者らの発明は、ＳＩＰエージェントが、少なくとも１つは実装時定義であるＳＩＰヘッダフィールド群を含むＳＩＰメッセージを受信することによりこのような埋め込み情報を他のＳＩＰエージェントから受信し、埋め込み情報を１つまたは複数の実装時定義のＳＩＰヘッダフィールドから抽出し、抽出された情報を復号化することを含む。
【発明を実施するための最良の形態】
【００１０】
情報の埋め込みに用いられる可能性があるＳＩＰメッセージの様々な種類のうち、最も基本的な種類のＳＩＰメッセージを用いることが有利である。これは、情報が標準的なＳＩＰメッセージ内で搬送可能であることを保証し、これらのＳＩＰメッセージは、相対的に豊富であり、メッセージが連絡を取る可能性がある任意のＳＩＰエージェントに対応できる。基本的なＳＩＰメッセージは、例えば、リクエストメッセージＲＥＧＩＳＴＥＲ、ＩＮＶＩＴＥ、ＡＣＫ、ＣＡＮＣＥＬ、ＢＹＥ、およびＯＰＴＩＯＮＳ、ならびにそれらのレスポンスを含む。
【００１１】
発明者らは、基本的なＳＩＰメッセージ内で発生し、実装時定義のパラメータを含む４つのヘッダフィールドを特定するが、これらは本明細書に説明される本方法に有用なヘッダフィールドの例である。
【００１２】
発明者らが特定したこれらのヘッダフィールドは、Ｖｉａ、Ｆｒｏｍ、Ｔｏ、およびＣａｌｌ−ＩＤである。
【００１３】
「Ｖｉａ」ヘッダフィールドは、リクエストメッセージへのレスポンスが送信されるべきアドレスを含み、クライアントおよびサーバが、メッセージが生成するトランザクションを識別するために用いる「ｂｒａｎｃｈ」パラメータも含む。ｂｒａｎｃｈパラメータは、実装時定義であるが、文字列「ｚ９ｈＧ４ｂＫ」を前に付加しなければならない。
【００１４】
「Ｆｒｏｍ」ヘッダフィールドは、リクエストメッセージの開始者を識別するＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）を含む。「Ｆｒｏｍ」ヘッダフィールドはまた、「ｔａｇ」パラメータも含み、これは、典型的にはＵＡＣにより選択されたランダムな文字列である。（ＵＡＣ―ユーザエージェントクライアント（Ｕｓｅｒ  Ａｇｅｎｔ  Ｃｌｉｅｎｔ）―は、新しいリクエストを作成し、クライアントトランザクション状態機構を用いてそれを送信する論理要素である）。ｔａｇは、識別の目的のために用いられる。例えば、「ダイアログ」、すなわち、ピアツーピアのＳＩＰ関係は、「Ｔｏ」タグ、「Ｆｒｏｍ」タグ、および「Ｃａｌｌ−ＩＤ」フィールドの値の組み合わせにより一意的に識別される。「Ｆｒｏｍ」タグパラメータは実装時定義である。
【００１５】
「Ｔｏ」ヘッダフィールドは、リクエストメッセージの目的であるユーザまたはリソースを識別するＵＲＩを含む。リクエストがダイアログに関係する場合、「ｔａｇ」パラメータは含まれてよい。
【００１６】
「Ｃａｌｌ−ＩＤ」ヘッダフィールドは、グループ化された一連のメッセージを識別する一意的な文字列を提供する。例えば、ダイアログ内のユーザエージェントにより送信されるすべてのリクエストおよびレスポンスは、同一のＣａｌｌ−ＩＤを共用する。Ｃａｌｌ−ＩＤヘッダは実装時定義である。典型的には、このフィールドは、暗号化されたランダムな文字列で設定される。しかし、用いられる正確な文字列は、その識別機能を果たすことが可能であるという条件でのみ、任意のものである。
【００１７】
発明者らの方法によれば、情報は、上述のヘッダフィールドなどの実装時定義のヘッダフィールドに埋め込まれる。図１を参照すると、埋め込むべき情報が取得され（ブロック１０）、例えば公開鍵Ｋ１を用いて暗号化される（ブロック２０）。暗号化の結果を用いて、ＳＩＰメッセージの１つまたは複数の実装時定義のヘッダフィールドを設定する（ブロック３０）。ヘッダフィールド内に設定されるため、暗号化された情報は、例えば、あたかもランダムな文字列かのように識別子として働くことが可能である。埋め込み情報を持つヘッダまたはヘッダ群を含むＳＩＰメッセージは、開始ＳＩＰエージェントから目的のＳＩＰエージェントへ送信される（ブロック４０）。送信の際、暗号化された情報は、ＳＩＰプロトコルに準拠して、例えばランダムな識別文字列として扱われ、通常、なんらかの情報コンテンツのために読み込まれることはない。
【００１８】
しかし、目的のエンドポイントにおけるＳＩＰエージェント、またはエンドポイント間の経路における１つまたは複数の仲介ＳＩＰエージェントは、ヘッダから埋め込み情報を回復させるために、後続の処理のため特定のヘッダを格納するように指図されてよい。
【００１９】
上述のように、「ｂｒａｎｃｈ」パラメータは、文字列「ｚ９ｈＧ４ｂＫ」を前に置かなければならない。したがって、暗号化された情報がｂｒａｎｃｈパラメータフィールド内に設定される場合、この文字列が暗号化されていない形で前に付加される必要がある。
【００２０】
（任意の適切なフィールド内に埋め込まれる）暗号化された情報をあるパターンで前に付加することは有利であり、この暗号化された情報は、本明細書では「冒頭検索文字列」と称し、回復されるべき情報の存在を示す。このような文字列の使用は、実際には埋め込み情報を含まないヘッダフィールドを復号化する無駄な試みを防ぐことができる。
【００２１】
任意の様々な知られた方法が、公開鍵Ｋ１および冒頭検索文字列の交換のために用いられてよい。これらは、とりわけセキュアな電話通話およびセキュアな電子メール送信を含む。
【００２２】
冒頭検索文字列の有用性は、前に付加されたデータのフォーマットに対するインデックスであるようにそれを設計することにより拡張可能である。冒頭検索文字列のフォーマットに関する制約は（影響を受けるヘッダフィールドにＳＩＰプロトコルにより課せられる可能性があるもの以外には）原理上は存在しないが、実用面では少なくとも４文字の長さの文字列を用いることが有利であることが多い。
【００２３】
以下に発明者らは、暗号化された情報の３つの可能なフォーマットの例を提示し、これらを発明者らはそれぞれＳ１、Ｓ２、およびＳ３と称する。発明者らはまた、冒頭検索文字列の可能なフォーマットを説明し、これらを発明者らはパターン１、パターン２、およびパターン３とそれぞれ称する。冒頭検索文字列は、ユーザ定義であり、それらが関係する通信に先立ち決定される。
【００２４】
これら３つの例示のフォーマットは、以下に表で要約される。
【表１】
2009518958.tif 000003
【００２５】
発明者らが「パラメータ値の対」と称するフォーマットの種類を用いて、ユーザ定義のパラメータの値を渡す。対応する構造Ｓ１は、以下の表により表される種類である。
【表２】
2009518958.tif 000004
【００２６】
例えば冒頭文字が「Ａ」である場合、このフォーマットを用いて通知を送信可能である。１つのＳＩＰエージェントが他から情報を必要とするとき、冒頭文字は、例えば、「ｒｅｑｕｅｓｔ」の「Ｒ」であってよい。１つのＳＩＰエージェントが他に応答するときには、冒頭文字は「ｒｅｐｌｙ」の「Ｐ」であってよい。
【００２７】
冒頭文字に続くフィールドは、コンマで区切られた一連のパラメータ値の対を含む。
【００２８】
発明者らが「命令」と称するフォーマットの種類を用いて命令を送信し、これは１つまたは複数の引数をとってよい。対応する構造Ｓ２は、以下の表により表される種類である。
【表３】
2009518958.tif 000005
【００２９】
冒頭文字は、例えば値「Ｃ」をとり、それに続くデータがコマンドを表すことを示してよい。冒頭文字に続くフィールドは、命令の名前を含み、この名前に、適宜、コンマで区切られた引数１、引数２等の引数のリストが続く。
【００３０】
発明者らが「メッセージ」と称するフォーマットの種類を用いて、任意の種類のメッセージまたは文字列を送信する。対応する構造Ｓ３は、以下の表により表される種類である。
【表４】
2009518958.tif 000006
【００３１】
冒頭文字は、例えば値「Ｍ」をとり、「メッセージ」を意味してよい。冒頭文字に続くフィールドは、送信するメッセージまたは文字列を含む。
【００３２】
１つのヘッダを用いてすべての埋め込み情報を含んでよく、または、情報は多数のヘッダにわたり埋め込まれてよい。しかし、例えば情報が複数のＶｉａヘッダにわたり分散されている場合、埋め込み情報を受信するように指定されたＳＩＰエージェントは、単一のＶｉａヘッダのみではなく、多数のＶｉａヘッダを取り除き処理せねばならない。これは、埋め込み情報を含むＶｉａヘッダのうち、１つだけ除いてすべてが、ＳＩＰエージェントがいずれの方向のＳＩＰメッセージも処理してそのＳＩＰメッセージから取り除くダミーのヘッダであることを意味する。
【００３３】
適切なＳＩＰエージェントに属するダミーではないＶｉａヘッダが上にあり、適切なＳＩＰエージェントがダミーのヘッダを処理する方法を認識している場合、ダミーのＶｉａヘッダはダミーのドメイン名を含んでよい。埋め込み情報を受信する対象とされている目的のＳＩＰエージェントも、ダミーのＶｉａヘッダを処理し取り除く方法を認識しなければならない。
【００３４】
「Ｔｏ」、「Ｆｒｏｍ」、および「Ｃａｌｌ−ＩＤ」ヘッダ内の埋め込み情報は、非常に多数のそれらの種類のヘッダはＳＩＰプロトコルが失敗する原因となるため、それらの各種類の複数のヘッダにわたり分散できない。
【００３５】
「Ｔｏ」および「Ｆｒｏｍ」ヘッダでは、情報は、それを「Ｔａｇ」フィールド内に挿入することにより埋め込まれている。すなわち、これらのヘッダは、「ｔａｇ＝値」の形の文字列を含む。埋め込み情報は、「値」と称される位置に挿入される。
【００３６】
「Ｃａｌｌ−ＩＤ」フィールドは、「ａｂｃｄ＠ｄｏｍａｉｎ．ｃｏｍ」という形の文字列を含む。情報を「＠」記号の前に挿入することにより、すなわち情報を「ａｂｃｄ」と称される位置に挿入することにより、情報はこのフィールド内に埋め込み可能である。
【００３７】
埋め込み情報の対象受信者であるＳＩＰエージェントにより受信されると、ヘッダは後続の処理のために格納される。後続の処理は例えば、冒頭検索文字列を有するヘッダフィールドを選択すること、およびそれらを復号化して埋め込み情報を回復することを含む。
【図面の簡単な説明】
【００３８】
【図１】本明細書で説明される方法による情報の送信における一連のステップを示す流れ図である。
【図１】
2009518958.tif 000007
【国際調査報告】
2009518958.tif 000008
2009518958.tif 000009