JP2005339550A - サーバプール使用時の効率のよいメッセージ経路指定 - Google Patents
サーバプール使用時の効率のよいメッセージ経路指定 Download PDFInfo
- Publication number
- JP2005339550A JP2005339550A JP2005149910A JP2005149910A JP2005339550A JP 2005339550 A JP2005339550 A JP 2005339550A JP 2005149910 A JP2005149910 A JP 2005149910A JP 2005149910 A JP2005149910 A JP 2005149910A JP 2005339550 A JP2005339550 A JP 2005339550A
- Authority
- JP
- Japan
- Prior art keywords
- server
- message
- end server
- pool
- routine
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/166—Implementing security features at a particular protocol layer at the transport layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/101—Server selection for load balancing based on network conditions
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Multimedia (AREA)
- General Business, Economics & Management (AREA)
- Business, Economics & Management (AREA)
- Computing Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
- Hardware Redundancy (AREA)
Abstract
【課題】 サーバプール使用時の効率よいメッセージ経路指定を提供する。
【解決手段】 システムは、サーバプールが、別個の名前を持つ複数のサーバを含む場合であってもクライアントがサーバプールのドメイン名を指定できるようにすることによって、サーバの高可用性を保証しようとする。クライアントがサーバプールのドメイン名を用いてセッションを開始すると、システムは異なる名前を持つ利用可能なサーバを選択でき、そのセッション中の要求および後続メッセージを選択されたサーバに経路指定する。システムは、プールから最低の負荷を有するサーバを選択すること、セッション中の後続メッセージが通過すべきサーバを指示することもでき、その場合後続メッセージは指示されたサーバに経路指定されて、指示されたサーバ上のアプリケーションがそれらのメッセージおよびメッセージの指定に基づいて処置できる。
【選択図】 図3
【解決手段】 システムは、サーバプールが、別個の名前を持つ複数のサーバを含む場合であってもクライアントがサーバプールのドメイン名を指定できるようにすることによって、サーバの高可用性を保証しようとする。クライアントがサーバプールのドメイン名を用いてセッションを開始すると、システムは異なる名前を持つ利用可能なサーバを選択でき、そのセッション中の要求および後続メッセージを選択されたサーバに経路指定する。システムは、プールから最低の負荷を有するサーバを選択すること、セッション中の後続メッセージが通過すべきサーバを指示することもでき、その場合後続メッセージは指示されたサーバに経路指定されて、指示されたサーバ上のアプリケーションがそれらのメッセージおよびメッセージの指定に基づいて処置できる。
【選択図】 図3
Description
以下で説明する技術は、一般に、データ通信に関し、より詳細には、サーバプール使用時にメッセージを効率よく経路指定する方法およびシステムに関する。
アプリケーションは、時として、コンピューティングデバイス間のセッションを確立し、それを管理することを必要とする。セッションとは、ある期間にわたって発生するコンピューティングデバイス間の一連の対話である。例えば、MICROSOFT(登録商標) MESSENGERや「VoIP」(インターネットプロトコル上の音声)などのリアルタイム通信アプリケーションは、ユーザに代わって通信するデバイス間のセッションを確立する。これらのアプリケーションは、「セッション開始プロトコル」(「SIP」)など、様々な機構を用いてセッションを確立することができる。SIPは、デバイスが、相互に発見し合い、デバイス間のセッションを確立し、変更し、終了するのに使用し得るアプリケーション層の制御プロトコルである。SIPはインターネットで提案された標準である。その規格「RFC3261」は<http://www.ietf.org/rfc/rfc3261.txt>で入手可能である。イベント通知に関するSIPの拡張の規格、「RFC3265」も<http://www.ietf.org/rfc/rfc3265.txt>で入手可能である。これらの規格両方の全体を参照により本明細書に組み込むものとする。
アプリケーションはSIPを別のプロトコルと共に使用して情報を送信または受信することができる。例えば、アプリケーションは、SIPをリアルタイムトランスポートプロトコル(「RTP」)と共に使用してセッション時にリアルタイムデータを移送することができる。SIPを他のプロトコルと共に使用することにより、アプリケーションは、セッションを作成、管理し、そのセッションの間に情報を交換することができる。SIPと共に情報を交換するための使用されるプロトコルは、その情報を複数のメッセージに分割することができる。各デバイスはSIPメッセージを交換することもできる。このセッション時のメッセージの交換を「ダイアログ」という。SIPは、一般に用いられるトランスポート層およびネットワーク層プロトコルである、伝送制御プロトコル/インターネットプロトコル(「TCP/IP」)といった下位レベルの通信層を用いてダイアログのメッセージを移送することができる。
SIPネットワークは、クライアント、サーバ、またはその両方としてダイアログに参加し得るエンティティを備える。SIPは4種類のエンティティ、すなわち、ユーザエージェント、プロキシサーバ、リダイレクトサーバ、レジストラをサポートする。ユーザエージェントは、他のSIPエンティティとメッセージを交換することにより、セッションを開始し、終了する。ユーザエージェントは、一般に、SIP要求を開始するデバイスであるユーザエージェントクライアントとすることもでき、一般に、SIP要求を受け取り、そのような要求に応答するデバイスであるユーザエージェントサーバとすることもできる。例えば、「IP電話」、携帯情報端末、他の任意の種類のコンピューティングデバイスをユーザエージェントとすることができる。1つのデバイスを、あるダイアログではユーザエージェントクライアントとし、別のダイアログではユーザエージェントサーバとすることもでき、デバイスがダイアログの間に役割を変更することもできる。プロキシサーバは、クライアントに対するサーバおよびサーバに対するクライアントとして働くエンティティである。その際、プロキシサーバは、クライアントとサーバの間でメッセージを代行受信し、解釈し、または転送する。リダイレクトサーバは、SIP要求を受け入れ、別のネットワークリソースにコンタクトするよう求める要求を送信したクライアントを導く応答を生成する。レジストラは、SIPクライアントから登録情報を受け入れ、位置情報サービスに受け取った登録情報を知らせるサーバである。
SIPは2種類のメッセージをサポートする。それらは、クライアントからサーバに送信される要求と、一般に要求に応答するときにサーバからクライアントに送信される応答である。SIPメッセージは3つの部分から構成される。SIPメッセージの第1の部分は「開始行」であり、メッセージタイプおよびプロトコルバージョンを指示するフィールドを含む。SIPメッセージの第2の部分は、その値が名前/値対として表されるヘッダフィールドを備える。SIPメッセージの第3の部分はメッセージの本文であり、開始すべきセッションを記述するのに使用され、またはそのセッションに関連するデータを含む。メッセージ本文は要求または応答として表示され得る。
SIPメッセージはそのヘッダフィールドの内容に基づいて経路指定される。有効であるためには、SIP要求は少なくとも、To、From、CSeq、Call−ID、Max−Forwards、およびViaという6つのヘッダフィールドを含む必要がある。Toヘッダフィールドは、要求の受信側の論理識別情報を指示する。Fromヘッダフィールドは、要求の開始側の論理識別情報を指示する。Max−Forwardsヘッダフィールドは、その宛先に到着する前に要求が行い得るホップ数を指示する。例えば、デバイスAからのメッセージが宛先デバイスCに到着する前にデバイスBを通過する場合、そのメッセージは2つのホップを行っていると(デバイスBおよびCなど)という。Viaヘッダフィールドは、その要求がそれまでにたどったパス(その要求が通過したデバイスのネットワークアドレスのシーケンスなど)を指示し、その応答を経路指定するときにたどるべきパスを指示する。ヘッダは、その後の要求および応答を指示されたデバイスを経由して経路指定すべきことを指示するのに使用されるRecordフィールドおよびRecord−Routeフィールドも含み得る。様々なネットワークデバイスは、ダイアログ中の後続メッセージをそのデバイスを経由して経路指定させるようとしてSIPメッセージを転送するときに、Record−Routeヘッダフィールドを挿入することができる。Record−Routeヘッダフィールドは、そのデバイスおよびパラメータの識別子(ネットワークアドレスなど)を含み得る。メッセージを処理するデバイスは、そのメッセージを、メッセージのRouteヘッダフィールドに記載されたデバイスに経路指定させることができる。Routeヘッダフィールド値は、デバイスによって挿入されたRecord−Routeヘッダフィールド値に基づくものとすることができる。上記その他のヘッダフィールドは前述のSIP規格に記載されている。
SIPサーバは、単一障害点となることがあり、多数の同時セッションをサポートできないことがある。このサーバが単一障害点となり得るのは、あるクライアントから、またはそのクライアントへのすべてのSIPメッセージがこのサーバを通過し得るからであり、このサーバに障害が発生した場合、位置情報サービスがそのクライアントを障害が発生したサーバと関連付けるために、そのクライアントはSIPダイアログに参加できなくなる可能性がある。単一のサーバは、ハードウェア(プロセッサやメモリなど)およびネットワーク帯域幅の制限のために多数のクライアントをサポートできないことがある。そのような場合、多数のクライアントがサーバサポートを拒絶され、それらのクライアント上で実行されているアプリケーションの障害を発生させることがある。
これらのSIPの欠点を克服する有効な手法があれば大いに役立つはずである。
サーバプールを用いてメッセージを効率よく経路指定する手法が提供される。一実施形態では、システムは、サーバプールが、それぞれ別個の名前を持つ複数のサーバを含む場合であってもクライアントがそのサーバプールのドメイン名を指定できるようにすることによって、サーバの高可用性を保証しようとする。クライアントがそのサーバプールのドメイン名を用いてセッションを開始すると、システムは、異なる名前を持つ利用可能なサーバを選択することができ、そのセッション中の要求および後続メッセージを選択されたサーバに経路指定する。システムは、プールから最低の負荷を有するサーバを選択することができる。システムは、セッション中の後続メッセージが通過すべきサーバを指示することもできる。その場合、後続メッセージは指示されたサーバに経路指定されて、指示されたサーバ上のアプリケーションが、それらのメッセージおよびメッセージの指定に基づいて処置を講じることが可能になる。
一実施形態では、サーバプールを用いてメッセージを効率よく経路指定(routing)するシステムが提供される。このシステムは、サーバプールがそれぞれ別個の完全修飾ドメイン名(「FQDN」)を持つ複数のサーバを備える場合であってもクライアントがそのサーバプールの単一のFQDNを指定できるようにすることによって、サーバの高可用性を保証しようとする。クライアントがそのプールのFQDNを用いてSIPセッションを開始すると、システムは、プールから利用可能なサーバ(または「フロントエンドサーバ」)を選択することができ、そのセッション中の要求および後続メッセージを選択されたサーバに経路指定する。選択されたサーバのFQDNは、そのサーバプールのFQDNと異なっていてもよい。システムは、サーバプールから最低の負荷を有するサーバを選択することができる。後続メッセージは選択されたサーバを通過することになるため、システムは、メッセージを直接選択されたサーバに経路指定して他のサーバへのホップを最小限に抑えようと試みることができる。メッセージが直接選択されたサーバに経路指定されず、他の中間サーバに経路指定された場合、それらのサーバが不必要にトラフィックを処理しているために全体のサーバの負荷が増大し得る。さらに、ホップが増加するために、全体のメッセージ待ち時間も増大し得る。メッセージの直接経路指定を可能にするために、システムは、要求のヘッダフィールドにパラメータとして選択されたサーバのFQDNを付加することにより、メッセージのヘッダを変更する。ネットワーク上のデバイスはこのパラメータを用いてメッセージを直接選択されたサーバに経路指定することができる。システムは、メッセージの受信側の登録サーバ(レジストラなど)のFQDNをヘッダフィールドに付加することもできる。ネットワーク上のデバイスは、このヘッダフィールドを用いて、例えば、受信側に関連する情報を探し出すために、登録サーバと通信することができる。SIP規格に従ってメッセージを経路指定するデバイスは、そのセッション中に交換される後続のSIPメッセージにこれらのヘッダフィールドおよびパラメータを保持する。これらのヘッダフィールドおよびパラメータを評価することにより、ネットワークデバイスは、メッセージを直接選択されたサーバに経路指定し、受信側に関連付けられた登録サーバに格納された情報を探し出すことができる。その後のセッションでは、あるいは選択されたサーバが(クラッシュしたなどの理由で)利用不能になったためにセッションを再確立する必要がある場合、システムはクライアントに別のサーバを選択することができる。ゆえに、システムは、サーバの高可用性を保証し、サーバ全体にわたって負荷を平衡化させることができる。
一実施形態では、メッセージのパスに沿ったサーバ上で走るアプリケーションが、通過するメッセージを正しく処理することができるように、各サーバはメッセージのヘッダにサーバの役割を指示するフラグを付加することができる。例えば、パス上のサーバは、ユーザによって送信または受信されたメッセージに関連する課金情報を記録することができる。アプリケーションがすべてのメッセージトラフィックを知り、その役割に基づいて適切な処置を講じることができるように、システムは、メッセージのヘッダフィールドにTo/Fromフラグを付加する。ヘッダフィールドから、そのサーバの役割が、そのセッション作成要求の元の送信側からのメッセージを処理することか、それとも元の送信側へのメッセージを処理することか判定することにより、アプリケーションは、サーバの役割を決定するための高価なデータベース検索を実行せずに、適切な処置を講じることができる。ヘッダフィールド中のパラメータを用いてサーバの役割を指示することは、システムが、メッセージに対してアプリケーションに関連した処置を講じるサーバを限定することも可能にする。この情報が、Record−Routeヘッダフィールドのパラメータとして出現すると、システムによって制御されないSIP対応デバイスは、その情報を返す。メッセージと共に移動することになるヘッダフィールドおよびパラメータを付加した結果として、データベースや他のルックアップが回避され、メッセージが正しく処理される。
一実施形態では、システムは、完全修飾でないドメイン名およびデバイス名を使用する。例えば、システムは、相対ドメイン名またはマシン名を使用することができる。システムは、これらのドメイン名およびデバイス名を解決し、またはそれらを用いてサーバプールまたはデバイスを一意に識別することができる。
次に図を見ると、図1は、サーバプール使用時の効率のよいメッセージ経路指定のためのシステムの実施形態を示すブロック図である。このシステムは少なくとも1つのサーバプール102を備える。システムは、さらなるサーバプールを含むことができ、それらは1つまたは複数の他のサーバプールに接続され得る。一実施形態では、サーバプールは、様々な相互接続されたドメインでホストされ得る。例えば、1つのサーバプールが「A.com」でホストされ、第2のサーバプールがドメイン「B.org」でホストされ得る。「A.com」および「B.org」は第2レベルドメインとみなされ、他方「.com」および「.org」は第1レベルドメインとみなされる。サーバプールは、それぞれ第3レベルおよび第4レベルのドメインである「X.A.com」や「N.Y.B.org」といった下位レベルドメインによっても識別され得る。
システムのサーバプールはネットワーク108に結合され得る。ネットワークはイントラネットとすることも、インターネットとすることも、他の任意の種類のネットワークとすることもできる。ネットワークは、1つまたは複数のユーザデバイス110にも結合され得る。これらのユーザデバイスは、ネットワークを用いてサーバプールとメッセージを交換することができる。
図2は、図1のサーバプールの実施形態を示すブロック図である。サーバプール202は、「フロントエンドサーバ」とも呼ばれる複数のサーバ204を備える。これらのサーバは、そのサーバプールのドメイン名に関連したマシン名によって識別され得る。例えば、サーバ1(server1)という名前のサーバが「X.A.com」という名前のドメインを持つサーバプールのメンバである場合、そのサーバは、そのFQDN「server1.X.A.com」で識別され得る。これらのサーバは、相互に結合されてサーバのネットワークを形成することができる。
サーバは、データベースサーバ206など、他のネットワークリソースにも結合され得る。一実施形態では、各サーバ204はそれ自身のデータベースを持つ。代替として、サーバは、データベースサーバにあるデータベースを使用することもできる。データベースは、サーバとは別のコンピューティングデバイスにも、サーバと同じコンピューティングデバイスにも存在し得る。データベースを用いてセッションに関連する情報を格納することができる。例えば、データベースを用いて、サーバが処理する各セッションごとのサーバの役割(role)を格納し得る。
サーバ204は、ロードバランサ208にも結合され得る。セッション作成要求がロードバランサに到着すると、ロードバランサは、各サーバ上の負荷などに基づいて、サーバプールからその要求を処理するサーバを選択することができる。例えば、サーバプールが3つのサーバを備え、1つのサーバが保守のためにサービス停止しており、残り2つのサーバの1つが高い、プロセッサまたはネットワークの利用率を持つ場合、ロードバランサは第3のサーバを選択し得る。
サーバプールは、プロキシサーバ210に結合され得る。プロキシサーバは、ヘッダを解釈または変更する、メッセージを転送する、メッセージをネットワークから除去するなどを含めて、それが処理するメッセージに対して様々な処置を講じる。プロキシサーバは、複数のネットワークインターフェースを備え得る。1つのインターフェースは、インターネットに結合され、別のインターフェースはサーバプールに結合され得る。サーバプールがプロキシサーバを利用するとき、クライアントとサーバプール間のすべてのトラフィックはそのプロキシサーバを通過し得る。着信要求メッセージは、まず、プロキシサーバによって処理され、そこでその要求メッセージのヘッダフィールドに現れた経路指定情報が検証され得る。次いで、メッセージは、それがシステムに存在する(図示せず)場合には、エンタープライズサービスコンポーネントに、次いで、他のアプリケーション(図示せず)に転送され得る。これらのコンポーネントは、サーバプール中のサーバによって実行され得る。
着信応答メッセージも、まず、プロキシサーバによって経路指定情報を検証するために処理され得る。次いで、応答メッセージは、(要求メッセージ処理とは逆の順序で)各アプリケーションに、次いで、それが存在する場合は、エンタープライズサービスコンポーネントに転送され得る。その場合、プロキシサーバは、その応答メッセージを転送する前に、経路指定情報を更新することができる。
図3は、要求メッセージのヘッダを検証するルーチンの実施形態を示す流れ図である。このルーチンは、プロキシサーバによって実行され、ブロック302から開始し、そこでパラメータとしてメッセージを受け取る。ブロック304で、ルーチンは、メッセージに指示されたRequest−URIを処理する。Request−URIは、要求メッセージの受信側として識別されたユニフォームリソース識別子(「URI」)である。例えば、要求メッセージは、Request−URI中でユーザまたはデバイスを識別することができる。Request−URIは「maddr」パラメータを持ち得る。maddrパラメータは、URIのヘッダフィールドによって指示されたサーバアドレスではなく、使用するサーバアドレスを指示するURIと関連付けられ得る。例えば、URIはユーザエージェントによって使用されるサーバを指示し得るが、そのURIのmaddrパラメータは、ユーザにコンタクトするのに使用するプロキシサーバを指示し得る。ルーチンは、Request−URI中のmaddrパラメータが、プロキシサーバが結合されたサーバプールのFQDNまたはプロキシサーバが接続要求のためにリッスンするIPアドレスを指示するかどうかチェックすることによってRequst−URIを処理する。そうである場合、ルーチンは、RFC3261に準拠してmaddrパラメータを除去する。次いで、ルーチンは、Request−URIが、プロキシサーバが結合されたサーバプールのFQDNを指示するかどうか、およびRouteヘッダフィールドもまたFQDNを含むかどうかチェックする。そうである場合、ルーチンは、そのRequest−URIを最初のRouteヘッダフィールドにし、最後のRouteヘッダフィールドに含まれる値をRequest−URIにする。
ブロック306で、ルーチンは、メッセージが信頼される接続上で到着したかどうか判定する。例えば、接続は、その接続がトランスポート層セキュリティ(「TLS」)を使用し、システムが、そのメッセージを送信するエンティティがTLS証明書を持つか、あるいはその接続がシステムの管理者によって信頼されているとマークされていることを確認されたときに信頼される。TLSは証明書を用いて、デバイス間の専用ディジタル通信を可能にする。この技法は、ケルベロス(Kerberos)、AES(Advanced Encryption Standard(高度暗号化標準))、DES(Data Encryption Standard(データ暗号化標準))などを含む任意の技術を用いて専用通信を可能にすることができる。接続が信頼される場合、ルーチンはブロック310に進む。そうでない場合、ルーチンはブロック308に進む。
ブロック308で、ルーチンはいくつかのヘッダフィールドを処理し、変更することができる。例えば、ルーチンは、Record−Routeヘッダフィールドおよびエッジプロキシの完全修飾ドメイン名を指示するヘッダフィールドを除去することができる。エッジプロキシとは、エッジプロキシのインターネット側にあるデバイスが、そのエッジプロキシを介してのみイントラネット上のデバイスと通信するように(例えば「非武装地帯」すなわち「DMZ」などとして)イントラネットとインターネットとにまたがるプロキシサーバである。システムがこれらのヘッダフィールドを除去するのは、その接続が信頼されなかったためにシステムがその有効性を信頼しないからである。プロキシサーバがヘッダフィールドを除去しなかった場合、後続のサーバはそれらのヘッダを誤って信頼し得る。接続が信頼され得なかったとき、プロキシサーバはクライアントからの直接接続を期待し、その場合、これらのヘッダフィールドは存在し得ないことになる。クライアントが別のプロキシを介して接続するとき、その接続は信頼されるはずである。というのは、他方のプロキシはTLSを介してそれ自体を検証することができる(または信頼される接続の他の何らかの表示(indication)を持つ)はずだからである。ヘッダフィールドを処理する間、ルーチンは、Request−URIが署名されているかどうか判定することもできる。Request−URIが署名されていない場合、システムは、前述と同じ理由で、サーバプール中の特定のサーバのサーバ役割または識別子を指示するパラメータを信頼することができず、そのためそれらのパラメータを除去する。ルーチンは、メッセージ中でコンタクトに指示されたIPアドレスが、そのメッセージを送信しているデバイスのものと同じIPアドレスであるかどうか判定することにより、Contactヘッダフィールドも検証する。メッセージ中のContactヘッダフィールドは、メッセージの送信側がそこで要求を受け取ることになるURIを含む。
ブロック310で、ルーチンは、先頭のRouteヘッダフィールドが、その値が先頭のViaヘッダフィールドのIPアドレスとマッチする「maddr」パラメータを持つかどうか判定する。ヘッダフィールドがmaddrパラメータを持つが、そのヘッダフィールドに指示されたIPアドレスがメッセージを送信しているエンティティのIPアドレスとマッチしない場合、ルーチンは、そのヘッダフィールドで識別されたFQDNに関連するIPアドレスおよびポートパラメータを、送信側のIPアドレスおよびポートで置き換える。また、ルーチンは、ダイアログの後続メッセージが正しい接続を介して送信されるように、Received−CID URIパラメータを(例えばダイアログを開始するINVITEメッセージに)付加する。Received−CIDパラメータは、クライアントが、以前に参加しなかったダイアログに接続するのを防ぐために使用される一意の番号を含み得る。例えば、クライアントがサーバから適切に切断されず、新しいクライアントがそのサーバの同じポートに接続された場合、その新しいクライアントは、そのダイアログを続行することができる。しかしながら、その新しいクライアントは、サーバがそれをメッセージに付加しないために、正しいReceived−CIDパラメータを所有しないはずである。この不正確なReceived−CIDパラメータは、サーバからみて、その新しいクライアントがそのダイアログに属さないことを指示するものになる。ヘッダフィールドにエッジプロキシのFQDN(またはネットワークアドレストランスレータのFQDN)が指示される場合、ルーチンは、そのFQDNを保存し、そのヘッダフィールドを除去してそれがメッセージと一緒にサーバプールに移動するのを防ぐ。
ブロック312で、ルーチンは、メッセージが受け取られた接続が連合ドメイン(federated domain)とのものであるかどうか判定する。連合ドメインとは、プロキシサーバが動作するドメイン以外の信頼されるドメインである。ルーチンは、ルーチンを実行するサーバがエッジプロキシであるとき、接続が連合ドメインとのものであるかどうか評価することができる。メッセージが連合ドメインからのものであった場合、ルーチンはブロック314に進む。そうでない場合、ルーチンはブロック316に進む。
ブロック314で、ルーチンは、メッセージのRouteヘッダフィールドおよびRequest−URIがディジタル署名されているかどうか判定する。これらのフィールドが有効な署名でディジタル署名されている場合、ルーチンはブロック316に進む。そうでない場合、ルーチンは、Routeヘッダフィールドが存在しないかどうか、およびRequest−URIがディジタル署名されていないかどうか判定する。そうである場合、ルーチンは、サーバの役割を指示するヘッダフィールド中のパラメータを除去し、ブロック316に進む。そうでない場合、ルーチンはブロック322に進む。ブロック322で、ルーチンは、ユーザエージェントサーバが、既存のトランザクション(セッションなど)にマッチしない要求を受け取っていることを指示する応答コード481を含む応答を返す。ユーザエージェントクライアントは、そのような応答を受け取ると、それに反応してセッションを再確立しようとすることができる。
ブロック316で、ルーチンはProcess_Headerサブルーチンを呼び出し、ブロック318で、ルーチンはApplication_Routingサブルーチンを呼び出す。これらのサブルーチンについては、以下でそれぞれ図4および5に関連して詳細に説明する。ルーチンはブロック320でその呼び出し側に戻る。
図4は、要求メッセージヘッダを処理するためにプロキシサーバによって実行されるルーチンの実施形態を示す流れ図である。このルーチンはブロック402から開始し、そこでパラメータとしてメッセージを受け取る。ブロック404で、ルーチンは、メッセージにRouteヘッダフィールドがあるかどうか判定する。Routeヘッダフィールドが見つかった場合、ルーチンはブロック406に進む。そうでない場合、ルーチンはブロック410に進む。
ブロック406で、ルーチンは、先頭のRouteヘッダフィールドのFQDNが、そのサーバが属するサーバプールのFQDNにマッチするかどうか判定する。FQDNがマッチする場合、ルーチンはブロック408に進む。そうでない場合、ルーチンはブロック420に進む。ブロック408で、ルーチンは、Routeヘッダから、サーバの役割と、メッセージがそこに経路指定されるサーバの識別を指示するパラメータを抽出する。
ブロック410で、ルーチンは、Request−URIから、サーバの役割と、メッセージがそこに経路指定されるサーバの識別を抽出する。これらのパラメータは、あるエンティティによって、そのエンティティが、そのヘッダを処理するプロキシサーバが果たす役割を決定したときに、Request−URIに付加されたものとすることができる。ブロック412で、ルーチンは、宛先サーバを指示するパラメータが、ルーチンを実行するサーバ以外のサーバを指示するかどうか判定する。そうである場合、ルーチンはブロック414に進む。そうでない場合、ルーチンはブロック416に進む。ブロック414で、サーバの役割を指示するパラメータが抽出された場合、その役割は、さらなる処理を実行するアプリケーションが、その役割に関連する情報を取り出すことができるように、例えば、そのサーバに結合されたデータベースに格納される。ブロック416で、ルーチンは、このルーチンが実行されているサーバにメッセージを送信したエンティティによって挿入されたように見えるように、先頭のRouteヘッダを複製する。ブロック420で、ルーチンは、要求を受け取ったユーザエージェントサーバが、対応するトランザクション(セッションなど)を持たないことを指示する、481の応答コードを用いて応答する。ブロック418で、ルーチンは呼び出し側に戻る。
図5は、要求メッセージを処理するためにシステムのエンタープライズサービスコンポーネントによって実行されるルーチンの実施形態を示す流れ図である。エンタープライズサービスコンポーネントは、アプリケーションによってメッセージに基づく特別な処理を実行するのに使用され得るロジックを提供する。このコンポーネントは、それが「To」サーバであるかそれとも「From」サーバであるかに基づいて処理を実行する(例えば、送信または受信されたメッセージに関連する課金情報を収集する)ことができる。「To」サーバは、元のセッション作成要求の宛先のサーバプール中のサーバである。それに対して、「From」サーバは、元のセッション作成要求の送信側のサーバプール中のサーバである。サーバが「From」サーバであるかそれとも「To」サーバであるかをそのサーバの「役割」と呼ぶ。
ルーチンは、ブロック548でサーバがNOTIFYメッセージを作成したとき、またはブロック502において他の任意の状況で(例えばそれがメッセージを処理するときなどに)開始し得る。サーバがNOTIFYメッセージを生成すると、ルーチンはブロック548で実行開始する。そのような場合、サーバの役割は暗黙的に「From」に設定することができる。NOTIFYメッセージはリソースの状態を指示する、あるユーザエージェントから別のユーザエージェントへのメッセージである。ブロック549で、ルーチンは、生成されたNOTIFYメッセージがすでにRouteヘッダを持っているかどうか判定する。サーバは、データベースからRouteヘッダを取り出し、それらを生成されたNORIFYメッセージに入れていることがある。NOTIFYメッセージがすでにRouteヘッダを持っている場合、ルーチンはブロック508に進む。そうでない場合、ルーチンはブロック528に進む。
ルーチンは、ブロック502でパラメータとしてメッセージを受け取った場合に開始し得る。ブロック504で、ルーチンは、メッセージが認証について信頼されているかどうか判定する。メッセージは、それが、ルーチンを実行するサーバと同じドメインの別のサーバからのTLS接続で、メッセージが信頼されていることを指示するエッジプロキシからのTLS接続で、または管理者によって信頼されるとマークされた接続で到着したときに、認証について信頼される。前述のように、この技法は、専用通信を可能にする任意の技術と共に使用することができる。メッセージが認証について信頼される場合、ルーチンはブロック506に進む。そうでない場合、ルーチンは、ブロック536に進む。
ブロック506で、ルーチンは、メッセージにRouteヘッダが存在するかどうか判定する。メッセージ中のRouteヘッダフィールドの存在は、サーバがすでにメッセージの次のホップを指示していること、または、メッセージが、経路(ホップシーケンスなど)が前のメッセージによってすでに確立されている既存のセッションの一部であり、そのため、サーバは次のホップを決定する必要がないこと、を示すものである。一実施形態では、サーバは、それがメッセージのヘッダに指示されたURIに責任を負わないことを検証することもできる。Routeヘッダが存在する場合、ルーチンはブロック508に進む。そうでない場合、ルーチンはブロック512に進む。ブロック508で、ルーチンは、以下で図6に関連して詳細に説明するOther_Routingサブルーチンを呼び出す。ブロック510でルーチンはその呼び出し側に戻る。
ブロック512で、ルーチンは、役割パラメータが、(例えば、プロキシサーバ、そのメッセージを処理した前のサーバによって、またはそのセッションの前のメッセージを経路指定することによって)以前に保存されたかどうか判定する。そのようなパラメータが以前に保存されたとき、それはルーチンからみて、そのサーバの役割が以前に決定されていることを示すものである。そうである場合、ルーチンはブロック514に進む。そうでない場合、ルーチンはブロック528に進む。
ブロック514で、ルーチンは、サーバの役割が「To」であるかどうか判定する。そうである場合、ルーチンはブロック516に進む。そうでない場合、ルーチンは、ブロック524に進む。ブロック516で、ルーチンは、要求の宛先が「To」サーバプールのサーバであるかどうか判定する。そうである場合、ルーチンはブロック518に進む。そうでない場合、ルーチンはブロック520に進む。ブロック518で、ルーチンはその要求を処理し、応答を送信することができる。
ブロック520で、ルーチンは、メッセージのヘッダフィールドにエンドポイント識別子(「EPID」)を指示するパラメータが存在するかどうか判定する。EPIDを用いて、1人のユーザに関連する複数のログイン(例えば、デスクトップコンピューティングデバイスからのものとセルラ電話からのものなど)を区別することができる。EPIDパラメータの存在は、「To」サーバプールのエンドポイントがすでに選択されていることを示す。というのは、EPIDパラメータを最初にメッセージに付加するのは「To」サーバであり、このパラメータが後続メッセージで保持されるからである。EPIDパラメータが存在する場合、ルーチンはブロック522に進む。そうでない場合、ルーチンはブロック508に進む。ブロック522で、ルーチンは、次のサーバが「To」サーバであることを指示するRouteヘッダをメッセージに挿入する。また、サーバは、メッセージがそのプール中の別のサーバに経路指定されない限り、その役割を「To」に設定することもできる。そのプール中の別のサーバに経路指定される場合、サーバは、そのサーバプール中の別のサーバを指し示すために先頭のRouteヘッダフィールドにパラメータを付加することになる。
ブロック524で、ルーチンは、要求の宛先が「From」サーバであるかどうか判定する。そうである場合、ルーチンは、ブロック518に進む。そうでない場合、ルーチンは、ブロック526に進む。ブロック526で、ルーチンは、サーバの役割が「From」であるという指示を保存する。ブロック528で、ルーチンは、サーバが「To」サーバプールのドメインにあるかどうか判定する。そうである場合、ルーチンはブロック530に進む。そうでない場合、ルーチンはブロック508に進む。
ブロック530で、ルーチンは、「To」サーバプールのFQDNを取り出す。ブロック532で、ルーチンは、ルーチンを実行するサーバが「To」サーバプールのメンバであるかどうか判定する。そうである場合、ルーチンはブロック516に進む。そうでない場合、ルーチンはブロック534に進む。ブロック534で、ルーチンは、次のサーバが「To」サーバであることを指示するパラメータと共に、メッセージのRequest−URIに「To」サーバプールのFQDNを付加する。その結果、Request−URIがプロキシサーバによって次に処理されるときに、メッセージは「To」サーバプール中のサーバに送信される。
ブロック536で、ルーチンは、メッセージが認証されたかどうか判定する。メッセージが認証された場合、ルーチンはブロック538に進む。そうでない場合、ルーチンはブロック546に進む。ブロック546で、ルーチンは、プロキシサーバに、チャレンジメッセージを発行するよう要求する。
ブロック538で、ルーチンは、メッセージに、そのメッセージが既存のセッション中のダイアログの一部であることを指示するRouteヘッダがあるかどうか判定する。そうである場合、ルーチンはブロック508に進む。そうでない場合、ルーチンはブロック540に進む。
ブロック540で、ルーチンは「From」サーバプールのFQDNを取り出す。ブロック542で、ルーチンは、ルーチンを実行するサーバが、「From」サーバプールのメンバであるかどうか判定する。そうである場合、ルーチンはブロック524に進む。そうでない場合、ルーチンはブロック544に進む。ブロック544で、ルーチンは、次のサーバが「From」サーバであることを指示するパラメータと共に、メッセージのヘッダ中のRequest−URIに「From」サーバプールのFQDNを付加する。Request−URIが次にプロキシによって処理されるとき、メッセージは、「From」サーバプール中のサーバに送られる。
図6は、アプリケーションに関連した経路指定を可能にするために要求メッセージヘッダを処理するルーチンの実施形態を示す流れ図である。このルーチンは、ブロック602で開始し、そこでパラメータとしてメッセージを受け取る。ブロック604で、ルーチンは、メッセージにヘッダフィールドおよび関連する値を挿入する。例えば、ルーチンは、プロキシに経路ヘッダを挿入するよう要求することができる。そのような場合、プロキシは、サーバの役割を設定することもできる。ルーチンを実行するサーバ上で走るアプリケーションは、さらにRecord−Routeヘッダフィールドを付加することができる。例えば、アーカイブアプリケーションは、メッセージがアーカイブされていることを指示するために、メッセージにRecord−Routeヘッダフィールドを付加することができる。そのメッセージを再度受け取ると(あるいはおそらく、そのメッセージが通過する別のサーバ上で実行されるアプリケーションがそのメッセージを受け取ったときに)、アプリケーションは、そのフィールドがすでに付加されているため、メッセージが以前にアーカイブされたと判定することができるはずである。
ブロック606で、ルーチンは、メッセージの次のホップがメッセージのヘッダから判定され得るかどうか評価する。宛先を指示するRouteヘッダフィールドがある場合、ルーチンは、Routeヘッダから次のホップのためのFQDNまたはIPアドレスを決定する。そうではなく、Request−URIでサーバプールのサーバが識別され、メッセージが経路指定について信頼されている場合、指示されたサーバが次のホップとして使用される。そうではなく、Request−URIが、そのサーバに関連付けられた静的経路指定表中のパターンにマッチする場合、次のホップはその静的経路指定表から取り出される。メッセージは、それが信頼される接続で受け取られるか、またはそのRequest−URIが、サーバ上にインストールされたアプリケーションによって変更されたか、あるいはその経路指定情報がディジタル署名されているときに、経路指定について信頼される。メッセージが経路指定について信頼されている場合、ルーチンは、メッセージのヘッダ中のRequest−URIのホスト部分を次のホップとして識別する。次のホップが決定され得ない場合、ルーチンはブロック620に進む。そうでない場合、ブロック608で、ルーチンは、決定された次のホップのFQDNまたはIP番号を解決し、識別されたエンティティに接続する(またはすでに開いている接続を使用する)。
ブロック610で、ルーチンは、FQDNが解決され、接続が開いているかどうか判定する。そうである場合、ルーチンは、ブロック612に進む。そうでない場合、ルーチンは、ブロック620に進む。ブロック612で、ルーチンは、要求がローカルで生成されたかどうか、およびRecord−Routeが必要とされるかどうか判定する。Record−Routeは、サーバ役割パラメータが保存されるとき、および他のいくつかの状況において、エッジプロキシ、転送プロキシ上で必要とされる。Record−Routeは、NOTIFY、MESSAGE、INFO、SERVICEメッセージタイプなど、ダイアログを開始しないメッセージには必要とされない。メッセージがローカルで生成されたのではなく、あるいはRecord−Routeが必要とされる場合、ルーチンはブロック614に進む。そうでない場合、ルーチンはブロック616に進む。
ブロック614で、ルーチンは、メッセージにヘッダフィールドまたはパラメータを付加することができる。どのヘッダおよびパラメータが付加されるかは、メッセージが送信される接続が「一方向」とマークされているかどうかに左右され得る。管理者は、例えば、デバイスをより安全にするために、一方向接続のみにデバイスを使用可能にすることができる(例えば、デバイスが他のデバイスからの接続要求を受け入れることができないなど)。接続が「一方向」とマークされると、ルーチンは、メッセージのRecord−Routeヘッダフィールドに、そのサーバのFQDN、ポートおよびIPアドレス情報を付加することができ、それらは、メッセージの受信側が、メッセージを返すときのセッションでそのデバイスによって確立された接続を使用できるようにする。接続が一方向とマークされず、ルーチンを実行するサーバがサーバプールのサーバである場合、ルーチンは、サーバを識別するパラメータ(例えば、サーバ自体のFQDNまたは単にドメインに関連したサーバの名前)と共にサーバプールのFQDNをRecord−Routeヘッダフィールドに付加する。そのセッションでシステムによって後続メッセージが受け取られたとき、システムは、そのパラメータに基づき、どのサーバにその後続メッセージを経路指定すべきか決定することができるはずである。接続が一方向とマークされておらず、ルーチンを実行するデバイスがサーバプールにないとき、ルーチンは、デバイスがエッジプロキシであり、評価されている要求メッセージがクライアントまたは転送プロキシで発信されたかどうか判定する。そうである場合、ルーチンは、後続メッセージが同じエッジプロキシを介して経路指定されるように、接続が一方向とマークされたときに付加されたものと類似のヘッダフィールドおよびパラメータを付加することができる。そうでない場合、ルーチンは、Record−RouteヘッダフィールドにサーバのFQDNを付加することができる。デバイスがエッジプロキシである場合、デバイスは、メッセージがそこに転送されるデバイスによって解決され得るFQDN(すなわち、次のサーバがイントラネットの内部にあるかそれとも外部にあるかに応じて、イントラネットの内部または外部で解決され得るFQDN)を付加することができる。これらのヘッダフィールドを付加した後、ルーチンは、逆方向のパラメータ(opposite parameter)が以前に格納されていた場合には、さらに、サーバの役割を(例えばFromをToにまたはその反対に)反転するパラメータを付加することができる。
ブロック616で、ルーチンはメッセージを転送する。メッセージを転送する前に、ルーチンは、メッセージがそこで送信される接続が経路指定について信頼されているかどうか判定する。例えば、TLS(または専用通信を可能にする他の何らかの機構)を用い、あるいは管理者によって信頼されると明示的に指示された接続が経路指定について信頼される。接続が経路指定について信頼され、プロセスがエッジプロキシによって実行されている場合、ルーチンは、その接続が連合ドメインとのものであるかどうか判定する。連合ドメインは、そのサーバのドメイン以外の信頼されるドメインである。接続が信頼されておらず、または接続が連合ドメインとのものである場合、ルーチンは、メッセージ中の任意のContactおよびRecord−Routeヘッダフィールドにディジタル署名し、署名を先頭のRecord−Routeヘッダフィールドに入れる。Viaヘッダもディジタル署名される。次いでルーチンは、メッセージを転送する。ブロック618で、ルーチンはその呼び出し側に戻る。ブロック620で、ルーチンは、サーバが要求を処理しようとしたときに適時の応答を受け取らなかったことを示す504応答コードを用いて応答する。
図7は、応答メッセージを処理するルーチンの実施形態を示す流れ図である。このルーチンはブロック702で開始し、そこでパラメータとして応答メッセージを受け取る。ブロック706で、ルーチンは、メッセージが複数のViaヘッダフィールドを含むかどうか判定する。メッセージが複数のViaメッセージフィールドを含む場合、それは、その応答を別のサーバに転送する必要がある可能性があることを示すものである。そうである場合、ルーチンはブロック708に進む。そうでない場合、ルーチンはローカルでその応答を消費し(consume)、ブロック716に進む。
ブロック708で、ルーチンは、メッセージが受け取られた接続が経路指定について信頼されているかどうか判定する。接続が経路指定について信頼される状況については、先に、例えば、図6との関連で説明した。接続が経路指定について信頼される場合、ルーチンは、ヘッダフィールドがそのような値を指示したときにエッジプロキシのFQDNを保存し、そのヘッダフィールドを除去する。そうでない場合、ルーチンは、応答メッセージのContactヘッダフィールドを、それらのフィールドが、サーバが接続されているエンティティ(またはプロキシ)と同じIPアドレスを指示することを検証し、Received−CID URIパラメータを付加することによって処理し、ルーチンを実行するサーバとセッションを持つ別のクライアントがその同じIPアドレスおよびポートを使用しないよう保証しようする。接続が経路指定について信頼され、ルーチンがエッジプロキシによって実行されている場合、ルーチンは、その接続が連合ドメインへのものであるかどうか判定する。その接続が連合ドメインへのものである場合、またはContactヘッダフィールドを処理した後、ルーチンは、メッセージ中の経路指定情報が、Record−RouteおよびViaヘッダフィールド中の署名とマッチすることを検証する。接続が連合ドメインからのものではなく、あるいは経路指定署名が検証された場合、ルーチンは、アプリケーションおよびエンタープライズサービスがその応答を処理できるようにする。経路指定署名が(例えばヘッダが適正にディジタル署名されていなかったために)検証されなかった場合、ルーチンはその応答を取り消す。ルーチンは、応答のヘッダフィールドを分析することにより、このルーチンを実行するサーバが、前の要求にRecord−Routeヘッダフィールドを挿入したかどうか判定する。そうである場合、ルーチンはブロック710に進む。そうでない場合、ルーチンは、ブロック712に進む。
ブロック710で、ルーチンは、Record−Routeヘッダフィールドを処理する。ルーチンは、応答中にContactヘッダがない場合、ルーチンを実行するサーバを指示するRecord−Routeヘッダフィールドがあれば、それを除去する。ルーチンは、現在の応答を生じた前の要求を処理するときに、そのルーチンまたは別のプロキシが挿入した可能性のある他の関連するヘッダフィールドも除去することができる。ルーチンは、ヘッダにサーバの役割を指示するパラメータを付加して(または除去されたパラメータの値を使用して)、前の要求の送信側が後続の要求を送信するときにその役割が識別され、または使用され得るようにすることもできる。ルーチンは、管理者が接続を一方向とマークしたかどうかチェックする。一方向接続とは、ネットワーク中の他のデバイスがそのサーバのFQDNを解決し、またはそのサーバに戻る接続を確立することができないことを示すものである。例えば、管理者は、サーバを、発信接続を可能にし、着信接続をできないものとするファイアウォールにすることを望むことができる。接続が一方向とマークされている場合、ルーチンは、応答のRecord−RouteヘッダフィールドにサーバのFQDN、IPアドレス、およびポート情報を付加することができる。ルーチンは、前のホップのViaヘッダフィールドからの転送ポイントパラメータを用いて、ネットワークアドレストランスレータの通過に関する問題を処理することもできる。
接続が一方向とマークされておらず、ルーチンを実行するデバイスがサーバプールのサーバである場合、ルーチンは、Record−Routeヘッダフィールドに、サーバのFQDNを指示するパラメータと共にサーバプールのFQDNを付加する。そのセッションでシステムによって後続メッセージが受け取られるとき、システムは、そのパラメータに基づいてどのサーバにその後続メッセージを経路指定すべきか決定することができるはずである。接続が一方向とマークされておらず、ルーチンを実行するデバイスがサーバプールにない場合、ルーチンは、そのデバイスがエッジプロキシであり、評価されている要求メッセージがクライアントまたは転送プロキシで発信されたかどうか判定する。そうである場合、ルーチンは、後続メッセージが同じエッジプロキシを介して経路指定されるように、接続が一方向とマークされたときに付加されるものと類似のヘッダフィールドおよびパラメータを付加することができる。そうでない場合、ルーチンは、Record−RouteヘッダフィールドにサーバのFQDNを付加することができる。デバイスがエッジプロキシである場合、デバイスは、メッセージがそこに転送されるデバイスによって解決され得るFQDNを付加することができる。これらのヘッダフィールドを付加した後、ルーチンは、逆方向のパラメータが以前に格納された場合は、サーバの役割を(例えばFromをToにまたはその反対に)反転するパラメータを付加することができる。
ブロック712で、ルーチンは、先頭のViaヘッダフィールドを除去する。ブロック714で、ルーチンは応答を転送する。発信接続が(例えば、それがTLSまたは専用接続を可能にする他の何らかの機構を使用しており、あるいは管理者によって信頼されると指示されているために)経路指定について信頼される場合、ルーチンは、接続が連合ドメインへのものであるかどうか判定する。接続が連合ドメインへのものである場合、ルーチンはRecord−Routeおよびコンタクト情報を含むヘッダフィールドにディジタル署名する。ルーチンは、発信接続が経路指定について信頼されない場合にもこれらのヘッダフィールドに署名する。次いで、ルーチンは、その応答経路の次のエンティティに応答を転送する。ブロック716で、ルーチンはその呼び出し側に戻る。
メッセージを効率よく経路指定するシステムが実施されるコンピューティングデバイスは、中央処理装置、メモリ、入力装置(キーボードやポインティング装置など)、出力装置(表示装置など)、および記憶装置(ディスクドライブなど)を含み得る。メモリおよび記憶装置は、そのセキュリティシステムを実施する命令を含み得るコンピュータ可読媒体である。また、そのデータ構造およびメッセージ構造は、通信リンク上の信号などのデータ伝送媒体によって格納され、送信され得る。インターネット、ローカルエリアネットワーク、広域ネットワーク、ポイントツーポイントダイヤルアップ接続など、様々な通信リンクが使用され得る。
図1および図2には、このセキュリティが実施され得る適当な動作環境の一例が示されている。この動作環境は、適当な動作環境の一例にすぎず、この拡張可能な無線フレームワークの使用または機能の範囲に関するどのような限定も示唆するものではない。使用に適し得る他の公知のコンピューティングシステム、環境および構成には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ機器、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラム可能家庭用電化製品、ネットワークPC、ミニコンピュータ、メインフレームコンピュータ、前述のシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれる。
このセキュリティシステムは、1つまたは複数のコンピュータまたは他のデバイスによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的なコンテキストで説明され得る。一般に、プログラムモジュールには、個々のタスクを実行し、個々の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。通常、プログラムモジュールの機能は、様々な実施形態において、所望に応じて組み合わされ、分散され得る。
以上から、本明細書では、説明のために、本発明の特定の実施形態について説明したが、本発明の精神および範囲から逸脱することなく、様々な変更が加えられ得ることが理解されよう。したがって、本発明は、添付の特許請求の範囲による以外には限定されない。
102 サーバプール1〜n
108 ネットワーク
110 ユーザ1〜m
204 サーバ1〜n
206 データベース
208 ロードバランサ
210 プロキシ
108 ネットワーク
110 ユーザ1〜m
204 サーバ1〜n
206 データベース
208 ロードバランサ
210 プロキシ
Claims (40)
- サーバプールのフロントエンドサーバにメッセージを効率よく経路指定するためにコンピュータシステムによって実行される方法であって、前記サーバプールは複数のフロントエンドサーバを備え、
ダイアログを開くよう指示するクライアントコンピューティングデバイスから、前記サーバプールを識別するドメイン名に送信されたメッセージを受け取ること、
サーバドメイン名を持つ前記サーバプールのフロントエンドサーバを選択すること、
前記選択されたフロントエンドサーバの前記サーバドメイン名の指示を付加するように前記メッセージのヘッダフィールドを変更し、それによって前記ダイアログの後続メッセージが、前記指示に基づき、前記選択されたフロントエンドサーバに送信され得るようにすること、および
前記クライアントコンピューティングデバイスと前記選択されたフロントエンドサーバの間の前記ダイアログを開くために、前記選択されたフロントエンドサーバに前記変更されたメッセージを転送すること
を備えることを特徴とする方法。 - 前記クライアントコンピューティングデバイスから前記ダイアログの後続メッセージを受け取ること、
前記後続メッセージのヘッダフィールドに含まれる前記サーバドメイン名の前記指示から前記選択されたフロントエンドサーバを検出すること、および
前記後続メッセージに含まれる前記サーバドメイン名の前記指示に基づき、前記選択されたフロントエンドサーバに前記後続メッセージを転送すること
を含むことを特徴とする請求項1に記載の方法。 - 前記コンピュータシステムはプロキシサーバであることを特徴とする請求項2に記載の方法。
- 前記ダイアログの後続メッセージは、前記サーバプールの別のコンピューティングデバイスによる転送なしで、前記クライアントコンピューティングデバイスと前記選択されたフロントエンドサーバの間で交換されることを特徴とする請求項1に記載の方法。
- 前記コンピュータシステムは、前記サーバプールの別のコンピューティングデバイスであることを特徴とする請求項4に記載の方法。
- 前記変更することは、ヘッダフィールドにパラメータを付加することを含むことを特徴とする請求項1に記載の方法。
- 前記ヘッダフィールドはセッション開始プロトコルのRecord−Routeヘッダフィールドであることを特徴とする請求項6に記載の方法。
- 前記パラメータは前記サーバドメイン名を指示することを特徴とする請求項6に記載の方法。
- 前記サーバドメイン名は完全修飾ドメイン名であることを特徴とする請求項8に記載の方法。
- 前記フロントエンドサーバの役割を指示するヘッダフィールド値を付加することを含む請求項1に記載の方法。
- 前記役割はFromであることを特徴とする請求項10に記載の方法。
- 前記役割はToであることを特徴とする請求項10に記載の方法。
- アプリケーションプログラムは、前記指示された役割に基づいて処理を実行することを特徴とする請求項10に記載の方法。
- 前記サーバプールの前記選択されたフロントエンドサーバが使用不能になったときに前記サーバプールの代替のフロントエンドサーバを選択することを含むことを特徴とする請求項1に記載の方法。
- 前記選択することは、サーバ負荷を判定することを含むことを特徴とする請求項1に記載の方法。
- 前記後続メッセージは、同一のネットワークデバイスのセットをトラバース(traverse)することを特徴とする請求項1に記載の方法。
- 前記メッセージは、セッション開始プロトコルメッセージであることを特徴とする請求項1に記載の方法。
- サーバプールのフロントエンドサーバにメッセージを効率よく経路指定するシステムであって、前記サーバプールは複数のフロントエンドサーバを備え、
ダイアログを開くよう指示するクライアントコンピューティングデバイスから、前記サーバプールを識別するドメイン名に送信されたメッセージを受け取るコンポーネントと、
識別子を持つ前記サーバプールのフロントエンドサーバを選択するコンポーネントと、
前記選択されたフロントエンドサーバの前記識別子の指示を前記メッセージのヘッダフィールドに付加することによって前記メッセージを変更するコンポーネントと
を備えることを特徴とするシステム。 - 前記メッセージはセッション開始プロトコルメッセージであることを特徴とする請求項18に記載のシステム。
- 前記識別子は前記選択されたフロントエンドサーバのサーバ名であることを特徴とする請求項18に記載のシステム。
- 前記サーバ名は完全修飾ドメイン名であることを特徴とする請求項20に記載のシステム。
- 前記クライアントコンピューティングデバイスと前記選択されたフロントエンドサーバの間の前記ダイアログを開くために、前記選択されたフロントエンドサーバに前記変更されたメッセージを転送するコンポーネントを含むことを特徴とする請求項18に記載のシステム。
- 前記クライアントコンピューティングデバイスから後続メッセージを受け取り、各後続メッセージを、前記後続メッセージのヘッダフィールドに指示された前記フロントエンドサーバに転送するコンポーネントを含むことを特徴とする請求項18に記載のシステム。
- その内容がコンピューティングシステムに、
ダイアログを開くよう指示するクライアントコンピューティングデバイスから、サーバプールを識別するドメイン名を指示するメッセージを受け取ること、
識別子を持つ前記プールのフロントエンドサーバを選択すること、
前記選択されたフロントエンドサーバの前記識別子の指示を付加するように前記メッセージのヘッダフィールドを変更し、それによって前記ダイアログの後続メッセージが、前記識別子に基づき、前記選択されたフロントエンドサーバに送信され得るようにすること、および
前記クライアントコンピューティングデバイスと前記選択されたフロントエンドサーバの間の前記ダイアログを開くために、前記選択されたフロントエンドサーバに前記変更されたメッセージを転送すること
を備える方法を実行させることを特徴とするコンピュータ可読媒体。 - 前記クライアントコンピューティングデバイスから前記ダイアログの後続メッセージを受け取ること、
前記後続メッセージのヘッダフィールドに含まれる前記選択されたフロントエンドサーバの前記識別子から前記選択されたフロントエンドサーバを検出すること、および
前記後続メッセージのヘッダフィールドに含まれる前記フロントエンドサーバの前記識別子に基づき、前記選択されたフロントエンドサーバに前記後続メッセージを転送すること
を含むことを特徴とする請求項24に記載のコンピュータ可読媒体。 - 前記ダイアログの後続メッセージは、前記サーバプールの別のコンピューティングデバイスによる転送なしで、前記クライアントコンピューティングデバイスと前記選択されたフロントエンドサーバの間で交換されることを特徴とする請求項24に記載のコンピュータ可読媒体。
- 前記メッセージはセッション開始プロトコルメッセージであることを特徴とする請求項24に記載のコンピュータ可読媒体。
- 前記フロントエンドサーバの前記識別子は完全修飾ドメイン名であることを特徴とする請求項24に記載のコンピュータ可読媒体。
- 前記ドメイン名は完全修飾ドメイン名であることを特徴とする請求項28に記載のコンピュータ可読媒体。
- 前記フロントエンドサーバの前記識別子はサーバ名であることを特徴とする請求項24に記載のコンピュータ可読媒体。
- 前記フロントエンドサーバの前記識別子は前記サーバプールに固有であることを特徴とする請求項24に記載のコンピュータ可読媒体。
- サーバプールのフロントエンドサーバを指示するためのコンピュータ可読媒体であって、
前記サーバプールを識別するヘッダフィールドを含むメッセージと、
前記フロントエンドサーバを指示する前記ヘッダフィールドのパラメータと
を備えることを特徴とするコンピュータ可読媒体。 - 前記サーバプールの前記識別は完全修飾ドメイン名であることを特徴とする請求項32に記載のコンピュータ可読媒体。
- 前記ドメイン名は完全修飾ドメイン名であることを特徴とする請求項33に記載のコンピュータ可読媒体。
- 前記パラメータは前記フロントエンドサーバのドメイン名であることを特徴とする請求項32に記載のコンピュータ可読媒体。
- 前記ドメイン名は完全修飾ドメイン名であることを特徴とする請求項35に記載のコンピュータ可読媒体。
- 前記パラメータは前記サーバプールにおいて前記フロントエンドサーバを一意に識別することを特徴とする請求項32に記載のコンピュータ可読媒体。
- 前記フロントエンドサーバの役割の指示を含むことを特徴とする請求項32に記載のコンピュータ可読媒体。
- 前記役割がFromであることを特徴とする請求項38に記載のコンピュータ可読媒体。
- 前記役割がToであることを特徴とする請求項38に記載のコンピュータ可読媒体。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/851,003 US8024476B2 (en) | 2004-05-21 | 2004-05-21 | Efficient message routing when using server pools |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2005339550A true JP2005339550A (ja) | 2005-12-08 |
Family
ID=34939686
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005149910A Pending JP2005339550A (ja) | 2004-05-21 | 2005-05-23 | サーバプール使用時の効率のよいメッセージ経路指定 |
Country Status (5)
Country | Link |
---|---|
US (1) | US8024476B2 (ja) |
EP (1) | EP1599015A1 (ja) |
JP (1) | JP2005339550A (ja) |
KR (1) | KR101120695B1 (ja) |
CN (1) | CN1700680B (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008033558A (ja) * | 2006-07-27 | 2008-02-14 | Fujitsu Ltd | Sipメッセージ引渡プログラム |
JP2010507951A (ja) * | 2006-10-24 | 2010-03-11 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Sip構文解析性能を改善する方法、装置、及びコンピュータ・プログラム |
WO2010106772A1 (ja) * | 2009-03-17 | 2010-09-23 | 日本電気株式会社 | 分散処理システム及び分散処理方法 |
US8374079B2 (en) | 2006-10-20 | 2013-02-12 | Nec Corporation | Proxy server, communication system, communication method and program |
Families Citing this family (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7535905B2 (en) * | 2004-03-31 | 2009-05-19 | Microsoft Corporation | Signing and validating session initiation protocol routing headers |
US8024476B2 (en) | 2004-05-21 | 2011-09-20 | Microsoft Corporation | Efficient message routing when using server pools |
US7506369B2 (en) * | 2004-05-27 | 2009-03-17 | Microsoft Corporation | Secure federation of data communications networks |
US20060048163A1 (en) * | 2004-08-27 | 2006-03-02 | Thierry Bessis | Method for routing messages between servers located on the same board |
US20060083242A1 (en) * | 2004-10-20 | 2006-04-20 | Nokia Corporation | Address modification in application servers |
US8312074B2 (en) * | 2005-05-26 | 2012-11-13 | Bytemobile, Inc. | Method for multipart encoding |
US20070055784A1 (en) * | 2005-09-08 | 2007-03-08 | Pancholi Ketan P | Method to reduce the learning curve of a transmission control protocol connection |
US8943181B2 (en) * | 2005-11-29 | 2015-01-27 | Ebay Inc. | Method and system for reducing connections to a database |
CA2631763A1 (en) | 2005-12-01 | 2007-06-07 | Firestar Software, Inc. | System and method for exchanging information among exchange applications |
US9953097B2 (en) | 2006-03-16 | 2018-04-24 | Ebay Inc. | System and method for managing network traffic routing |
JP4632450B2 (ja) * | 2006-04-17 | 2011-02-16 | キヤノン株式会社 | 通信装置及びその制御方法 |
FR2902590B1 (fr) * | 2006-06-16 | 2008-08-01 | Alcatel Sa | Detection de boucles au sein d'un element intermediaire de signalisation sip |
US7761538B2 (en) * | 2006-08-30 | 2010-07-20 | Microsoft Corporation | Dynamically configuring, allocating and deploying computing systems |
FR2906668A1 (fr) * | 2006-10-02 | 2008-04-04 | Alcatel Sa | Marqueur pour systemes de communication composes d'une pluralite de serveurs sip. |
US7664108B2 (en) * | 2006-10-10 | 2010-02-16 | Abdullah Ali Bahattab | Route once and cross-connect many |
US8929360B2 (en) | 2006-12-07 | 2015-01-06 | Cisco Technology, Inc. | Systems, methods, media, and means for hiding network topology |
CN101242392B (zh) * | 2007-02-06 | 2012-02-08 | 国际商业机器公司 | 用于系列服务消息处理的方法、设备和系统 |
US8713186B2 (en) * | 2007-03-13 | 2014-04-29 | Oracle International Corporation | Server-side connection resource pooling |
WO2009036184A2 (en) | 2007-09-11 | 2009-03-19 | Research In Motion Limited | System and method for sharing a sip communication service identifier |
US20090185673A1 (en) * | 2008-01-17 | 2009-07-23 | Avaya Technology Llc | Voice-Over-IP Call Recording in Call Centers |
US9160610B1 (en) * | 2009-03-31 | 2015-10-13 | Symantec Corporation | Method and apparatus for coordinating service execution within a shared file system environment to optimize cluster performance |
US9378503B2 (en) * | 2010-06-30 | 2016-06-28 | Alcatel Lucent | Methods of routing for networks with feedback |
US9385935B2 (en) * | 2013-03-06 | 2016-07-05 | Microsoft Technology Licensing, Llc | Transparent message modification for diagnostics or testing |
US20150172324A1 (en) * | 2013-12-13 | 2015-06-18 | Alcatel-Lucent Usa Inc. | Authorized SIP Redirection |
CN105338480B (zh) * | 2014-06-24 | 2020-01-24 | 创新先进技术有限公司 | 基于lbs的用户匹配方法、消息客户端、服务器及系统 |
US9612889B2 (en) * | 2015-02-27 | 2017-04-04 | Wal-Mart Stores, Inc. | Integrating applications |
US10826868B2 (en) * | 2016-03-29 | 2020-11-03 | T-Mobile Usa, Inc. | NAT aware DNS |
EP3874697A4 (en) | 2018-10-30 | 2022-09-14 | Hewlett Packard Enterprise Development LP | SOFTWARE-DEFINED WAN UPLINK SELECTION FOR A CLOUD SERVICE |
NL2022642B1 (en) * | 2019-02-26 | 2020-09-01 | Machsol Holding B V | A system for connecting a user to a cloud service and a method for setting up the system |
US11792071B1 (en) * | 2021-12-17 | 2023-10-17 | Juniper Networks, Inc. | Intent-based user authentication for dynamic applications |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030110257A1 (en) * | 2001-12-11 | 2003-06-12 | Wook Hyun | Method for performing a load distribution between session initiation protocol servers within an intra domain |
Family Cites Families (46)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6317775B1 (en) * | 1995-11-03 | 2001-11-13 | Cisco Technology, Inc. | System for distributing load over multiple servers at an internet site |
US5774660A (en) * | 1996-08-05 | 1998-06-30 | Resonate, Inc. | World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network |
US6275937B1 (en) | 1997-11-06 | 2001-08-14 | International Business Machines Corporation | Collaborative server processing of content and meta-information with application to virus checking in a server network |
JP3966598B2 (ja) | 1998-03-04 | 2007-08-29 | 富士通株式会社 | サーバ選択システム |
US6389532B1 (en) | 1998-04-20 | 2002-05-14 | Sun Microsystems, Inc. | Method and apparatus for using digital signatures to filter packets in a network |
US6567915B1 (en) | 1998-10-23 | 2003-05-20 | Microsoft Corporation | Integrated circuit card with identity authentication table and authorization tables defining access rights based on Boolean expressions of authenticated identities |
NO308019B1 (no) | 1998-11-27 | 2000-07-03 | Ericsson Telefon Ab L M | FremgangsmÕte for Õ utvide bruken av SIP (Session Initiation Protocol) |
US6553422B1 (en) | 1999-04-26 | 2003-04-22 | Hewlett-Packard Development Co., L.P. | Reverse HTTP connections for device management outside a firewall |
US6584567B1 (en) | 1999-06-30 | 2003-06-24 | International Business Machines Corporation | Dynamic connection to multiple origin servers in a transcoding proxy |
US6434143B1 (en) | 1999-11-08 | 2002-08-13 | Mci Worldcom, Inc. | Internet protocol telephony voice/video message deposit and retrieval |
US8743892B2 (en) | 1999-11-08 | 2014-06-03 | Verizon Business Global Llc | Method and system for dynamic gateway selection in an IP telephony network |
US6477150B1 (en) * | 2000-03-03 | 2002-11-05 | Qualcomm, Inc. | System and method for providing group communication services in an existing communication system |
US6976090B2 (en) * | 2000-04-20 | 2005-12-13 | Actona Technologies Ltd. | Differentiated content and application delivery via internet |
US6865681B2 (en) | 2000-12-29 | 2005-03-08 | Nokia Mobile Phones Ltd. | VoIP terminal security module, SIP stack with security manager, system and security methods |
US6985958B2 (en) | 2001-03-14 | 2006-01-10 | Microsoft Corporation | Messaging infrastructure for identity-centric data access |
US7284271B2 (en) | 2001-03-14 | 2007-10-16 | Microsoft Corporation | Authorizing a requesting entity to operate upon data structures |
US20020141404A1 (en) | 2001-04-03 | 2002-10-03 | Michael Wengrovitz | Call routing using information in session initiation protocol messages |
US7676430B2 (en) | 2001-05-09 | 2010-03-09 | Lenovo (Singapore) Ptd. Ltd. | System and method for installing a remote credit card authorization on a system with a TCPA complaint chipset |
US20020178240A1 (en) | 2001-05-24 | 2002-11-28 | International Business Machines Corporation | System and method for selectively confirming digital certificates in a virtual private network |
US7243370B2 (en) | 2001-06-14 | 2007-07-10 | Microsoft Corporation | Method and system for integrating security mechanisms into session initiation protocol request messages for client-proxy authentication |
US7010727B1 (en) | 2001-06-15 | 2006-03-07 | Nortel Networks Limited | Method and system for negotiating compression techniques to be utilized in packet data communications |
US20030009570A1 (en) | 2001-07-03 | 2003-01-09 | International Business Machines Corporation | Method and apparatus for segmented peer-to-peer computing |
US20030084331A1 (en) | 2001-10-26 | 2003-05-01 | Microsoft Corporation | Method for providing user authentication/authorization and distributed firewall utilizing same |
US7343490B2 (en) | 2001-11-30 | 2008-03-11 | Nokia Siemens Networks Oy | Apparatus, and associated method, for facilitating authentication of a mobile station with a core network |
EP1452000A2 (en) | 2001-12-07 | 2004-09-01 | Telefonaktiebolaget LM Ericsson (publ) | Lawful interception of end-to-end encrypted data traffic |
JP3811057B2 (ja) * | 2001-12-10 | 2006-08-16 | 富士通株式会社 | 中継コネクション管理プログラムおよび中継コネクション管理方法 |
US7085829B2 (en) * | 2001-12-31 | 2006-08-01 | Innomedia, Pte Ltd. | Method and system for an intelligent proxy server for workload balancing by workload shifting |
US7509425B1 (en) | 2002-01-15 | 2009-03-24 | Dynamicsoft, Inc. | Establishing and modifying network signaling protocols |
US7240366B2 (en) | 2002-05-17 | 2007-07-03 | Microsoft Corporation | End-to-end authentication of session initiation protocol messages using certificates |
US7774473B2 (en) * | 2002-07-31 | 2010-08-10 | Oracle America, Inc. | System and method for sticky routing of requests within a server farm |
US20040043756A1 (en) | 2002-09-03 | 2004-03-04 | Tao Haukka | Method and system for authentication in IP multimedia core network system (IMS) |
US7406709B2 (en) | 2002-09-09 | 2008-07-29 | Audiocodes, Inc. | Apparatus and method for allowing peer-to-peer network traffic across enterprise firewalls |
KR100472952B1 (ko) | 2002-10-30 | 2005-03-10 | 한국전자통신연구원 | 세션 초기화 프로토콜(sip)기반의 부하 분산장치 및방법 |
JP4338993B2 (ja) | 2003-02-28 | 2009-10-07 | モトローラ・インコーポレイテッド | 無線端末のセッション制御方法及びインターフェース設定方法 |
US7412521B2 (en) | 2003-03-12 | 2008-08-12 | Microsoft Corporation | End-point identifiers in SIP |
US7949785B2 (en) * | 2003-03-31 | 2011-05-24 | Inpro Network Facility, Llc | Secure virtual community network system |
US7421732B2 (en) | 2003-05-05 | 2008-09-02 | Nokia Corporation | System, apparatus, and method for providing generic internet protocol authentication |
US6963635B1 (en) | 2003-05-06 | 2005-11-08 | Sprint Spectrum L.P. | Method and system for facilitating collection of subscriber past due balance |
JP2004364141A (ja) | 2003-06-06 | 2004-12-24 | Hitachi Communication Technologies Ltd | Ipアドレス変換装置およびパケット転送装置 |
US20040260752A1 (en) * | 2003-06-19 | 2004-12-23 | Cisco Technology, Inc. | Methods and apparatus for optimizing resource management in CDMA2000 wireless IP networks |
JP4115354B2 (ja) * | 2003-07-04 | 2008-07-09 | 富士フイルム株式会社 | ピア・ツー・ピア通信システム |
US7257837B2 (en) * | 2003-07-26 | 2007-08-14 | Innomedia Pte | Firewall penetration system and method for real time media communications |
US7142537B2 (en) | 2003-12-18 | 2006-11-28 | Motorola, Inc. | Interface call signaling protocol |
US7535905B2 (en) | 2004-03-31 | 2009-05-19 | Microsoft Corporation | Signing and validating session initiation protocol routing headers |
US8024476B2 (en) | 2004-05-21 | 2011-09-20 | Microsoft Corporation | Efficient message routing when using server pools |
FR2902590B1 (fr) | 2006-06-16 | 2008-08-01 | Alcatel Sa | Detection de boucles au sein d'un element intermediaire de signalisation sip |
-
2004
- 2004-05-21 US US10/851,003 patent/US8024476B2/en not_active Expired - Fee Related
-
2005
- 2005-05-04 EP EP05103723A patent/EP1599015A1/en not_active Withdrawn
- 2005-05-20 CN CN2005100758778A patent/CN1700680B/zh not_active Expired - Fee Related
- 2005-05-20 KR KR1020050042306A patent/KR101120695B1/ko not_active IP Right Cessation
- 2005-05-23 JP JP2005149910A patent/JP2005339550A/ja active Pending
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030110257A1 (en) * | 2001-12-11 | 2003-06-12 | Wook Hyun | Method for performing a load distribution between session initiation protocol servers within an intra domain |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008033558A (ja) * | 2006-07-27 | 2008-02-14 | Fujitsu Ltd | Sipメッセージ引渡プログラム |
US8374079B2 (en) | 2006-10-20 | 2013-02-12 | Nec Corporation | Proxy server, communication system, communication method and program |
JP2010507951A (ja) * | 2006-10-24 | 2010-03-11 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Sip構文解析性能を改善する方法、装置、及びコンピュータ・プログラム |
US8412830B2 (en) | 2006-10-24 | 2013-04-02 | International Business Machines Corporation | Method and apparatus for improving SIP parse performance |
US8589567B2 (en) | 2006-10-24 | 2013-11-19 | International Business Machines Corporation | Method and apparatus for improving SIP parse performance |
WO2010106772A1 (ja) * | 2009-03-17 | 2010-09-23 | 日本電気株式会社 | 分散処理システム及び分散処理方法 |
US9167031B2 (en) | 2009-03-17 | 2015-10-20 | Nec Corporation | Distributed processing system and distributed processing method |
Also Published As
Publication number | Publication date |
---|---|
EP1599015A1 (en) | 2005-11-23 |
KR20060048035A (ko) | 2006-05-18 |
CN1700680B (zh) | 2012-03-14 |
CN1700680A (zh) | 2005-11-23 |
US20060031536A1 (en) | 2006-02-09 |
US8024476B2 (en) | 2011-09-20 |
KR101120695B1 (ko) | 2012-03-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2005339550A (ja) | サーバプール使用時の効率のよいメッセージ経路指定 | |
US8402146B2 (en) | End-point identifiers in SIP | |
JP4738060B2 (ja) | データ通信網のセキュアな連合 | |
JP5143125B2 (ja) | ドメイン間情報通信のための認証方法、システム、およびその装置 | |
JP5043392B2 (ja) | Sip通信セッションをセットアップする方法、並びに、そのシステム及びコンピュータ・プログラム | |
Rosenberg et al. | SIP: session initiation protocol | |
US8055778B2 (en) | SIP user agent with simultaneous multiple registrations | |
US20070078986A1 (en) | Techniques for reducing session set-up for real-time communications over a network | |
EP1643406A2 (en) | Registration identifier reuse | |
JP4684897B2 (ja) | セッションに対して制限を課すための方法およびシステム | |
JP2006094488A (ja) | 経路情報に関するストレージ要件の軽減 | |
US8966089B2 (en) | Supporting proxy discovery | |
CN101471938B (zh) | 一种点对点p2p网络中的认证方法、系统和装置 | |
Institu et al. | Peer to |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080519 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20111007 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120110 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20120817 |