発信側および着信側のユーザエージェントの間でSIP呼をルーティングする手段を備えるプロキシサーバであって、前記2つのユーザエージェントのIPアドレスのタイプIPv4、IPv6、またはデュアルスタックを識別する手段をさらに備え、前記識別は、現在の呼の目的のために、または事前に、発信側のユーザエージェントによって送信されるSIPクエリーメッセージ内に含まれるCONTACTフィールド内に含まれるIPアドレスのタイプ指示子、および、着信側のユーザエージェントのタイプを含む登録データベース内に記憶された分類に基づき、前記2つのユーザエージェントの間の通信セッションの効果的な設定のために必要なリソースを識別し、適切に配置する手段をさらに備えることを特徴とするプロキシサーバ。ロケーションサーバによって更新され、発信側および着信側のユーザエージェントのタイプを含む登録データベース内に記憶された分類に基づいて前記2つのユーザエージェントのタイプを識別する手段をさらに備えることを特徴とする請求項1に記載のプロキシサーバ。互いに異なるタイプを有する2つのユーザエージェントの間のSIPメッセージ内で伝達されるSDPofferの内容を修正する、または修正を引き起こす手段をさらに備えることを特徴とする請求項1に記載のプロキシサーバ。それにもかかわらず、この新たな世代のプロトコルの導入は、IPv6プロトコルと、IPネットワークに既に配備されたIPv4プロトコルとの間の相互運用および相互作用を保証するニーズに関する重大な問題を引き起こしている。この技術の現在の状態におけるそれらの課題への解決策は特定されているが、特にアプリケーション層におけるサービスレベルだけでなくIP層におけるトランスポートレベルにおいて影響を及ぼす欠点を有する。トランスポート層において、IPv4データグラム内にIPv6データをカプセル化する、または、その逆のNAT-PTNetworkAddressTranslationProtocolTranslation技術および各種のトンネル技術のようなメカニズムがIETFInternetEngineeringTaskForceによって提案され標準化されてきた。さらに、アーキテクチャおよびサービスプラットフォームは、エンドユーザのために可能な限り透過的に異種IP環境IPv4とIPv6に位置するクライアント間で相互作用を可能とするように更新および適合されなければならない。他のマルチメディア機能の中で、IETFはSIPSessionInitiationProtocolを標準化し、その主要な機能はマルチメディアセッションを開始、変更、および終了することである。SIPは、本発明の適用の興味深い例である。それは関係のあるセッションに関するパラメータの記述を生成するためにSDPServiceDescriptionProtocolに基づく。2者間の呼へのネゴシエーションが成功すると、両者はRTPRealtimeTransportProtocolを起動することによってメディアストリームを交換することができる。RTPセッションパラメータはSIPシグナリングメッセージによって、特にSDP部において事前にネゴシエーションされる。それらは主に、設定される通信リンクの両端において使用される末端のアドレスおよびポート番号である。SIPの最初のバージョンはRFCRequestForComments2543に記載されているので、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に表わされているように、404NoRouteメッセージである。ここで、プロキシサーバ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ストリームを送受信するために使用できるアドレスに加えて、SDPofferの記述を含む。図1bにおいて、そのアドレスはIPv6アドレスである。従って、ユーザエージェントAがこのINVITEメッセージを受信するとき、それはIPv4クライアントであるので、セッションのオープンを拒否することのみ可能である。それがどのように実装されるかに応じて、良くてユーザエージェントBのIPアドレスにネットワーク接続をサポートしないことを示すエラーメッセージを返送しうる。従って、図1aおよび1bを参照して説明したいずれの例もSIPセッションを設定することができない。異なるタイプのIPアドレスの共存は、図示し上述した以外に呼に影響しうる。従って、デュアルスタックDSクライアントへの呼はメディアストリームの交換において終了することを失敗しうる。DSユーザエージェントはIPv4およびIPv6アドレスの両方のタイプを処理することが可能である。これは、基本的なSIPがメディアストリームを送信または受信するためにただ1つのIPアドレスを与えることを許すためである。この課題を解決するために、RFC4092は1つまたは複数のアドレスのタイプをユーザエージェントが通知および/または発見することを可能とするsdpagentフラグを示す新たな一貫した意味論を導入している。従って、DSユーザエージェントは、それらのSDPoffer内にIPv4アドレスとIPv6アドレスの両方を示すことができる。この技術によって、DSユーザエージェントから単一バージョンのクライアントすなわち、IPv4プロトコルのみ、または、IPv6プロトコルのみと互換性があるクライントへ、または、単一バージョンのクライアントからDSユーザエージェントへの全ての呼は、成功したSIPセッション内で終了することができる。所定の呼を伝達することを意図する通信リンクの端における2つのノードが単一バージョンのノードである場合において、関係するSIP電話サービス通信事業者は、サポートされるアドレスのタイプと受信したSIPメッセージ内に含まれるタイプとの間の一貫性を保証するようにSDPofferを変更するために、アプリケーションレベルゲートウェイALGアプリケーションを使用することができる。この目的のために、SIPサーバは、呼をルーディングするために、または、SDPofferの内容を変更するためにALGアプリケーションを使用することを決定するために、SIPに固有でないトランスポート層に関する情報を使用する。SIPサーバのそのような動作は、標準規格によってカバーされていない。概して、2つの異種ユーザエージェントすなわち、異なるIPタイプのユーザエージェントを相互接続させることに関する課題は、通信コミュニティによって詳細に検討されていない。特に、課題の一部を解決するRFC4091およびRFC4092に記載されたANATAlternativeNetworkAddressTypes提案は別として、2つの異なるIP環境において2つのユーザエージェントを接続する呼をルーティングするためのSIPサーバの動作を記載したIETFドキュメントは存在しない。さらに、既存の技術は次の欠点を有する。ALGアプリケーションおよび付加機能を使用することは文書化されていない。プロキシサーバPSは、この作業を容易にするためにRFC3261によって指定された手段を有さない。プロキシサーバPSは、サービス層に関する決定を行うためにこの明細書においてはトランスポート層としても参照されるネットワーク層からの情報を使用しなければならない。従って、メッセージのソースアドレス、プロキシサーバに接続し、または、SDP部を検査するために使用されるアドレス以外を考慮しなければならない。これは、サービスレベルの情報のみを処理するために先験的に構成されるプロキシの性能を劣化させる危険にさらす。これらのアドレスの使用は効率化されていない。成功したセッションを獲得する1つの方法は、SDPネゴシエーションが常に成功するように、呼に関与する両方のユーザエージェントが2つのタイプのアドレスを有することを可能とすることであるが、これは、特に、IPv4の通信事業者に利用可能なアドレス空間の使用の効率化に課題を引き起こす。解決策は包括的でない。プロキシサーバPSによる呼のルーティングおよび介在の原理は、トランスポートレベルにおいて配備される相互接続の解決策に依存する。プロキシサーバPSは、ユーザエージェントがIPv4、IPv6、または、DSタイプであるか判定するための手段を有さない。発明者らの検討は、上記検討から生じるニーズに逆らうことなく、IP通信ネットワーク内の通信手段が所定のユーザエージェントに対応付けられたアドレスのタイプを識別することを可能とする簡単な方法が現在の技術に存在しないという結論に導いた。これは、現在検討中の異種ノード間の呼を管理するための大多数の技術がなぜ不十分であるか、異種の呼を可能とするサービス要件になぜ対応しないかを説明している。所定のユーザエージェントによってサポートされるアドレスのタイプを容易に識別することを可能とする送信方法の提案において、本発明は上記欠点を有さない解決策を提供する。異種ノード間でデータを送信するための本発明による方法は、前記ノード間で通信セッションを設定する前に、前記ノードのうち1つにおいて、ユーザエージェントによって送信されるメッセージ内にタイプ指示子を挿入するステップを含み、前記タイプ指示子は、前記ユーザエージェントに対応付けされたアドレスのタイプを表わすことを特徴とする。本発明は、必要ならば、このような非互換性を克服する目的で、互いに通信する必要がある2つのタイプのユーザエージェントの間の非互換性のリスクを識別する迅速な方法を提供する。特に、本発明は、ユーザエージェントが同一のタイプであろうと、異なるタイプであろうと、前記サーバが、それらのユーザエージェント間での効果的な通信セッションの設定のために必要なリソースを識別し、適切に配置することを可能とするために、上述したようなプロキシサーバが互いに通信する必要がある2つのタイプのユーザエージェントを迅速に識別することを可能とする。ここで、ユーザエージェントのタイプとは、保有するSIPノードのネットワークインタフェースを介してユーザエージェントが利用することができるインターネットプロトコルの1つまたは複数のバージョン例えば、IPv4、IPv6を示す。ノードAの保有するユーザエージェントのタイプが、ノードBの保有するユーザエージェントのタイプと異なるならば、2つのノードAおよびBは異種であると言う。従って、本発明のプロトコルは、タイプ指示子を送信するユーザエージェントを、IPv4のみ、IPv6のみ、または、デュアルスタックの3つのIPタイプに従って分類するステップをさらに含みうる。本発明の1つの特定の実施形態において、前記挿入するステップは、前記ユーザエージェントの主導で実行される。これは、ユーザエージェントが、送信または受信する呼を、対応するネットワークインタフェースおよびインターネットプロトコルのタイプに制限することを可能とする。好ましくは、前記タイプ指示子は、IPv4プロトコル、IPv6プロトコル、または、デュアルスタックIPv4IPv6プロトコルを表わす符号化された数値の形態をとりうる。そのような数値は、いくつかのビットにたいへん容易に符号化することができ、従って、本発明の実装は、呼の目的のために交換されるメッセージの量において著しい増加は引き起こさない。本発明の第1の効果的な変形において、前記方法は、前記タイプ指示子を、対応付けされたユーザエージェントの識別子とともに記憶するステップをさらに含む。とりわけ、この記憶するステップは、タイプ指示子が記憶された各ユーザエージェントに対応付けされたIPアドレスのタイプを容易かつ直接に識別するために、データベース内に参照テーブルを生成し更新する。このデータベースは、接続の初期化において各ユーザエージェントによって自発的に与えられ、または、ロケーションサーバによって定期的に更新および管理される。ユーザエージェントは、ロケーションサーバを用いて、通信セッションの初期化において、または、登録期間の満了において登録する。第1の変形に代えて、または、第1の変形とともに使用することができる本発明の第2の効果的な変形において、前記方法は、呼び出しメッセージを送信したユーザエージェントに対応付けされたタイプ指示子と前記呼び出しメッセージの宛先のユーザエージェントに対応付けされたタイプ指示子との間で非互換の場合に、ユーザエージェントとの通信に入るための呼び出しメッセージ内に含まれるアドレスを変換するステップをさらに含みうる。本発明のこの変形によれば、発信側と着信側のユーザエージェントに対応付けされたタイプ指示子を単に比較することは、発信側と着信側との間で接続を設定する試みが行われる前に、それらの間の非互換性が修復されることを可能とする。例えば、本発明は、VoIPVoiceoverIPとして知られ、または、一般に対話サービスに分類されるIP電話アプリケーションにおいて効果的に使用される。そして、本発明は、RFC3162によって定義され、IPv4クライアントおよびIPv6クライアントの両方のために配備された、SIPを基にしたシグナリングサービスの一般的な課題に取り組む。これらのサービスは、音声、映像、音響、等のサービスでありうる。上述したように、本発明は、一方がIPv4ドメインに接続し、他方がIPv6ドメインに接続した2つの異種クライアントの間でSIPセッションを設定することを容易にするための簡単なメカニズムを提案する。本発明を使用することによって、SIPプロキシサーバは、セッションが異種ノード間で設定されることを可能とするために、SIP呼をルーティングし、RFC2327によって定義され、SIPメッセージ内で伝達されるSDPofferの内容を修正するまたは、修正を引き起こすために介入することができる。一方、本発明が実装されなければ、SIPプロキシサーバは、呼のルーティングの選択を助け、成功したSIPセッションを実現するためにSIPメッセージを修正する責任を持つALGアプリケーションの使用を効率化するために、アプリケーション層以外の情報、特に、ネットワーク層に関する情報にアクセスしなければならない。同種のプロトコルスタックを使用せず、SIPサーバおよびALGアプリケーションによるそのような介入なしでは、SIPセッションを発生させることはできない。本発明は、異種SIPノードの相互作用を可能とし、簡単にし、従って、SIP通信システムにおいて呼のルーティングを容易にする。特に、本発明は、IPアドレスの使用を効率化し、サーバによって受信されるSIPメッセージによって要求される処理を引き起こすために、トランスポート層からの情報に依存するSIPプロキシサーバによるSIPメッセージの処理を必要としない。ここで言及される適用例に固有な一実施形態において、前記タイプ指示子は、SIPクエリーメッセージ内に含まれるCONTACTフィールド内に挿入されうる。タイプ指示子をクエリーメッセージ内に導入することは、ユーザエージェントにおいて利用可能なネットワークインタフェースによってサポートされるIPアドレスのタイプをロケーションサーバおよびプロキシサーバに通知する。さらに、プロキシサーバは、ネットワーク層内の情報にアクセスする必要なく、タイプ指示子を使用してその宛先にルーティングするためにクエリーメッセージを処理することができる。上述した本発明の第1の変形の上記例への適用を置き換えると、ユーザエージェントがREGISTERメッセージ内にタイプ指示子を挿入することが分かる。従って、REGISTERメッセージを受信すると、ロケーションサーバは、登録アドレス、登録有効期限、タイプ指示子を記憶する処理を行う。また、他のデータを記憶することができる。上述した本発明の第2の変形の上記例への適用を置き換えると、INVITEメッセージを送信するユーザエージェントに対応付けされたタイプ指示子とINVITEメッセージの宛先のユーザエージェントに対応付けされたタイプ指示子との間で非互換の場合に、プロキシサーバはINVITEメッセージ内に含まれるアドレスを変換することが分かる。そのような非互換性は、特に、INVITEメッセージを送信および受信するユーザエージェントが異なるタイプであるとき生じる。本発明のそのような適用は、異なるタイプの2つのユーザエージェントの間で呼のメッセージを修正するためにアプリケーションレベルにおいてゲートウェイを使用して呼のルーティング処理を実行しなければならないプロキシサーバは、ロケーションサーバによって更新され、発信側および着信側のユーザエージェントのタイプの特性を含む登録データベース内に記憶された分類に基づいて、または、着信側のユーザエージェントのタイプの特性、および、発信側のユーザエージェントによって送信されたINVITEメッセージ内に含まれるタイプ指示子を含む登録データベース内に記憶された分類に基づいて、そのような処理を実行する。上記説明から明らかなように、本発明は、また、上述した適用における実現によって直接に得られる物によって、メッセージを送信するユーザエージェントに対応付けされたIPアドレスの特性を表わすタイプ指示子を含むクエリーメッセージを伝達する信号に関し、メッセージは、例えば、REGISTER、INVITE、または、200OKとすることができる。タイプ指示子は、特に、CONTACTフィールド内に挿入することができる。本発明のハードウェアの態様は、異種ノード間でデータを送信するためのシステムに関し、前記ノード間で通信セッションを設定する前に、前記ノードのうち1つにおいて、ユーザエージェントによって送信されるメッセージ内にタイプ指示子を挿入するための手段を含み、前記タイプ指示子は、前記ユーザエージェントに対応付けされたアドレスのタイプを表わすことを特徴とする。また、そのようなデータ送信システムのノードを構成する端末に関し、前記ノードにおいて、ユーザエージェントによって送信されるメッセージ内にタイプ指示子を挿入するための手段を含み、前記タイプ指示子は、前記ユーザエージェントに対応付けされたアドレスのタイプを表わす。本発明のこのハードウェアの態様の1つの変形は、前記ユーザエージェントのタイプ指示子に基づいてクエリーメッセージを送信するユーザエージェントを区別および分類するための手段と、前記分類を記憶するように構成されたデータベースと、をさらに含む上記送信システムに関する。本発明のこのハードウェアの態様のもう1つの変形は、発信側のユーザエージェントおよび着信側のユーザエージェントに固有のタイプ指示子を比較するための手段をさらに含む上記送信システムに関する。実現するために有効な手段を構成する本発明のもう1つの態様は、コンピュータで実行されるとき前記方法のあるステップを実行するための一連のプログラムコード命令を含むコンピュータプログラムに関する。本発明は、添付図面を参照して、限定しない例によって与えられる、続く説明に照らして、より良く理解することができる。図2および続く図面を参照して、本発明による方法のより詳細な説明が与えられる。概して、例えば、IPv4、IPv6、または、デュアルスタックDSハイブリッドIP端末によって構成される各々の異種ノードは特定のタイプのユーザエージェントUAを含み、そのタイプは関係する端末に利用可能なネットワークインタフェースを介してユーザエージェントが使用することができるIPのバージョンに対応する。図2に表わされているように、本発明による方法は、ステップ10において、ユーザエージェントUAによって送信されるクエリーメッセージM内にタイプ指示子atypesを挿入する。この挿入の後、クエリーメッセージは、Matypesと表記される。そのようなクエリーメッセージは、例えば、レジストラとしても知られているロケーションサーバRへの登録メッセージを含む。また、プロキシサーバPSに送信されるメッセージ、例えば、他のユーザエージェントとの通信に入ることを促すメッセージが存在しうる。タイプ指示子が挿入されたメッセージの送信13の後、本発明による方法は、含まれるタイプ指示子atypesに基づいてクエリーメッセージMatypesを処理する11。この処理は、登録メッセージについてロケーションサーバ、または、他のユーザエージェントとの通信に入ることを促すメッセージについてプロキシサーバでありうる装置12において行われる。プロキシサーバ12において実行される処理11は、プロキシサーバ12がトランスポート層内の情報にアクセスする必要なく、メッセージをルーティングする。特に、タイプ指示子atypesは、この情報をロケーションサーバおよびプロキシサーバ12に提供するために、メッセージを送信するユーザエージェントに利用可能なネットワークインタフェースおよびインターネットプロトコルの特性を表わす符号化された数値データを含み、通信することを試みる責任を負う各種のユーザエージェントのタイプについての情報を提供するデータベースを維持するように、ロケーションサーバ12がユーザエージェントの識別子に対応付けられたタイプ指示子の登録11に進むことを可能とし、プロキシサーバ12がMatypesメッセージを送信するために使用されるトランスポート層内の情報にアクセスせずにルーティング11を処理することを可能とすることが理解される。以下、図3および図4を参照して、図2に表わされている本発明による方法のステップ10の実現例を説明する。1つの特定の類型の実施形態において、タイプ指示子atypesはSIPクエリー、特に、REGISTERおよびINVITEクエリーのCONTACTフィールド内に挿入される。この指示子の定義を説明するために、RFC3162によって定義されているCONTACTフィールドのABNFAugmentedBackusNaurform拡張バッカスナウア記法記述を以下に示す。下記のABNF記述において、この技術分野で周知の要素およびRFC3162に記載されている要素は通常の字体、追加の記述要素は太字の字体とした。新たなABNF記述の全体を下記の表1に示す。ユーザエージェントは、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に対応するロケーションサーバを示す。<IPv4ユーザエージェントの例>ユーザエージェントAはアドレス192165252を有するIPv4ユーザエージェントであると仮定する。図3に表わされているように、ユーザエージェントAは、表2に記載されているREGISTERメッセージをロケーションサーバRに送信する。登録サーバRは、表3に記載されている200OKを用いてユーザエージェントAに応答する。<IPv6ユーザエージェントの例>ユーザエージェントBはアドレス20016881ffbff802を有するIPv6ユーザエージェントであると仮定する。図3に表わされているように、ユーザエージェントBは、表4に記載されているREGISTERメッセージをロケーションサーバR6に送信する。登録サーバR6は、登録を確認するために、表5に記載されている200OKを用いてユーザエージェントAに応答する。CONTACTフィールド内のIPアドレスは、タイプ指示子atypeフィールド内に示されている以外のタイプのユニークなアドレスとすることができる。タイプ指示子atypeを6に設定するユーザエージェントはCONTACTフィールド内にIPv4アドレスを使用することができ、タイプ指示子atypeを0に設定するユーザエージェントは以下で説明するように2つではなく1つのみのアドレスを宣言することができる。CONTACTフィールド内に含まれるアドレスは、シグナリングメッセージをルーティングするためにSIPプロキシサーバによって使用される。ユーザエージェントはプロキシサーバに送信されるメッセージ内に挿入されるタイプ指示子に基づいて、または、このユーザエージェントのためにロケーションサーバによって記憶されたタイプ指示子に基づいてそのプロキシサーバPSにIPv6ユーザエージェントとして宣言したので、メディアメッセージはIPv6インタフェースを介してユーザエージェントに送信される。<CONTACTフィールド内に1つのみのアドレスを有するDSユーザエージェントの例>図4を参照し、ユーザエージェントはアドレス20016881ffbff802/192168255を有するデュアルスタックDSユーザエージェントであると仮定する。図4に表わされているように、登録フェーズの間に、DSユーザエージェントは、表6に記載されているREGISTERメッセージをそのロケーションサーバRに送信する。ロケーションサーバR6は、登録を確認するために、表7に記載されている200OKメッセージを用いて応答する。<タイプ指示子atypeの処理>REGISTERメッセージを受信すると、ロケーションサーバRは、AddressofRecordAOR、登録有効期限、タイプ指示子atypeを記憶する。このデータおよび、おそらく他のデータは、ロケーションサーバによって管理される登録データベース内に記憶される。これは同一のユーザエージェントから到達する他のREGISTERメッセージによって更新されうる。この処理は、最初にRFC3261において用意された処理を置き換える。タイプ指示子atypeからの情報を使用して、ロケーションサーバはそのユーザエージェントを3つのカテゴリIPv4のみIPv6のみデュアルスタックDSに分類する。この分類は、ロケーションサーバによって管理される登録データベースを検索することによってプロキシサーバに簡単にアクセス可能である。また、以下で説明するように、プロキシサーバのために意図されたメッセージ内にユーザエージェントによって挿入されたタイプ指示子を単に読み出すプロキシサーバによって直接に処理することができる。また、ユーザエージェントは、それらがINVITEメッセージを送信するときに、タイプ指示子atypeを設定することができる。プロキシサーバPSは下記の場合ケース1にそれらの内容を修正せずにSIPメッセージを送信しなければならない。IPv4からIPv4へIPv6からIPv6へIPv4からDSへ、および、DSからIPv4へIPv6からDSへ、および、DSからIPv6へDSからDSへ上記ケース1の場合において、ユーザエージェントは、同一のタイプでありまたは、概して、それらは少なくとも1つの共通のタイプを有するので、DSユーザエージェントを用いて、、従って同一のIPバージョンを使用して対話することできるので、互換性を有すると言う。下記の場合ケース2のみ修正が行われた後、SIPメッセージの修正は、同一タイプの着信側および発信側のユーザエージェントのIPアドレスを利用可能にする。IPv6からIPv4へIPv4からIPv6へ上記ケース2の場合において、ユーザエージェントは、同一のタイプでなく、従って通信できないので、互換性を有さないと言う。呼のルーティング、および、異なるタイプの2つのユーザエージェントの間で成功してセッションを獲得するためにALGアプリケーションを使用するか、または、SIPメッセージを修正する決定のために、プロキシサーバPSは、次のいずれかを行うことができる。<ロケーションサーバによって維持される登録データベースを検査する>この場合において、プロキシサーバ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メッセージが交換される。RE1ユーザエージェントAはプロキシサーバPSにINVITEメッセージを送信する。RE2プロキシサーバPSは、ユーザエージェントBのロケーションアドレス、および、登録の間に指定されたユーザエージェントAおよびBのタイプ指示子atypeについてロケーションサーバRに問い合わせる。RE3ロケーションサーバRは、ユーザエージェントBのアドレス、ユーザエージェントBのタイプ指示子atype、ユーザエージェントAのタイプ指示子atypeを返送する。RE4プロキシサーバPSは、ユーザエージェントAおよびBの2つのタイプ指示子atypeを比較する。ロケーションサーバRにおいて利用可能な分類のタイプに基づいて、プロキシサーバPSは、AがIPv4ユーザエージェントであり、BがIPv6ユーザエージェントであることを確認する。そして、プロキシサーバPSは、適合させるメカニズムに、IPv6アドレスを含むようにユーザエージェントAの最初のSDPofferを修正させる。そして、プロキシサーバPSは、修正されたINVITEメッセージをロケーションサーバRによって指定されたユーザエージェントBのアドレスに送信する。この手順なしでは、プロキシサーバPSは、ユーザエージェントBに呼をルーティングする手段、および、ユーザエージェントBへのメッセージの正しいルーティングのために必要な、適合させる機能を起動するための手段を有さない。プロキシサーバPSは、それを修正することなくユーザエージェントBにクエリーを返送し、この場合においてユーザエージェントAおよびBの間のSIPセッションは生じえない図1bを参照。<または、登録データベース、および、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メッセージが交換される。I1ユーザエージェントAはプロキシサーバPSにINVITEメッセージを送信する。I2プロキシサーバPSは、ユーザエージェントBのロケーションアドレス、および、登録の間に指定されたユーザエージェントBのタイプ指示子atypeについてロケーションサーバRに問い合わせる。I3ロケーションサーバRは、ユーザエージェントBのアドレスおよびタイプ指示子atypeを返送する。I4プロキシサーバPSは、I1INVITEクエリーからユーザエージェントAのタイプ指示子atypeを抽出し、それをユーザエージェントBのタイプ指示子atypeと比較する。ロケーションサーバRにおいて利用可能な分類のタイプに基づいて、プロキシサーバPSは、ユーザエージェントAがIPv4ユーザエージェントであり、ユーザエージェントBがIPv6ユーザエージェントであることを確認する。そして、プロキシサーバPSは、適合させるメカニズムに、IPv6アドレスを含むようにユーザエージェントAの最初のSDPofferを修正させる。そして、プロキシサーバPSは、修正されたINVITEメッセージをロケーションサーバRによって指定されたユーザエージェントBのアドレスに送信する。図5に表わされているプロトコルを使用するために、プロキシサーバPSは、好ましくは、発信側のユーザエージェントおよび着信側のユーザエージェントと対応付けされたタイプ指示子を比較するためのモジュールM1を含む。モジュールM1が発信側および着信側のユーザエージェントが異なるタイプであると判定したならば、プロキシサーバは発信側のユーザエージェントのIPアドレスを修正するためのリソースを呼び出すためにモジュールM2を起動させる。修正するためのリソースはプロキシサーバPSの外部に存在し、図5には表わされていない。モジュールM1およびM2は、コンピュータプログラムの形態で実現することができる。簡単のために、それらは、図5において同一の英数字の参照符号で示されている。本発明は、さらに、IP端末のIPv4、IPv6、または、デュアルスタックのユーザエージェントのような、コンピュータまたは専用装置によって実行するためのコンピュータプログラムM0を含む。コンピュータプログラムM0が実行されるとき、そのコード命令は、上述し、図2、3、4に表わされているように、そのユーザエージェントUA内で利用可能なネットワークインタフェースによってサポートされる1つまたは複数のIPアドレスのタイプを表わすタイプ指示子atypeをユーザエージェントUAによって送信されるクエリーメッセージ内に挿入する。上述したように、本発明は、さらに、プロキシサーバPSのような、コンピュータまたは専用装置によって実行するための一連の命令を含むコンピュータプログラムM1、M2を含む。コンピュータプログラムM1、M2が実行されるとき、それらの命令は、ユーザエージェントによってプロキシサーバに送信され、そのユーザエージェント内で利用可能なネットワークインタフェースによってサポートされる1つまたは複数のIPアドレスのタイプを表わすタイプ指示子atypeを含むクエリーメッセージを処理する。このような処理は、上述し、図2から5に表わされているように、トランスポート層内に含まれる情報へのアクセスなしでその宛先にクエリーメッセージをルーティングする。本発明は、また、ロケーションサーバRのような、コンピュータまたは専用装置によって実行するためのコード命令を含むコンピュータプログラムM3を含む。コンピュータプログラムM3が実行されるとき、その命令は、ユーザエージェントによって送信される登録メッセージからタイプ指示子を抽出し、登録データベース内に、関係するユーザエージェントの識別子に関するタイプ指示子を記憶する。また、それらは、上述し、図2から5に表わされているように、関係するユーザエージェントを3つのIPカテゴリIPv4、IPv6、デュアルスタックのうち1つに分類する。