説明

異種通信ノードを特徴付けるための方法およびシステム

【課題】エンドユーザのために可能な限り透過的に異種IP環境(IPv4とIPv6)に位置するクライアント間で相互作用を可能とする。
【解決手段】本発明は、異種ノード間でデータを送信する方法に関する。本発明による方法は、前記ノード間で通信セッションを設定する前に、前記ノードのうち1つにおいて、ユーザエージェントによって送信されるメッセージ(RE(1),I(1))内にタイプ指示子を挿入するステップを含み、前記タイプ指示子は前記ユーザエージェント(A)と対応付けられたアドレスのタイプを表わす。本発明は、必要ならば、非互換性を解決する目的で、互いに通信することを要求している2つのタイプのユーザエージェント(A,B)の間の非互換性の危険性を即座に識別する。IPネットワークにおいてIPv4、IPv6、または、デュアルスタック(DS)のユーザエージェントの相互通信に適用される。

【発明の詳細な説明】
【技術分野】
【0001】
本発明の分野は通信の分野であり、より詳しくはIP電話の分野である。
【背景技術】
【0002】
インターネットプロトコル(IP)ネットワークは、多数のサービスおよびアプリケーションのための普遍的な媒体としてますます使用されている。IPは、このプロトコルを選択する多くの通信事業者のために、以前の異種サービスの提供を共通化して統合する役割を果たしてきた。
インターネットプロトコルのIPv4バージョンは何年も使用されてきた。
そのような通信サービスによって強いられる制約にかなうために、より詳しくは、アドレスに関して増加する要求条件を受け入れるために、通信事業者およびネットワーク設備製造業者は協力してIPv6として知られる新たな世代の通信プロトコルを規定した。IPv6は、現在、通信事業者のネットワークにおいて運用の配備を構想することが可能な程度に十分に発展した開発段階にある仕様書および分析書類によって定義されている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2003−174466号公報
【特許文献2】特開2000−270024号公報
【特許文献3】国際公開第03/021911号
【発明の概要】
【発明が解決しようとする課題】
【0004】
それにもかかわらず、この新たな世代のプロトコルの導入は、IPv6プロトコルと、IPネットワークに既に配備されたIPv4プロトコルとの間の相互運用および相互作用を保証するニーズに関する重大な問題を引き起こしている。この技術の現在の状態におけるそれらの課題への解決策は特定されているが、(特にアプリケーション層における)“サービス”レベルだけでなく(IP層における)“トランスポート”レベルにおいて影響を及ぼす欠点を有する。トランスポート層において、IPv4データグラム内にIPv6データをカプセル化する、または、その逆のNAT−PT(Network Address Translation - Protocol Translation)技術および各種のトンネル技術のようなメカニズムがIETF(Internet Engineering Task Force)によって提案され標準化されてきた。
さらに、アーキテクチャおよびサービスプラットフォームは、エンドユーザのために可能な限り透過的に異種IP環境(IPv4とIPv6)に位置するクライアント間で相互作用を可能とするように更新および適合されなければならない。
【0005】
他のマルチメディア機能の中で、IETFはSIP(Session Initiation Protocol)を標準化し、その主要な機能はマルチメディアセッションを開始、変更、および終了することである。SIPは、本発明の適用の興味深い例である。それは関係のあるセッションに関するパラメータの記述を生成するためにSDP(Service Description Protocol)に基づく。2者間の呼へのネゴシエーションが成功すると、両者はRTP(Real-time Transport Protocol)を起動することによってメディアストリームを交換することができる。RTPセッションパラメータはSIPシグナリングメッセージによって、特にSDP部において事前にネゴシエーションされる。それらは主に、設定される通信リンクの両端において使用される末端のアドレスおよびポート番号である。
【0006】
SIPの最初のバージョンはRFC(Request For Comments)2543に記載されているので、IPv6と互換性を有する。理論上は、SIPの実装はIPv4およびIPv6のアドレスを容易にデコードし、“CONTACT”ヘッダまたはSDP部のヘッダのような特定のフィールド内に導入することができる。しかし、そのようなアドレスの存在は、両方の端末が同一のIP環境において交信することができないとき、すなわち、一方がIPv4アドレスを有し、他方がIPv6アドレスを有するとき、SIP呼が設定されることを妨げうる。従って、IPv4ユーザエージェントAが、(“レジストラ”Rとしても知られる)IPv4ロケーションサーバに登録されたIPv6ユーザエージェントとのSIPセッションを開始するとき、結果として生じるSIPメッセージの交換は、図1aに表わされている通りであり、ここで、第2のユーザエージェントBとの交信を求める第1のユーザエージェントAは、それに固有のIPv4アドレスを使用してプロキシサーバPSに“INVITE”メッセージを送信する。ここで、プロキシサーバPSはIPv4のみの環境に接続している。そのメッセージがプロキシサーバPSによって受信されると、プロキシサーバは、第2のユーザエージェントBのアドレスを取得するために、登録サーバとしても知られるロケーションサーバにクエリーを送信する。そのアドレスがIPv6アドレスであると仮定すると、プロキシサーバPSがIPv4のみのタイプであるならば、プロキシサーバPSはその宛先への経路を知らない。そして、第1および第2のユーザエージェントAおよびBの間にSIPセッションを設定することが不可能であることを示すエラーメッセージがユーザエージェントAに送信される。このエラーメッセージは、図1aに表わされているように、“(2) 404 No Route”メッセージである。
【0007】
ここで、プロキシサーバPSは、それにもかかわらず、第2のユーザエージェントBとともに第1のユーザエージェントAのロケーションアドレスと交信することができると仮定すると、図1bに表わされているように、第2のユーザエージェントBが第1のユーザエージェントAを呼び出すことを試みるもう1つのSIPメッセージの交換が発生する。
この場合において、プロキシサーバPSは、第2のユーザエージェントBから受信した“INVITE”メッセージを第1のユーザエージェントAのロケーションアドレスにルーティングする。この“INVITE”メッセージは、第2のユーザエージェントBによって提供されるコーデック(符号化器/復号化器)、RTPポート番号、第2のユーザエージェントBがRTPストリームを送受信するために使用できるアドレスに加えて、SDP offerの記述を含む。図1bにおいて、そのアドレスはIPv6アドレスである。従って、ユーザエージェントAがこの“INVITE”メッセージを受信するとき、それはIPv4クライアントであるので、セッションのオープンを拒否することのみ可能である。それがどのように実装されるかに応じて、良くてユーザエージェントBのIPアドレスにネットワーク接続をサポートしないことを示すエラーメッセージを返送しうる。従って、図1aおよび1bを参照して説明したいずれの例もSIPセッションを設定することができない。
【0008】
異なるタイプのIPアドレスの共存は、図示し上述した以外に呼に影響しうる。従って、デュアルスタック(DS)クライアントへの呼はメディアストリームの交換において終了することを失敗しうる。DSユーザエージェントはIPv4およびIPv6アドレスの両方のタイプを処理することが可能である。これは、基本的なSIPがメディアストリームを送信または受信するためにただ1つのIPアドレスを与えることを許すためである。この課題を解決するために、RFC4092は1つまたは複数のアドレスのタイプをユーザエージェントが通知および/または発見することを可能とする“sdp-agent”フラグを示す新たな一貫した意味論を導入している。従って、DSユーザエージェントは、それらのSDP offer内にIPv4アドレスとIPv6アドレスの両方を示すことができる。この技術によって、DSユーザエージェントから単一バージョンのクライアント(すなわち、IPv4プロトコルのみ、または、IPv6プロトコルのみと互換性があるクライント)へ、または、単一バージョンのクライアントからDSユーザエージェントへの全ての呼は、成功したSIPセッション内で終了することができる。
【0009】
所定の呼を伝達することを意図する通信リンクの端における2つのノードが単一バージョンのノードである場合において、関係するSIP電話サービス通信事業者は、サポートされるアドレスのタイプと受信したSIPメッセージ内に含まれるタイプとの間の一貫性を保証するようにSDP offerを変更するために、アプリケーションレベルゲートウェイ(ALG)アプリケーションを使用することができる。この目的のために、SIPサーバは、呼をルーディングするために、または、SDP offerの内容を変更するためにALGアプリケーションを使用することを決定するために、SIPに固有でないトランスポート層に関する情報を使用する。SIPサーバのそのような動作は、標準規格によってカバーされていない。
概して、2つの異種ユーザエージェント(すなわち、異なるIPタイプのユーザエージェント)を相互接続させることに関する課題は、通信コミュニティによって詳細に検討されていない。特に、課題の一部を解決するRFC4091およびRFC4092に記載されたANAT(Alternative Network Address Types)提案は別として、2つの異なるIP環境において2つのユーザエージェントを接続する呼をルーティングするためのSIPサーバの動作を記載したIETFドキュメントは存在しない。
【0010】
さらに、既存の技術は次の欠点を有する。
・ALGアプリケーションおよび付加機能を使用することは文書化されていない。プロキシサーバPSは、この作業を容易にするためにRFC3261によって指定された手段を有さない。
・プロキシサーバPSは、サービス層に関する決定を行うために(この明細書においてはトランスポート層としても参照される)ネットワーク層からの情報を使用しなければならない。従って、メッセージのソースアドレス、プロキシサーバに接続し、または、SDP部を検査するために使用されるアドレス以外を考慮しなければならない。これは、サービスレベルの情報のみを処理するために先験的に構成されるプロキシの性能を劣化させる危険にさらす。
・これらのアドレスの使用は効率化されていない。成功したセッションを獲得する1つの方法は、SDPネゴシエーションが常に成功するように、呼に関与する両方のユーザエージェントが2つのタイプのアドレスを有することを可能とすることであるが、これは、(特に、IPv4の)通信事業者に利用可能なアドレス空間の使用の効率化に課題を引き起こす。
・解決策は包括的でない。プロキシサーバPSによる呼のルーティングおよび介在の原理は、トランスポートレベルにおいて配備される相互接続の解決策に依存する。
・プロキシサーバPSは、ユーザエージェントがIPv4、IPv6、または、DSタイプであるか判定するための手段を有さない。
【課題を解決するための手段】
【0011】
発明者らの検討は、上記検討から生じるニーズに逆らうことなく、IP通信ネットワーク内の通信手段が所定のユーザエージェントに対応付けられたアドレスのタイプを識別することを可能とする簡単な方法が現在の技術に存在しないという結論に導いた。これは、現在検討中の異種ノード間の呼を管理するための大多数の技術がなぜ不十分であるか、異種の呼を可能とするサービス要件になぜ対応しないかを説明している。
所定のユーザエージェントによってサポートされるアドレスのタイプを容易に識別することを可能とする送信方法の提案において、本発明は上記欠点を有さない解決策を提供する。
【0012】
異種ノード間でデータを送信するための本発明による方法は、前記ノード間で通信セッションを設定する前に、前記ノードのうち1つにおいて、ユーザエージェントによって送信されるメッセージ内にタイプ指示子を挿入するステップを含み、前記タイプ指示子は、前記ユーザエージェントに対応付けされたアドレスのタイプを表わすことを特徴とする。
本発明は、必要ならば、このような非互換性を克服する目的で、互いに通信する必要がある2つのタイプのユーザエージェントの間の非互換性のリスクを識別する迅速な方法を提供する。
特に、本発明は、ユーザエージェントが同一のタイプであろうと、異なるタイプであろうと、前記サーバが、それらのユーザエージェント間での効果的な通信セッションの設定のために必要なリソースを識別し、適切に配置することを可能とするために、上述したようなプロキシサーバが互いに通信する必要がある2つのタイプのユーザエージェントを迅速に識別することを可能とする。
【0013】
ここで、ユーザエージェントの“タイプ”とは、保有するSIPノードのネットワークインタフェースを介してユーザエージェントが利用することができるインターネットプロトコルの1つまたは複数のバージョン(例えば、IPv4、IPv6)を示す。ノードAの保有するユーザエージェントのタイプが、ノードBの保有するユーザエージェントのタイプと異なるならば、2つのノードAおよびBは異種であると言う。
【0014】
従って、本発明のプロトコルは、タイプ指示子を送信するユーザエージェントを、IPv4のみ、IPv6のみ、または、デュアルスタックの3つのIPタイプに従って分類するステップをさらに含みうる。
本発明の1つの特定の実施形態において、前記挿入するステップは、前記ユーザエージェントの主導で実行される。
これは、ユーザエージェントが、送信または受信する呼を、対応するネットワークインタフェースおよびインターネットプロトコルのタイプに制限することを可能とする。
好ましくは、前記タイプ指示子は、IPv4プロトコル、IPv6プロトコル、または、デュアルスタック(IPv4+IPv6)プロトコルを表わす符号化された数値の形態をとりうる。
そのような数値は、いくつかのビットにたいへん容易に符号化することができ、従って、本発明の実装は、呼の目的のために交換されるメッセージの量において著しい増加は引き起こさない。
【0015】
本発明の第1の効果的な変形において、前記方法は、前記タイプ指示子を、対応付けされたユーザエージェントの識別子とともに記憶するステップをさらに含む。
とりわけ、この記憶するステップは、タイプ指示子が記憶された各ユーザエージェントに対応付けされたIPアドレスのタイプを容易かつ直接に識別するために、データベース内に参照テーブルを生成し更新する。このデータベースは、接続の初期化において各ユーザエージェントによって自発的に与えられ、または、ロケーションサーバによって定期的に更新および管理される。ユーザエージェントは、ロケーションサーバを用いて、通信セッションの初期化において、または、登録期間の満了において登録する。
【0016】
第1の変形に代えて、または、第1の変形とともに使用することができる本発明の第2の効果的な変形において、前記方法は、呼び出しメッセージを送信したユーザエージェントに対応付けされたタイプ指示子と前記呼び出しメッセージの宛先のユーザエージェントに対応付けされたタイプ指示子との間で非互換の場合に、ユーザエージェントとの通信に入るための呼び出しメッセージ内に含まれるアドレスを変換するステップをさらに含みうる。
本発明のこの変形によれば、発信側と着信側のユーザエージェントに対応付けされたタイプ指示子を単に比較することは、発信側と着信側との間で接続を設定する試みが行われる前に、それらの間の非互換性が修復されることを可能とする。
例えば、本発明は、VoIP(Voice over IP)として知られ、または、一般に対話サービスに分類されるIP電話アプリケーションにおいて効果的に使用される。
そして、本発明は、RFC3162によって定義され、IPv4クライアントおよびIPv6クライアントの両方のために配備された、SIPを基にしたシグナリングサービスの一般的な課題に取り組む。これらのサービスは、音声、映像、音響、等のサービスでありうる。
【0017】
上述したように、本発明は、一方がIPv4ドメインに接続し、他方がIPv6ドメインに接続した2つの異種クライアントの間でSIPセッションを設定することを容易にするための簡単なメカニズムを提案する。
本発明を使用することによって、SIPプロキシサーバは、セッションが異種ノード間で設定されることを可能とするために、SIP呼をルーティングし、RFC2327によって定義され、SIPメッセージ内で伝達されるSDP offerの内容を修正する(または、修正を引き起こす)ために介入することができる。一方、本発明が実装されなければ、SIPプロキシサーバは、呼のルーティングの選択を助け、成功したSIPセッションを実現するためにSIPメッセージを修正する責任を持つALGアプリケーションの使用を効率化するために、アプリケーション層以外の情報、特に、ネットワーク層に関する情報にアクセスしなければならない。
同種のプロトコルスタックを使用せず、SIPサーバおよびALGアプリケーションによるそのような介入なしでは、SIPセッションを発生させることはできない。
本発明は、異種SIPノードの相互作用を可能とし、簡単にし、従って、SIP通信システムにおいて呼のルーティングを容易にする。
特に、本発明は、IPアドレスの使用を効率化し、サーバによって受信されるSIPメッセージによって要求される処理を引き起こすために、トランスポート層からの情報に依存するSIPプロキシサーバによるSIPメッセージの処理を必要としない。
【0018】
ここで言及される適用例に固有な一実施形態において、前記タイプ指示子は、SIPクエリーメッセージ内に含まれる“CONTACT”フィールド内に挿入されうる。
タイプ指示子をクエリーメッセージ内に導入することは、ユーザエージェントにおいて利用可能なネットワークインタフェースによってサポートされるIPアドレスのタイプをロケーションサーバおよびプロキシサーバに通知する。さらに、プロキシサーバは、ネットワーク層内の情報にアクセスする必要なく、タイプ指示子を使用してその宛先にルーティングするためにクエリーメッセージを処理することができる。
上述した本発明の第1の変形の上記例への適用を置き換えると、ユーザエージェントが“REGISTER”メッセージ内にタイプ指示子を挿入することが分かる。
従って、“REGISTER”メッセージを受信すると、ロケーションサーバは、登録アドレス、登録有効期限、タイプ指示子を記憶する処理を行う。また、他のデータを記憶することができる。
上述した本発明の第2の変形の上記例への適用を置き換えると、“INVITE”メッセージを送信するユーザエージェントに対応付けされたタイプ指示子と“INVITE”メッセージの宛先のユーザエージェントに対応付けされたタイプ指示子との間で非互換の場合に、プロキシサーバは“INVITE”メッセージ内に含まれるアドレスを変換することが分かる。
そのような非互換性は、特に、“INVITE”メッセージを送信および受信するユーザエージェントが異なるタイプであるとき生じる。
【0019】
本発明のそのような適用は、異なるタイプの2つのユーザエージェントの間で呼のメッセージを修正するためにアプリケーションレベルにおいてゲートウェイを使用して呼のルーティング処理を実行しなければならないプロキシサーバは、
・ロケーションサーバによって更新され、発信側および着信側のユーザエージェントのタイプの特性を含む登録データベース内に記憶された分類に基づいて、
・または、着信側のユーザエージェントのタイプの特性、および、発信側のユーザエージェントによって送信された“INVITE”メッセージ内に含まれるタイプ指示子を含む登録データベース内に記憶された分類に基づいて、
そのような処理を実行する。
上記説明から明らかなように、本発明は、また、上述した適用における実現によって直接に得られる物によって、メッセージを送信するユーザエージェントに対応付けされたIPアドレスの特性を表わすタイプ指示子を含むクエリーメッセージを伝達する信号に関し、メッセージは、例えば、“REGISTER”、“INVITE”、または、“200 OK”とすることができる。タイプ指示子は、特に、“CONTACT”フィールド内に挿入することができる。
【0020】
本発明のハードウェアの態様は、異種ノード間でデータを送信するためのシステムに関し、前記ノード間で通信セッションを設定する前に、前記ノードのうち1つにおいて、ユーザエージェントによって送信されるメッセージ内にタイプ指示子を挿入するための手段を含み、前記タイプ指示子は、前記ユーザエージェントに対応付けされたアドレスのタイプを表わすことを特徴とする。また、そのようなデータ送信システムのノードを構成する端末に関し、前記ノードにおいて、ユーザエージェントによって送信されるメッセージ内にタイプ指示子を挿入するための手段を含み、前記タイプ指示子は、前記ユーザエージェントに対応付けされたアドレスのタイプを表わす。
本発明のこのハードウェアの態様の1つの変形は、前記ユーザエージェントのタイプ指示子に基づいてクエリーメッセージを送信するユーザエージェントを区別および分類するための手段と、前記分類を記憶するように構成されたデータベースと、をさらに含む上記送信システムに関する。
本発明のこのハードウェアの態様のもう1つの変形は、発信側のユーザエージェントおよび着信側のユーザエージェントに固有のタイプ指示子を比較するための手段をさらに含む上記送信システムに関する。
【0021】
実現するために有効な手段を構成する本発明のもう1つの態様は、コンピュータで実行されるとき前記方法のあるステップを実行するための一連のプログラムコード命令を含むコンピュータプログラムに関する。
【図面の簡単な説明】
【0022】
【図1a】先行技術に関する図である。
【図1b】先行技術に関する図である。
【図2】本発明による方法の主要なステップのフローチャートの例を表わす。
【図3】IPv4およびIPv6ユーザエージェントの登録の第1の例を表わす。
【図4】デュアルスタックユーザエージェントの登録の第2の例を表わす。
【図5】ユーザエージェントがロケーションサーバに“REGISTER”メッセージを送信し、プロキシサーバを通して“INVITE”メッセージを渡す場合において動作する、異種SIPノードの相互作用のための本発明によるシステムを表わす。
【発明を実施するための形態】
【0023】
本発明は、添付図面を参照して、限定しない例によって与えられる、続く説明に照らして、より良く理解することができる。
図2および続く図面を参照して、本発明による方法のより詳細な説明が与えられる。
概して、例えば、IPv4、IPv6、または、デュアルスタック(DS)ハイブリッドIP端末によって構成される各々の異種ノードは特定のタイプのユーザエージェントUAを含み、そのタイプは関係する端末に利用可能なネットワークインタフェースを介してユーザエージェントが使用することができるIPのバージョンに対応する。
図2に表わされているように、本発明による方法は、ステップ10において、ユーザエージェントUAによって送信されるクエリーメッセージM内にタイプ指示子“atypes”を挿入する。この挿入の後、クエリーメッセージは、M(“atypes”)と表記される。そのようなクエリーメッセージは、例えば、(“レジストラ”としても知られている)ロケーションサーバRへの登録メッセージを含む。また、プロキシサーバPSに送信されるメッセージ、例えば、他のユーザエージェントとの通信に入ることを促すメッセージが存在しうる。
タイプ指示子が挿入されたメッセージの送信(13)の後、本発明による方法は、含まれるタイプ指示子“atypes”に基づいてクエリーメッセージM(“atypes”)を処理する(11)。この処理は、登録メッセージについてロケーションサーバ、または、他のユーザエージェントとの通信に入ることを促すメッセージについてプロキシサーバでありうる装置12において行われる。
【0024】
プロキシサーバ12において実行される処理11は、プロキシサーバ12がトランスポート層内の情報にアクセスする必要なく、メッセージをルーティングする。
特に、タイプ指示子“atypes”は、この情報をロケーションサーバおよびプロキシサーバ12に提供するために、メッセージを送信するユーザエージェントに利用可能なネットワークインタフェースおよびインターネットプロトコルの特性を表わす符号化された数値データを含み、
・通信することを試みる責任を負う各種のユーザエージェントのタイプについての情報を提供するデータベースを維持するように、ロケーションサーバ12がユーザエージェントの識別子に対応付けられたタイプ指示子の登録11に進むことを可能とし、
・プロキシサーバ12がM(“atypes”)メッセージを送信するために使用されるトランスポート層内の情報にアクセスせずにルーティング11を処理することを可能とすることが理解される。
【0025】
以下、図3および図4を参照して、図2に表わされている本発明による方法のステップ10の実現例を説明する。
1つの特定の類型の実施形態において、タイプ指示子“atypes”はSIPクエリー、特に、“REGISTER”および“INVITE”クエリーの“CONTACT”フィールド内に挿入される。この指示子の定義を説明するために、RFC3162によって定義されている“CONTACT”フィールドのABNF(Augmented Backus-Naur form(拡張バッカス・ナウア記法))記述を以下に示す。
下記のABNF記述において、この技術分野で周知の要素およびRFC3162に記載されている要素は通常の字体、追加の記述要素は太字の字体とした。
新たなABNF記述の全体を下記の表1に示す。
【0026】
【表1】

【0027】
ユーザエージェントは、
・IPv4インタフェースにおいて、
・IPv6インタフェースにおいて、
・または、デュアルスタック(DS)インタフェースが設けられている(すなわち、IPv4およびIPv6の両方のプロトコルバージョンと互換性を有する)ならば、両方のタイプのインタフェースにおいて、
発信呼または着信呼を制限することを要求しうる。
この動作はタイプ指示子“atype”によって通知される。
ユーザエージェントは、タイプ指示子“atype”を適切な値に設定することによって実際の利用可能性を通知しないように構成することができる。設定されたアドレスの1つがグローバルな範囲であるときのみ(IPv6プロトコルは“リンクローカル”および“グローバル”なタイプのアドレスを区別する)、IPv6インタフェースが利用可能であるとみなされる。ローカルな範囲のアドレスは、ルーティングすることができる(すなわち、ローカルなネットワークを越えて接続される)グローバルな範囲のアドレスと異なり、ローカルなネットワークを越えてルーティングすることができない。登録の間に、SIPユーザエージェントは、下記の値
・ユーザエージェントがIPv4のみサポートするならば4、
・ユーザエージェントがIPv6のみサポートするならば6、
・ユーザエージェントがデュアルスタックを利用可能ならば0
をとりうる追加の欄の“atype”を含む表1に記載されているように拡張された“CONTACT”フィールドを有する“REGISTER”メッセージを送信する。
ユーザエージェントは、登録サーバRに送信される“REGISTER”メッセージ内のタイプ指示子“atype”を(例えば、ユーザエージェントがデュアルスタックタイプであっても)4に設定することによってIPv4プロトコルのみサポートすること、または、タイプ指示子“atype”を6に設定することによってIPv6プロトコルのみサポートすること、または、タイプ指示子“atype”を0に設定することによってデュアルスタックプロトコルDSをサポートすることをプロキシサーバPSに通知することができる。
図3において、RおよびR6は、それぞれ、ユーザエージェントAおよびBに対応するロケーションサーバを示す。
【0028】
<IPv4ユーザエージェントの例>
ユーザエージェントAはアドレス192.165.25.2を有するIPv4ユーザエージェントであると仮定する。図3に表わされているように、ユーザエージェントAは、表2に記載されている“(1) REGISTER”メッセージをロケーションサーバRに送信する。
【0029】
【表2】

【0030】
登録サーバRは、表3に記載されている“(2) 200 OK”を用いてユーザエージェントAに応答する。
【0031】
【表3】

【0032】
<IPv6ユーザエージェントの例>
ユーザエージェントBはアドレス2001:688:1ffb:ff80::2を有するIPv6ユーザエージェントであると仮定する。図3に表わされているように、ユーザエージェントBは、表4に記載されている“(1) REGISTER”メッセージをロケーションサーバR6に送信する。
【0033】
【表4】

【0034】
登録サーバR6は、登録を確認するために、表5に記載されている“(2) 200 OK”を用いてユーザエージェントAに応答する。
【0035】
【表5】

【0036】
“CONTACT”フィールド内のIPアドレスは、タイプ指示子“atype”フィールド内に示されている以外のタイプのユニークなアドレスとすることができる。タイプ指示子“atype”を6に設定するユーザエージェントは“CONTACT”フィールド内にIPv4アドレスを使用することができ、タイプ指示子“atype”を0に設定するユーザエージェントは以下で説明するように2つではなく1つのみのアドレスを宣言することができる。“CONTACT”フィールド内に含まれるアドレスは、シグナリングメッセージをルーティングするためにSIPプロキシサーバによって使用される。ユーザエージェントは(プロキシサーバに送信されるメッセージ内に挿入されるタイプ指示子に基づいて、または、このユーザエージェントのためにロケーションサーバによって記憶されたタイプ指示子に基づいて)そのプロキシサーバPSにIPv6ユーザエージェントとして宣言したので、メディアメッセージはIPv6インタフェースを介してユーザエージェントに送信される。
【0037】
<“CONTACT”フィールド内に1つのみのアドレスを有するDSユーザエージェントの例>
図4を参照し、ユーザエージェントはアドレス2001:688:1ffb:ff80::2/192.168.25.5を有するデュアルスタック(DS)ユーザエージェントであると仮定する。図4に表わされているように、登録フェーズの間に、DSユーザエージェントは、表6に記載されている“(1) REGISTER”メッセージをそのロケーションサーバRに送信する。
【0038】
【表6】

【0039】
ロケーションサーバR6は、登録を確認するために、表7に記載されている“(2) 200 OK”メッセージを用いて応答する。
【0040】
【表7】

【0041】
<タイプ指示子“atype”の処理>
“REGISTER”メッセージを受信すると、ロケーションサーバRは、Address of Record(AOR)、登録有効期限、タイプ指示子“atype”を記憶する。このデータ(および、おそらく他のデータ)は、ロケーションサーバによって管理される登録データベース内に記憶される。これは同一のユーザエージェントから到達する他の“REGISTER”メッセージによって更新されうる。この処理は、最初にRFC3261において用意された処理を置き換える。タイプ指示子“atype”からの情報を使用して、ロケーションサーバはそのユーザエージェントを3つのカテゴリ
・IPv4のみ
・IPv6のみ
・デュアルスタック(DS)
に分類する。
この分類は、ロケーションサーバによって管理される登録データベースを検索することによってプロキシサーバに簡単にアクセス可能である。また、以下で説明するように、プロキシサーバのために意図されたメッセージ内にユーザエージェントによって挿入されたタイプ指示子を単に読み出すプロキシサーバによって直接に処理することができる。
また、ユーザエージェントは、それらが“INVITE”メッセージを送信するときに、タイプ指示子“atype”を設定することができる。
【0042】
プロキシサーバPSは下記の場合(ケース1)にそれらの内容を修正せずにSIPメッセージを送信しなければならない。
・IPv4からIPv4へ
・IPv6からIPv6へ
・IPv4からDSへ、および、DSからIPv4へ
・IPv6からDSへ、および、DSからIPv6へ
・DSからDSへ
上記ケース1の場合において、ユーザエージェントは、同一のタイプであり(または、概して、それらは少なくとも1つの共通のタイプを有するので、DSユーザエージェントを用いて、)、従って同一のIPバージョンを使用して対話することできるので、互換性を有すると言う。
【0043】
下記の場合(ケース2)のみ修正が行われた後、SIPメッセージの修正は、同一タイプの着信側および発信側のユーザエージェントのIPアドレスを利用可能にする。
・IPv6からIPv4へ
・IPv4からIPv6へ
上記ケース2の場合において、ユーザエージェントは、同一のタイプでなく、従って通信できないので、互換性を有さないと言う。
呼のルーティング、および、異なるタイプの2つのユーザエージェントの間で成功してセッションを獲得するためにALGアプリケーションを使用するか、または、SIPメッセージを修正する決定のために、プロキシサーバ(PS)は、次のいずれかを行うことができる。
【0044】
<ロケーションサーバによって維持される登録データベースを検査する>
この場合において、プロキシサーバPSは、発信側および着信側のユーザエージェントのタイプについてロケーションサーバRに問い合わせる。すると、プロキシサーバPSは、ケース2の場合の1つであるシナリオにおいて、着信側によってサポートされるアドレスのタイプと一致させるために、SIPメッセージのSDPの内容を修正することを決定することができる。図5に表わされている例は、IPv4ユーザエージェントAとIPv6ユーザエージェントBとの間の呼を通して、この動作モードを説明している。IPv4およびIPv6ネットワークを相互接続する機能はノードINによって表わされ、これは中継局としての役割を果たし、特に、IPv4データグラムとIPv6データグラムとの間でプロトコル変換を実行する。
ユーザエージェントBはIPv6ユーザエージェントであると仮定する。サービスの開始において、ユーザエージェントBはタイプ指示子“atype”を6に設定してロケーションサーバRに設定されており、ユーザエージェントAはタイプ指示子“atype”を4に設定してロケーションサーバRに設定されている。簡単のために、この前置きの登録フェーズは図5に表わされていない。
ユーザエージェントBは、NAT−PTメカニズムのようなIPv6−IPv4相互接続メカニズムによってIPv4アドレスに変換されたIPv6アドレスによってIPv6環境内で知られている。そして、ユーザエージェントBはIPv6ユーザエージェントとして識別され、ユーザエージェントAはIPv4ユーザエージェントとして識別される。ユーザエージェントAがユーザエージェントBとのセッションを設定することを要求しているならば、下記のSIPメッセージが交換される。
・RE(1) ユーザエージェントAはプロキシサーバPSに“INVITE”メッセージを送信する。
・RE(2) プロキシサーバPSは、ユーザエージェントBのロケーションアドレス、および、登録の間に指定されたユーザエージェントAおよびBのタイプ指示子“atype”についてロケーションサーバRに問い合わせる。
・RE(3) ロケーションサーバRは、ユーザエージェントBのアドレス、ユーザエージェントBのタイプ指示子“atype”、ユーザエージェントAのタイプ指示子“atype”を返送する。
・RE(4) プロキシサーバPSは、ユーザエージェントAおよびBの2つのタイプ指示子“atype”を比較する。ロケーションサーバRにおいて利用可能な分類のタイプに基づいて、プロキシサーバPSは、AがIPv4ユーザエージェントであり、BがIPv6ユーザエージェントであることを確認する。そして、プロキシサーバPSは、適合させるメカニズムに、IPv6アドレスを含むようにユーザエージェントAの最初のSDP offerを修正させる。そして、プロキシサーバPSは、修正された“INVITE”メッセージをロケーションサーバRによって指定されたユーザエージェントBのアドレスに送信する。
この手順なしでは、プロキシサーバPSは、ユーザエージェントBに呼をルーティングする手段、および、ユーザエージェントBへのメッセージの正しいルーティングのために必要な、適合させる機能を起動するための手段を有さない。プロキシサーバPSは、それを修正することなくユーザエージェントBにクエリーを返送し、この場合においてユーザエージェントAおよびBの間のSIPセッションは生じえない(図1bを参照)。
【0045】
<または、登録データベース、および、“INVITE”メッセージ内で伝達されるタイプ指示子“atype”を検査する>
この場合において、プロキシサーバPSは、着信側のユーザエージェントBのタイプについてロケーションサーバRに問い合わせる。発信側のユーザエージェントAのタイプは、送信された“INVITE”メッセージから導き出される。そして、プロキシサーバPSは、着信側のユーザエージェントBによってサポートされるアドレスのタイプと一致させるために、SIPメッセージの内容を修正することを決定することができる。このシナリオは、ケース2の場合の1つである。このオプションのために、ユーザエージェントは、各セッションについて使用されるアドレスのタイプを制限することができる。図5を参照して説明される例は、IPv4ユーザエージェントとIPv6ユーザエージェントとの間の呼を通して、他の動作モードを説明している。
ユーザエージェントBはIPv6ユーザエージェントであると仮定する。サービスの開始において、ユーザエージェントBはタイプ指示子“atype”を6に設定してロケーションサーバRに設定されており、ユーザエージェントAはタイプ指示子“atype”を4に設定してロケーションサーバRに設定されている。ここで、ユーザエージェントBはIPv6ユーザエージェントとして識別され、ユーザエージェントAはIPv4ユーザエージェントとして識別される。ユーザエージェントAがユーザエージェントBとのセッションの設定を要求しているならば、下記のSIPメッセージが交換される。
・I(1) ユーザエージェントAはプロキシサーバPSに“INVITE”メッセージを送信する。
・I(2) プロキシサーバPSは、ユーザエージェントBのロケーションアドレス、および、登録の間に指定されたユーザエージェントBのタイプ指示子“atype”についてロケーションサーバRに問い合わせる。
・I(3) ロケーションサーバRは、ユーザエージェントBのアドレスおよびタイプ指示子“atype”を返送する。
・I(4) プロキシサーバPSは、“I(1)INVITE”クエリーからユーザエージェントAのタイプ指示子“atype”を抽出し、それをユーザエージェントBのタイプ指示子“atype”と比較する。ロケーションサーバRにおいて利用可能な分類のタイプに基づいて、プロキシサーバPSは、ユーザエージェントAがIPv4ユーザエージェントであり、ユーザエージェントBがIPv6ユーザエージェントであることを確認する。そして、プロキシサーバPSは、適合させるメカニズムに、IPv6アドレスを含むようにユーザエージェントAの最初のSDP offerを修正させる。そして、プロキシサーバPSは、修正された“INVITE”メッセージをロケーションサーバRによって指定されたユーザエージェントBのアドレスに送信する。
【0046】
図5に表わされているプロトコルを使用するために、プロキシサーバPSは、好ましくは、発信側のユーザエージェントおよび着信側のユーザエージェントと対応付けされたタイプ指示子を比較するためのモジュールMを含む。モジュールMが発信側および着信側のユーザエージェントが異なるタイプであると判定したならば、プロキシサーバは発信側のユーザエージェントのIPアドレスを修正するためのリソースを呼び出すためにモジュールMを起動させる。修正するためのリソースはプロキシサーバPSの外部に存在し、図5には表わされていない。モジュールMおよびMは、コンピュータプログラムの形態で実現することができる。簡単のために、それらは、図5において同一の英数字の参照符号で示されている。
【0047】
本発明は、さらに、IP端末のIPv4、IPv6、または、デュアルスタックのユーザエージェントのような、コンピュータまたは専用装置によって実行するためのコンピュータプログラムMを含む。コンピュータプログラムMが実行されるとき、そのコード命令は、上述し、図2、3、4に表わされているように、そのユーザエージェントUA内で利用可能なネットワークインタフェースによってサポートされる1つまたは複数のIPアドレスのタイプを表わすタイプ指示子“atype”をユーザエージェントUAによって送信されるクエリーメッセージ内に挿入する。
上述したように、本発明は、さらに、プロキシサーバPSのような、コンピュータまたは専用装置によって実行するための一連の命令を含むコンピュータプログラムM、Mを含む。コンピュータプログラムM、Mが実行されるとき、それらの命令は、ユーザエージェントによってプロキシサーバに送信され、そのユーザエージェント内で利用可能なネットワークインタフェースによってサポートされる1つまたは複数のIPアドレスのタイプを表わすタイプ指示子“atype”を含むクエリーメッセージを処理する。このような処理は、上述し、図2から5に表わされているように、トランスポート層内に含まれる情報へのアクセスなしでその宛先にクエリーメッセージをルーティングする。
本発明は、また、ロケーションサーバRのような、コンピュータまたは専用装置によって実行するためのコード命令を含むコンピュータプログラムMを含む。コンピュータプログラムMが実行されるとき、その命令は、ユーザエージェントによって送信される登録メッセージからタイプ指示子を抽出し、登録データベース内に、関係するユーザエージェントの識別子に関するタイプ指示子を記憶する。また、それらは、上述し、図2から5に表わされているように、関係するユーザエージェントを3つのIPカテゴリ(IPv4、IPv6、デュアルスタック)のうち1つに分類する。
【符号の説明】
【0048】
PS プロキシサーバ
R ロケーションサーバ
UA ユーザエージェント

【特許請求の範囲】
【請求項1】
発信側および着信側のユーザエージェントの間でSIP呼をルーティングする手段を備えるプロキシサーバであって、
前記2つのユーザエージェントのIPアドレスのタイプ(IPv4、IPv6、またはデュアルスタック)を識別する手段をさらに備え、前記識別は、
・現在の呼の目的のために、または事前に、発信側のユーザエージェントによって送信されるSIPクエリーメッセージ内に含まれる“CONTACT”フィールド内に含まれるIPアドレスのタイプ指示子、および、
・着信側のユーザエージェントのタイプを含む登録データベース内に記憶された分類に基づき、
前記2つのユーザエージェントの間の通信セッションの効果的な設定のために必要なリソースを識別し、適切に配置する手段をさらに備えることを特徴とするプロキシサーバ。
【請求項2】
ロケーションサーバによって更新され、発信側および着信側のユーザエージェントのタイプを含む登録データベース内に記憶された分類に基づいて前記2つのユーザエージェントのタイプを識別する手段をさらに備えることを特徴とする請求項1に記載のプロキシサーバ。
【請求項3】
互いに異なるタイプを有する2つのユーザエージェントの間のSIPメッセージ内で伝達されるSDP offerの内容を修正する、または修正を引き起こす手段をさらに備えることを特徴とする請求項1に記載のプロキシサーバ。

【図1a】
image rotate

【図1b】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate


【公開番号】特開2012−100293(P2012−100293A)
【公開日】平成24年5月24日(2012.5.24)
【国際特許分類】
【出願番号】特願2011−270289(P2011−270289)
【出願日】平成23年12月9日(2011.12.9)
【分割の表示】特願2008−556827(P2008−556827)の分割
【原出願日】平成19年2月15日(2007.2.15)
【出願人】(591034154)フランス・テレコム (290)
【Fターム(参考)】