JP4536999B2 - スクリーニングによって、複数のネットワークを流れるリアルタイムトランスポートプロトコルの制御を支援するシステム及び方法 - Google Patents

スクリーニングによって、複数のネットワークを流れるリアルタイムトランスポートプロトコルの制御を支援するシステム及び方法 Download PDF

Info

Publication number
JP4536999B2
JP4536999B2 JP2002550693A JP2002550693A JP4536999B2 JP 4536999 B2 JP4536999 B2 JP 4536999B2 JP 2002550693 A JP2002550693 A JP 2002550693A JP 2002550693 A JP2002550693 A JP 2002550693A JP 4536999 B2 JP4536999 B2 JP 4536999B2
Authority
JP
Japan
Prior art keywords
route
policy
sip
address
carrier
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.)
Expired - Lifetime
Application number
JP2002550693A
Other languages
English (en)
Other versions
JP2004538671A (ja
Inventor
パトリック ジェイ． メランピー、
アンドリュー ディ． オリー、
クリフォード エム． スペンサー、
ロバート エフ． ペンフィールド、
ピーター エス． カマーフォード、
スティーブン ティ． ヴォト、
シンシア イー． アレンズ、
レベッカ エー． ペダーセン、
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Acme Packet Inc
Original Assignee
Acme Packet Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Acme Packet Inc filed Critical Acme Packet Inc
Publication of JP2004538671A publication Critical patent/JP2004538671A/ja
Application granted granted Critical
Publication of JP4536999B2 publication Critical patent/JP4536999B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • 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/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H04L45/124—Shortest path evaluation using a combination of metrics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • H04L45/3065—Route determination based on the nature of the carried application for real time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/308—Route determination based on user's profile, e.g. premium users
    • 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
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42136—Administration or customisation of services
    • H04M3/42144—Administration or customisation of services by service provider
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/128—Details of addressing, directories or routing tables
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0025—Provisions for signalling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H04Q3/0045—Provisions for intelligent networking involving hybrid, i.e. a mixture of public and private, or multi-vendor systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/64—Distributing or queueing
    • H04Q3/66—Traffic distributors
    • 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
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13034—A/D conversion, code compression/expansion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13097—Numbering, addressing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13103—Memory
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13106—Microprocessor, CPU
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13138—Least cost routing, LCR
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13141—Hunting for free outlet, circuit or channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13166—Fault prevention
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13176—Common channel signaling, CCS7
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13204—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13299—Bus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13332—Broadband, CATV, dynamic bandwidth allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13345—Intelligent networks, SCP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13348—Channel/line reservation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13352—Self-routing networks, real-time routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13376—Information service, downloading of information, 0800/0900 services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13384—Inter-PBX traffic, PBX networks, e.g. corporate networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389—LAN, internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13395—Permanent channel, leased line
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13399—Virtual channel/circuits

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Control Of Conveyors (AREA)

Description

（関連出願の相互参照）
この出願は、２０００年１２月１１日に出願され、「通信セッション開始の為のルーティング方法および装置」の名称を持つ、米国仮出願番号第６０／２４，８４０号の優先権を主張するとともに、その全内容をこの出願の一部とする。
本発明は、一般に電気通信ネットワークに関するものであり、特に、複数のネットワークを通って流れるリアルタイムトランスポートプロトコルのフロー制御を支援する為のセッションルータを提供するシステムと方法に関する。
（発明の背景）
公衆電話交換網（ＰＳＴＮ）は、効率的で、リアルタイム処理の可能な、マルチメディア通信セッションツールへと発展し、そこでは、ユーザーは、ほぼ１０億台の電話のうちのいずれでも選ぶことができ、ほぼ１０億のエンドポイントのどの１つへでも、ダイヤルすることができる。いくつかの研究開発によって、番号割り当て計画、分散電子交換およびルーティング、ネットワーク化されたシグナリングシステムといった、自動ネットワークが可能となった。
番号割り当て計画は、地方、地域、および国の関係当局の後援により、数年にわたって発展していった。現在、Ｅ．１６４と呼ばれるＩＴＵ−Ｔ標準に基く、これらの番号割り当て計画によって、呼び出しのルーティングを可能とする、一般的で階層的な計画が提供されている。以下に、北アメリカの番号割り当て計画（ＮＡＮＰ）の階層の例を示す。電話番号１−９７８−９３３−６１６６を考えると、１は、この電話番号がＮＡＮＰのものであることを示す。９７８は、それがマサチューセッツのエリアコードであることを示す。９３３は、それがウォーバーン（マサチューセッツ）の交換局番号であることを示す。また、６１６６は、それがニューボストン街１３０番のアクメパケットに割り当てられた番号であることを示す。
同様にして、すべての電話番号は世界で、同様の番号要素に分解でき、地理的には、どのネットワーク要素（例えば、電話交換機）で、通信が完了させられるかによって決定される。近年、ポータブル番号の技術が実装され、企業が、その電話番号を機器毎に移動可能とすること、例えば、移動させたり、再度、割当て行うことができるようになっている。最初、この技術は、料金無料の電話番号（例えば１−８００−ＦＬＯＷＥＲＳ（ＴＭ））に利用され、所有者が長距離通信会社に変更することを可能にした。このポータブル番号の発展により、８００番の交換番号は、フリーダイヤル交換局として認知され、データベース（つまりサービス制御点（ＳＣＰ））で、固定階層に結びついた実際のネットワーク番号に変換される。８００番或いは料金無料の電話番号を実際の番号（シャドウアドレス）に分解するプロセスは、よく知られている。
更に、最近、ローカルの番号をポータブルにする開発が行われている。この技術は、交換番号がポータブルであると宣言され、データベース（つまりＳＣＰ）が、実際の番号の場所を特定する為に利用されるという点で、上述のような無料技術と類似している。返される場所は、実際には、終端切換スイッチの電話番号である。そして、その呼び出しは、シグナリングシステム＃７（ＳＳ７）のネットワークの仮想番号に対応付けられ、初期アドレスメッセージ（ＩＡＭ）中のエンドポイントへの個別の情報要素としての、実番号に受動的に当てられる。再度、呼び出しを送る為に使用される番号は、固定階層に準じた実番号であった。このローカル番号のポータビリティ（ＬＮＰ）も、よく知られている。
無線のネットワークで、ホームロケーション登録（ＨＬＲ）およびビジッタロケーション登録（ＶＬＲ）メカニズムが使用される。無線のネットワーク内では、電話は、それが通信することができるネットワーク上で、繰り返し登録すべきである。ユーザーに適切に呼び出しを向けることができるように、この登録は、電話位置をネットワークに通知する。ローカルのシステム（つまり非ローミング）内にある電話への呼び出しを送る為に、対応する設備は、正確なベースステーションからの呼び出し又はベースステーションへの呼び出しをルーティングさせることができるようになっている。システム間の呼び出しを送る為に、仮想番号が割り付けられており、新しい呼び出しは新システムへ向けられ、その後、それは新しいエンドポイントに電話を接続する。無線のネットワークでは、割当てられた仮想番号が、確立された階層に結びつけられる。
残念ながら、現在、ＰＳＴＮは、ＰＳＴＮの中にある階層に対応するアドレス以外には、実際の通信セッションをルーティングさせることができない。なぜなら、電話番号やその一部は、通信のエンドポイントへのパスを発見する為に使用されるからである。ポータビリティメカニズムは、ネットワークを通って通信を方向付けする為に仮想番号またはシャドウ番号が必要である。
ＰＳＴＮの階層に基づく方法に似て、インターネットはインターネットプロトコル（ＩＰ）に基づいている。ＩＰメッセージは、１つのリンクから次のリンクへ（つまりデータフローの始点からデータフローの終点まで）、ルーティング又は転送される。各ＩＰパケットは、ＩＰアドレス（インターネットプロトコルバージョン４（ＩＰｖ４）では、３２ビット）を含んでいる。各ＩＰアドレスは、さらに、ネットワーク部分を示すビットと、ホスト部分を示すビットを有している。
ＩＰルータは、１つのネットワーク（あるいはリンク）からパケットを受け、かつ別のネットワーク（あるいはリンク）へにそれを渡すために使用される。ＩＰルータの内には、テーブルが設けられており、そのテーブルには、パケットの最適のルーティングを決定するのに利用できる情報あるいは基準を含んでいる。この情報の例はネットワークリンクの状態およびプログラムされた距離表示である。残念ながら、典型的に、ＩＰルータは、終点ＩＰアドレス（それは転送のための適切なルートの探索には役立たない）によってパケットのルーティングを行う。一方、このルーティングシステムのいくつかの例外がある。ネットワークドメインの両側でインテリジェントな装置を使用することによって、ネットワークを通ってパケットを転送する為に一時的なアドレスを割り付け、かつネットワークの向こう側でパケットが、ネットワークを離れた時に、オリジナルのアドレスを回復することは可能である。これは多くの現在のヴァーチャルプライベートネットワーク（ＶＰＮ）の基礎であり、業界でよく知られている。
ルーティングさせるシステムのもう１つの例外は、マルチプロトコルラベルスイッチング（ＭＰＬＳ）である。ＭＰＬＳは、タグスイッチングと呼ばれ、カリフォルニア洲サンノゼのシスコシステムズによって開発された技術に基づいている。ＩＰパケットをルーティングさせるこの方法は、パケットがネットワークを通って現実にとるルートと、終点ＩＰアドレスとを潜在的に分離することを可能にする。ＭＰＬＳの最適の用途のうちの１つは、ＶＰＮ或いはヴァーチャルリーズドラインズ（ＶＬＬ）を作成することである。ＭＰＬＳタグは、ネットワークを通ったデータパケットのルーティングを有効にカプセル化することを可能とする。
つまり、データネットワークは、ＩＰ終点に基づいて、実際のすべてのＩＰパケットフォワーディングを行うということである。一方、ＩＰ終点は、ネットワークトポロジーに関係していて、電話ネットワークのように、パケットを運ぶために使用される。ＭＰＬＳタグおよびパスは、ルーティングに用いられ、ＩＰアドレス部分に結び付けられる一組のルール、例えば、同一ラベル転送クラス（フォワードエキュイバレンスクラス：ＦＥＣ）に基づいて、ＩＰパケットのためにオーバーライドフォワーディングを可能とする。
分散されたスイッチング及びルーティングは、要求されたサイズのネットワークスケールを構成する為に重要である。分散されたスイッチングルーティングの為の電子設備は、通信セッションに一定の役割を持つ必要がある。もしすべてのエンドポイントが各エンドポイント毎に接続を管理しなければならなければ、ネットワークのスケーリングはできないであろう。階層的スキームの中への制御を分配すれば、下層のアドレシングの変更に伴う困難を、さらに増大させることになる。
それらは、ネットワーク要素（例えば電話ネットワーク中のスイッチやデータネットワーク中のルータ）による関連するタスクの実行を保証する為に、それらは、隣接した通信リンクおよび利用可能なルートのステータスを知っていなければならず、シグナリングシステムはこの情報を提供する為に使用される。電話ネットワークでは、使用されるシグナリングシステムは、ＳＳ７のいずれか、あるいはＳＳ７と等価なものである。シグナリングシステムは、個々のリンク、リンクセット、ルートなどに関する情報を示す。データネットワークでは、ボーダーゲートウェイプロトコル（ＢＧＰ）、内部のゲートウェイプロトコル（ＩＧＰ）、オープンショーテストパスファースト（ＯＳＰＦ）などのようなプロトコルは、リンク状態およびルートを決定する為に使用される。
電話ネットワークでは、シグナリングシステムは、ネットワーク経由で「ｅｎｄ−ｔｏ−ｅｎｄ」パス（即ち、ＩＳＵＰ：ＩＳＤＮユーザパート）を確立するのに使用される。残念ながら、ＩＰネットワークでは、「ｅｎｄ−ｔｏ−ｅｎｄ」のパス割付けは存在しない。代わりに、通信セッションを処理する為に、名前または目的にエンドポイントを関連付けるシステムがなければならない。
今日の電話ネットワークは、イエローページ、ホワイトページ、４１１のディレクトリーシステムおよび、他のネットワークのユーザーが目的の場所を見つけるのを助けるディレクトリーサービスを使用する。ビジネスの電話番号が変更されるか、人々が移動すれば、ディレクトリーは更新される。さらに、ほとんどの電話ネットワークは、呼び出しを転送するか、ユーザーのアドレスが新しくなったことを、発信側に伝えるであろう。同様に、今日のデータネットワークは、ユーザーが他のインターネットユーザーを見つけるのを助ける為に、オンラインディレクトリーを使用する。しかし、これらのディレクトリーは多くの理由で不十分である。例えば、これらの理由としては、次のようなものがある。即ち、ほとんどのディレクトリーが電子メール（電子メール）サーバから構築されるので、情報の質は低い。又、ビリングプロセスの一部として維持されていないので、それはほとんどの電子メールシステムで古くなったエントリを生じさせる。更に、すべての電子メールシステムが、ディレクトリー供給者にデータを供給するわけではない。
加えて、もしディレクトリーエントリが手動で入力されない限り、地理的な位置はインターネットドメインアドレスの一部ではないので、インターネットディレクトリは地理的な位置を含んでいない。電話ネットワークのユーザーの場所を特定しようとする場合、都市か町が知られていれば、探索を限定的にすることができる。しかし、この種類の探索は、インターネットディレクトリにおいては、同じようには容易ではない。ユニフォームリソースロケーター（ＵＲＬ）は、典型的にはインターネット上のエンドポイントあるいは位置を示す。ドメイン名に付けられたユーザー名は、ユーザーのアドレスを得る、現在の方法である。そこで、ドメイン名は、ユーザーにそれを使用させている組織によって所有されている。
インターネット上に、包括的なレジストリは現在知られていない。ドメイン名E164.comを備えた包括的なレジストリが、マサチューセッツローウェルのＮＥＴＮＵＭＢＥＲ．ＣＯＭ社によって提案された。この包括的なレジストリの開発は、ＮＵＥＳＴＡＲ社の提案に基づいている。ＮＵＥＳＴＡＲ社は、今ＮＡＮＰの管理を行っている。この提案は、現在のドメイン名サービスを利用し、ＤＮＳサーバで解決できるように、番号のフォーマットをＵＲＬへ変換する。この方法では、各電話番号をＤＮＳサーバへ登録し、他のすべてのＤＮＳサーバへ配布する。ＤＮＳクエリの末端は、例えば、リソースレコードであり、それは、ライトウェイトディレクトリーアクセスプロトコル（ＬＤＡＰ）のディレクトリーサーバである。
従来の有線電話番号とのオーバーラップを回避する為に、ＩＰエンドポイントの包括的なポータブル電話（ＵＰＴ）番号の使用が、ＩＴＵにより提案されているが、これは有効であり、アドレス可能なＩＰエンドポイントを実現する。インターネットとＰＳＴＮ間での呼び出しを可能にする、上記の２つの提案を組み合わせることは可能である。残念ながら、この技術にいくつかの制限がある。これらの制限は次のものを含んでいる。即ち、ＤＮＳの分配および複製はかなりの待ち時間を持っている。又、ＤＮＳアドレス解決は、遅くなることがある。更に、ＤＮＳサーバは、向けられた数のアドレスをすべて扱う能力を持つとは限らない。更に、ＤＮＳサーバは、ラウンドロビンを使わない限り、複製のエントリを管理することができない。更に、ＤＮＳは、並列の更新メカニズムを使用しており、意図しない複製のエントリを生成する可能性がある。更に、プライベートネットワークアドレスあるいはそのアドレッシングを行うゲートウェイは、複製のエントリあるいはそのマッチングを生じさせる可能性がある。更に、要求された資源を扱うポリシーが存在しない。更に、ＰＳＴＮとデータネットワークの間の数値のオーバーラップを解決する手段が無い。
ＰＳＴＮベースのシステムでサービスを受けている今現在の電気通信ネットワークエンドポイントの為に、ゲートウェイを使用して、パケットデータネットワークとＰＳＴＮの間のメディアフローが促進される。ゲートウェイは、データネットワークおよび音声ネットワークの境界にインストールされ、そこで、ゲートウェイはメディア、またシグナリング、を変換し、通信を確実にするのに使用される。ゲートウェイで受けた呼び出しを、この業界で知られた他のゲートウェイへ、ルーティングするいくつかのストラテジーがある。これらのストラテジーの２つは、フルメッシュルーティングと階層型ルーティングである。フルメッシュルーティングは、ほとんどのソフトスイッチングアーキテクチャーに記述された標準の方法である。セッションイニシエイションプロトコル（ＳＩＰ）は、任意の場所の間のシグナリングをサポートするので、ソフトスイッチ間シグナリングシステムである。このモデルでは、すべてのソフトスイッチが、呼び出しを完了する為に、他のすべてのソフトスイッチに対して、仮想接続を行っている。ソフトスイッチメーカーによって提供されるポリシーに基づくソフトスイッチへ、トラヒックを向ける為に使用することができるルーティングテーブルが実装されている。
残念ながら、多くのソフトスイッチから成るネットワークを稼働する場合、ネットワークの所有者は、フルメッシュを作成する為に維持される必要のある、多くの異なるポリシー管理ポイントを抱えている。そのようなポリシー管理問題は、各ソフトスイッチが「他のソフトスイッチの各々のＩＰアドレスと、それらが接続している電話番号やＰＳＴＮを知っている」ことを確実にする問題を含んでいる。複数のベンダーからのソフトスイッチを稼働する場合、さらなる管理問題が発生する。管理問題は、設備が異なるインターフェースを通って管理される場合より複雑となる。
配置されたソフトスイッチの数が大きい場合、異なるルートの共有が起こりやすくなる。フルメッシュルーティングアレンジメントでは、いくつかの異なる出力ソフトスイッチが一杯であるか機能していないかもしれないので、呼び出しのルーティングが困難となることもある。例えば、キャリアが、国内長距離電話を扱うことができる３０のソフトスイッチを備えており、ネットワークが、約５０％で稼働している場合、塞がっていないルートを備えた一つのソフトスイッチを見つける為に、各々の起点ソフトスイッチは、平均１５の別個のソフトスイッチを試みなければならない。純粋なランダム分散が実装されれば、この探索努力は大幅に縮小されるが、いくつかのルートが、コストまたは質の問題で、他のものよりも優先的に扱われ、そのために、その問題を悪化させることも考えられる。
例えば、ＣＩＳＣＯ ＡＳ５３００のように、単純なゲートウェイの場合、ＳＩＰベースの呼び出し要求を、ＳＩＰプロキシサーバに転送できる。残念ながら、これらのゲートウェイは、密度が低く、ルーティングポリシーをセットアップする場合には、しばしば、機能性に劣る。したがって、これらのルータは、ソフトスイッチコントローラーがなくては、ネットワークを形成する為に相互に連結することができない。
階層型ルーティングでは、ネットワークが異なるレイヤーへ分けられている。これらのレイヤーは、任意の場所へのルーティングを可能とするピラミッド型へ、相互接続されている。この方法は現在のＰＳＴＮの基礎である。階層型ルーティング方法は、階層モデルを使用しており、そこでは、階層中の層の数は、ネットワークのサイズに依存する。今日のインターネットは、このような階層モデルには、なじまない。実際、ある場所から別の場所へ行く、多くの可能なルートと共に、インターネットの多くをフルメッシュと見做すことができる。ＢＧＰの主要な設計ゴールのうちの１つは、どれくらい多くの異なる相互連結が存在するかを示している複数の遠回りのルートを回避することである。
ＰＳＴＮにおいて、ネットワークへの階層的アプローチは、ローカル、国内長距離および国際的電話のネットワークに基づく標準としてふさわしく、ビジネスおよび政治的境界は、この階層的モデルを支援している。標準のＨ．３２３プロトコルベースの、ボイスオーバインターネットプロトコル（ＶｏＩＰ）の初期の実装は、全体の配備にあたって、階層的モデルの方へ傾いていた。
残念ながら、今日のピア環境にそれを適用しようとする場合、階層的モデルは複雑になる。ビジネスか政治的な状況から、階層のより高いレベルが、あるエンティティによって所有され、データネットワークが階層を厳守しない場合、どのように所有権およびピアの問題を解決することができるかを想像することは困難である。データネットワーク所有者が同じビジネスで競争しているので、ピアを行う準備（それらは互いに有益ではない）を確立することはありそうもない。階層的モデルは、さらにより大きな波及効果に結びつく、シングルポイント障害を生み出す。パブリックデータネットワークＰＤＮは、シングルポイント障害なしで発展しており、分散ピア配置に多くの出資を行っている。これを考慮すると、シングルソフトスイッチは、ネットワークの大きな部分に影響を与える可能性があり、賢明でない。
階層的モデルは、階層のすべてのポイントで、ルートコンフィギュレーションを注意深く使用する。即ち、どの２つのソフトスイッチも、同じコンフィギュレーションを持つことができず、どの２つのソフトスイッチも、特定の通信が通過するルートを予測することができない。したがって、階層型ルーティングシステムは、信じられないほどに統合された方法で、分散ルート計画を使用する。最後に、階層的モデルは、「ｅｎｄ−ｔｏ−ｅｎｄ」の適切なルーティングを保証するように、ベンダーが、同様のシグナリングシステムに従うようにする。例えば、適切なルーティングを可能にする為に、各ソフトスイッチは、回路利用可能性に関する情報を共有し、保証するべきネットワークが一杯になっても、適切な迂回機能を保証しなければならない。現在、これを遂行する為の基準がないので、ベンダーは独自の方法を構築している。これらの独自の方法では、正しい相互運用が可能とは限らない。
発明を解決するための手段
上記の通り、本発明の好ましい実施形態は、一般に、複数のネットワークを通るリアルタイムトランスポートプロトコルフローの制御を支援するシステムと方法に関する。
一般に、このシステムは、制御を行うシステムの構造に関し、このシステムは、第１のコンピュータと、第１のコンピュータに接続された第２のコンピュータを少なくとも備えている。第２のコンピュータは、第２の送受信機、第２のコンピュータによって実行される機能を定義するロジックを保存する第２のメモリ、及び第２のプロセッサを備えている。第２のプロセッサは、第１のコンピュータから、第２のコンピュータによって受信したルート情報において境界内のスクリーンを実行して、受信したルート情報が破棄されるべきかを決定し、ルート情報が破棄されない場合、受信しスクリーニングされたルート情報を、第２のコンピュータで定義されたローカルポリシーと比較し、受信しスクリーニングされたルート情報を送信する前に、受信しスクリーニングされた情報において、境界外のスクリーンを実行する機能を実現するために、第２のメモリによって定義されている。
一方、本発明は、複数のネットワークを通るリアルタイムトランスポートプロトコルフローの制御を支援する方法としてみることもできる。この点から、この方法は、次のステップによって要約できる。即ち、第１のエンドポイントから第２のエンドポイントへのルートに関する情報を受信するステップと、受信したルート情報において、境界内のスクリーンを実行し、受信したルート情報を破棄するかを決定するステップと、ルート情報が破棄されなかった場合、受信しスクリーンされたルート情報をローカルポリシーと比較するステップと、受信しスクリーンされた情報において、境界外のスクリーンを実行し、受信しスクリーンされた情報を送信するステップである。
本発明の他のシステムおよび方法は、次の図面および詳細な記述を読めば、当業者にとって明白である。そのような更なるシステム、方法、特徴、利点のすべては、この記載および本発明の範囲に含まれ、かつ添付のクレームによって保護されるべきである。
本発明によって、複数のネットワークを流れるリアルタイムトランスポートプロトコルを制御するのを支援する制御システムが提供される。本発明の制御システムは、ソフトウェア、ファームウェア、ハードウェア、あるいはそれらの組み合わせとして実装することができる。本発明の好ましい実施形態において、制御システムの一部は、例えば、パソコン、ワークステーション、ミニコンピュータあるいはメインフレームコンピュータ等で実行されるソフトウェアによって、実装することができる。しかし、この実施形態に限定されるものではない。
制御システムの、ロジック機能を実装する実行可能な命令の列であるソフトウェア部分は、コンピュータベースのシステムプロセッサを含むシステム等の命令実行システム、装置、または機器や、あるいは、命令実行システム、装置、または機器からの命令を取り込み、命令を実行できる他のシステムによって、使用されるか、またはこれらと共に使用される任意のコンピュータ読み取り可能な記録媒体にて実現することができる。本明細書では、「コンピュータ読み取り可能な記録媒体」とは、命令実行システム、装置、または機器によって使用されるか、またはこれらと共に使用されるプログラムを含有、格納、伝達、伝播、または伝送することのできる任意の手段とする。コンピュータ読み取り可能な記録媒体とは、例えば、電子、磁気、光、電磁気、赤外線、または半導体のシステム、機器、または装置、或いは、伝播媒体である。もちろん、これに限定はされない。コンピュータ読み取り可能な記録媒体のより具体的な例（ただし、完全に列挙していない）としては、１本以上のワイヤを有する電気接続機器（電子）、携帯可能なコンピュータディスク（磁気）、ランダムアクセスメモリ（ＲＡＭ）（磁気）、リードオンリメモリ（ＲＯＭ）（磁気）、消去可能プログラム可能リードオンリメモリ（ＥＰＲＯＭまたはフラッシュメモリ）（磁気）、光ファイバ（光）、および携帯可能なコンパクトディスクリードオンリメモリ（ＣＤ ＲＯＭ）（光）が挙げられる。ただし、コンピュータ読み取り可能な記録媒体はプログラムが印刷された紙や他の適当な媒体でもよく、プログラムは、例えば紙や他の媒体のオプティカルスキャニングによって電子的に取込まれ、その後コンパイルされ、解釈されるかまたは適当な方法で処理され、その後、必要であればコンピュータのメモリに格納される。
図１は、発明の好ましい実施形態による複数のドメインを含む通信ネットワーク１００を示すブロックダイヤグラムである。基本的に、図１はボイスオーバインターネットプロトコル（ＶｏＩＰ）の実装で用いられるインターネットワーキングの典型的な例の多くを代表するものである。第１のおよび第２の自律システム（ＡＳ）１０２、１０４は、第１のセッションルータ１２２によって、互いに接続されている。この分野で良く知られているように、１つの自律システム（ＡＳ）は、１つの技術的な管理下におけるルータの集まりであり、パケットルーティングの為に、ＡＳ内で共通の重み付けの基準を持つインターリオールゲートウェイプロトコルを用いるとともに、他のＡＳへのパケットルーティングに外部ゲートウェイプロトコルを使用する。典型的には、ＡＳは共通の管理権限によってグループ化されたボーダーゲートウェイプロトコル−４（ＢＧＰ−４）ルータの集まりである。しかし、ＡＳは、インターネット電話管理ドメイン（ＩＴＡＤ）となり得る。ＩＴＡＤはＢＧＰ−４のＡＳに似ているが、それらはセッションルーティングのための共通の管理エンティティを共有する、テレフォニールーティングインターネットプロトコル（ＴＲＩＰ）ルータ（以下に詳細を記述）上のグループを示すために使用される。以下、ＡＳ１０２および１０４ではなく、それぞれＩＴＡＤ１０２および１０４として参照するが、ＩＴＡＤへの参照は、ＡＳで交換可能であることに理解すべきである。
第１の管理ステーション１１２は第１のＩＴＡＤ１０２の内に設けられている。また、第２の管理ステーション１１４は第２のＩＴＡＤ１０４の内に設けられている。管理ステーション１１２、１１４は準備機能、モニタリング、およびそれぞれのＩＴＡＤ１０２、１０４の内のセッションルータの診断機能を示す。好ましくは、管理ステーション１１２、１１４はＪＡＶＡ仮想マシンを実行し、セッションルータからＪＡＶＡアプリケーションを受け取る。Ｊａｖａアプリケーションは、リクエストおよび処理レスポンスをＸＭＬフォーマットの形式にして、通信を行う。
ＩＰキャリア（通信会社）１４２は第２のセッションルータ１２４によって第１のＩＴＡＤ１０２に接続されている。ＩＰキャリア１４２は、第３のセッションルータ１２６によって第２のＩＴＡＤ１０４にも接続される。第１のセッションルータ１２２によって、第１のＩＴＡＤ１０２と第２のＩＴＡＤ１０４とが互いにピアの関係となっていることを理解すべきである。さらに、第２のセッションルータ１２４は、第１のＩＴＡＤ１０２とＩＰキャリア１４２の間のピアの関係を示す。また、第３のセッションルータ１２６は、第２のＩＴＡＤ１０４とＩＰキャリア１４２の間のピアの関係を示す。
第１の長距離キャリア１５２は第１のゲートウェイ１７２経由で第１のＩＴＡＤ１０２に接続されている。好ましくは、ここでの長距離キャリアはＰＳＴＮシステムを用いており、そこではアナログで音声データを運ぶ銅線によって電話システムが構築されている。別の実装では、長距離キャリアは、ディジタルデータあるいはアナログおよびディジタルデータの組み合わせを扱ってもよい。さらに、好ましくは、ここでのゲートウェイは、ＰＳＴＮベースのネットワークとパケットベースのデータネットワークの間のメディアゲートウェイとシグナリングゲートウェイの両方をサポートする。第１の既存地域キャリア１６２も第２のゲートウェイ１７４経由で第１のＩＴＡＤ１０２に接続されている。第１のＩＴＡＤ１０２の内にある第１のソフトスイッチ（コールエージェント）２０２は、第１と第２のゲートウェイ１７２、１７４経由で、第１の長距離キャリア１５２および第１の既存地域キャリア１６２の両方にそれぞれ接続される。ここでのソフトスイッチは、メディアゲートウェイコミュニケーションプロトコル（ＭＧＣＰ）あるいは同等のプロトコルによって、ゲートウェイの制御を行う。別の実装では、インテリジェントゲートウェイは、ソフトスイッチを必要としないこともある、その場合、ソフトスイッチを使わない電話呼び出しに基づくセッション開始プロトコル（ＳＩＰ）により、ＩＴＡＤと直接通信することになる。
ＳＩＰは多くのキーメカニズムを定義するプロトコルである。第１のＳＩＰメカニズムは「登録」メッセージと呼ばれる。ＳＩＰプロキシサーバに送られた時、このメッセージは、エンドポイントが特定のユーザーのために通信を受けることができることを示す。この「登録」メッセージは、物理的なＩＰアドレスを、そのＩＰアドレスを使用するユーザーにバインドする。第２のＳＩＰメカニズムは「招待（ＩＮＶＩＴＥ：インバイト）」メッセージである。このメッセージは通信セッションを要求するルータにもう一方のエンドポイントに送られる。「招待」メッセージは、着信側のエンドポイントまで送られる。その後、「招待」の着信側は、通信が受理されたことを示す「ＯＫ」メッセージで応答する。エンドポイントが少なくない場合や、あるいはある特徴を必要とするエンドポイントがある場合、ＳＩＰプロキシサーバは仲介役として機能する。ＳＩＰプロキシサーバは、前もって「登録」メッセージを送信したユーザーのために、「招待」メッセージを受け取り、これを転送する。
図２は、ＳＩＰプロキシを介して行われる２つのＳＩＰエージェント間の対話を示す詳細図である。例えば、ユーザーが第１のＳＩＰユーザーエージェント２４４から「登録」メッセージ２４２を送れば、ＳＩＰプロキシサーバ２４６はその「登録」を受理する。そして、第２のＳＩＰユーザーエージェント２４８が、「登録」メッセージ２４２を送信したユーザーのために、第一の「招待」メッセージ２５２を送れば、この第一の「招待」メッセージ２５２は、ＳＩＰプロキシサーバ２４６によって受理される。その後、ＳＩＰプロキシサーバ２４６は第１のＳＩＰユーザーエージェント２４４へ第２の「招待」メッセージ２５４を転送する。第１のＳＩＰユーザーエージェント２４４が第２のＳＩＰユーザーエージェント２４８からコミュニケーションを受理する意志があれば、第１のＳＩＰユーザーエージェント２４４は、ＳＩＰプロキシサーバ２４６に、承認のメッセージを送信し、その後、ＳＩＰプロキシサーバ２４６は、その承認のメッセージを第２のＳＩＰユーザーエージェント２４８に送信する。
第３のＳＩＰメカニズムは「バイ（ＢＹＥ）」メッセージであり、それは一方的にコミュニケーションセッションを送り、使用中のネットワークリソースをすべて解放するものである。コミュニケーションのいずれの側も、いつでも「ＢＹＥ」メッセージを送ることができる。ＳＩＰアーキテクチャーで実装されたものは、ユーザーがそこで任意のＩＰアドレスあるいは位置から彼のホームＳＩＰプロキシサーバにユーザーが「登録」メッセージを送ることができ、通信を受け始めることができるという、可動性を備えているということである。ＳＩＰの詳細な記述は、ＨＡＮＤＬＥＹらによって「ＳＩＰ：セッション開始プロトコル」として提供されている。これは、１９９９年３月の日付でドラフト番号ｒｆｃ２５４３を持つインターネットのドラフトであり、その内容をこの出願の一部とする。以下に、このＳＩＰプロトコルを、更に論じることとする。
図１に戻って、エンタープライズネットワーク１９２は第４のセッションルータ１２８によって第１のＩＴＡＤに接続されている。エンタープライズネットワーク１９２は、第１の構内交換機（ＰＢＸ）２１２に接続する第３のゲートウェイ１７６を含んでいる。当業者に知られているように、ＰＢＸのユーザーは、ＰＢＸの外部との電話の呼び出しを行うための幾つかの外線を共有している。例えば、エンタープライズネットワーク１９２は、第４のセッションルータ１２８によって第１のＩＴＡＤに接続されており、マサチューセッツ州のＰＩＮＧＴＥＬ社で製造されているようなＳＩＰ電話２２２、および米国のニュージャージー州のＤＹＮＡＭＩＣＳＯＦＴ社で製造されているようなＳＩＰユーザーエージェント２３２（つまり、コンピュータ）を含んでいる。
第２の長距離キャリア１５４は第４のゲートウェイ１７８経由で第２のＩＴＡＤ１０４に接続されている。さらに、第２の既存地域キャリア１６４は第５のゲートウェイ１８２経由で第２のＩＴＡＤ１０４に接続されている。又、第２のソフトスイッチ（或いはコールエージェント）２０４が、第２のＩＴＡＤ１０４の内に設けられており、第４と第５のゲートウェイ１７８、１８２を介して、第２の長距離キャリア１５４および第２の既存地域キャリア１６４の両方にそれぞれ接続されている。第１のＩＴＡＤ１０２との関連で説明したように、インテリジェントゲートウェイは、ソフトスイッチを必要としないこともある、その場合、ソフトスイッチを使わないＳＩＰベースの電話呼び出しを生成することによって、ＩＴＡＤと直接通信することになる。
第２のＰＢＸ２１４は第６のゲートウェイ１８４経由で第２のＩＴＡＤ１０４に接続されている。さらに、例えば、第２のＳＩＰユーザーエージェント２３４および第２のＳＩＰ電話２２４は、第２のＩＴＡＤ１０４に接続されている。セッションルータ、ＩＰキャリア、長距離キャリア、既存地域キャリア、エンタープライズネットワーク、ＰＢＸ、ＳＩＰ電話、ＳＩＰユーザーエージェント、ＩＴＡＤ、管理ステーションおよびゲートウェイは、数においても、又、図１との関係においても、特に限定されない。そして、上述の装置は、それぞれ幾つ設けてもかまわない。実際、装置の幾つかは省略されていると考えられる場合も有り、その場合でも、やはりマルチドメイン通信ネットワークのカテゴリーに含まれる。
各セッションルータ１２２、１２４、１２６および１２８は、いくつかのプロトコルを利用する。これらのプロトコルには、ＳＩＰ（上述の通りであるが、後に更に論じる）、セッション記述プロトコル（ＳＤＰ）、ユーザー／ユニバーサルデータグラムプロトコル（ＵＤＰ）およびインターネットプロトコル上の電話ルーティング（ＴＲＩＰ）が含まれているが、もちろん、これに限定はされない。ＳＤＰは、エンドポイントで用いられるセッションエンドポイントおよびリソースについて記述する。したがって、ＳＤＰは、オープンな方法で、メディアエンドポイントと対話する為の柔軟性のある方法となっている。ＵＤＰは、ＳＩＰユーザーエージェントおよびＳＩＰプロキシサーバを含む１つのシグナリングポイントから、別のシグナリングポイントまでＳＩＰメッセージを送信する為に使用されるプロトコルである。
現在、ＴＲＩＰはインターネットドラフトフォームに含まれている。ＴＲＩＰの提案は、ポリシーに基づいて、ドメインを超えて到達可能な電話先に関する情報を共有する為に、ＢＧＰ−４に似たプロトコルを使用することである。更に、その提案では、ドメイン内のルーティング情報を共有する内部システムについて記述されている。ＢＧＰ−４のように、このプロトコルは、接続されているエンティティ間でルートの集成および伝達（注流：フラッディング）をサポートする。これらの特徴は、電話番号ルーティングのためのスケーラブルなソルーションを示す。ＴＲＩＰは、ＩＰネットワーク上の電話で呼び出しを行った側が、ＰＳＴＮへのゲートウェイを見いだせるように設計された。加えて、このプロトコルは、特定のポリシーに基づいて、呼び出しをデータネットワークへ入れ、そして、最適の出口のゲートウェイ見いだすことをサポートする。
ＴＲＩＰは、以下のように、簡潔に記述することができる幾つかの属性を備えている。ＴＲＩＰの第１の属性はルート広告である。サポートされたルートが、各ＴＲＩＰサーバに提供され。そこでは、サポートされたルートは、ＴＲＩＰの「更新された（ｕｐｄａｔｅ）」メッセージの一部として、各隣接したサーバに広告される。ＴＲＩＰの第２の属性はルート集成である。特に、異なるネットワークから、これらのルートが隣接するネットワークに広告される場合、入力ルートの集りは、隣への情報の転送を簡単にする為に集成される。ＴＲＩＰの第３の属性は境界でのポリシーである。各ルータは、広告されたルートのプログラム可能なセットを持つことができ、各境界ルータは、受け取ったルートを受理するか否かをプログラムできるので、完全なポリシー管理システムが実現する。
現在のところ、残念ながら、ＴＲＩＰは次のものをサポートしない。即ち、発着ペア（つまり発信側と受信側）によるルーティング、要求側のキャリアによるルーティング、時間や曜日によるルーティング、ドメイン記述（つまり、ドットで区分された記述））を用いて逆にＤＮＳ／ＥＮＵＭ着信側へ解決すること（ここで、ＥＮＵＭはＥ．１６４番号（国際電話番号割り当て計画））、そして、現在のエンドポイントのキャパシティーベースのルーティングである。さらに、ＴＲＩＰは、ある位置から別の位置へのＳＩＰメッセージを送る為に、どのようにＴＲＩＰ情報を使用すべきかに関しては規定していない。したがって、ＴＲＩＰによって送受信された情報を使用するシステムのインプリメンテーションは、公開されない。
発明の好ましい実施形態によるＴＲＩＰの使用は、これらＴＲＩＰの問題点を解決するものである。実際、発明の好ましい実施例では、Ｅ．１６４スタイルの番号割り当て、インターネットスタイルのエンドポイントアドレス（ＵＲＩ）、および従来の電話アドレス（ＳＩＰおよび非ＳＩＰ）を含む範囲の、ネットワークルートの利用可能性を広告する。以下に言及されるように、エンドポイントへの最適のルートは、コスト、時刻およびサービスの質に基づいて選択されている。さらに、発着ペア（つまり発信側と受信側）によるルーティング、要求側のキャリアによるルーティングが提供される。さらに、発明の好ましい実施形態によれば、ポリシーが広告されるか否かに関して、将来の日付をセットできる。
セッションルータが、ＳＩＰ招待を正確な位置へ送る為に、電話ルーティング情報ベース（ＴＲＩＢ）が、各フォワーディングポイントで、あるいは発明の好ましい実施形態によれば各セッションルータで構築される。このＴＲＩＢは、ＳＩＰ招待を受け取った際に処理する一組のポリシーを含み、これにより、可能な適用規則の一組が選択される。発明の好ましい実施形態によれば、１つのポリシーは、１つ以上の着信側アドレス、共通の次の転送先および１つ以上のキャリアを共有する１つ以上の起点アドレスを含んでいる。
ＴＲＩＢを計算する為に、ローカルポリシーを定義し確立する必要がある。図３Ａおよび図３Ｂは、発明の好ましい実施形態によるセッションルータ上に格納されたポリシーを示すデータマップを示す。図３Ａおよび図３Ｂによって示されているように、ポリシーは次のデータオブジェクトを含んでいる。即ち、キャリア３０２、管理アカウント３３２、隣接したルータ３４２、セッションルータ３６２、ＳＩＰエージェント４０２、ＳＩＰエージェントグループ４３２、そしてローカルポリシー４６２である。
キャリアデータオブジェクト３０２は、上流と下流のネットワークの関係を構成し管理する為に使用され、コンフィギュレーションの行われた１つのエンティティである。各キャリアは、他のデータオブジェクトで参照される名前３０４が与えられている。例えば、参照線３０１、３０３は、キャリア名３０４が、ローカルポリシー４６２の定義の中で、どのように使用されるかを示す。キャリア記述３０６は、キャリアに関するユーザー数やその他の記述を含む情報のために使用される。有効／無効フラグ（ＥＮＡＢＬＥＤ／ＤＩＳＡＢＬＥＤ）３０８は、キャリアおよび一カ所におかれた関連する全ポリシー属性４８６の有効／無効を設定する為に使用される。この機能はキャリア間の契約を管理するのに役立つ。キャリアインジケータコード（ＣＩＣ）（ＰＳＴＮ）３１２では、利用されている番号割り当て計画で、キャリアを識別する為にＰＳＴＮによって使用されるユニークな一連の数字が定義される。例えば、北アメリカでは、ＣＩＣは、ＮＡＮＰによって決定され割り付けられている（例えば、ＡＴ＆Ｔ社は、１０１０２８８のＣＩＣを備えている）。ＳＤＰ／ＦＩＲＥＷＡＬＬ／ＭＰＬＳフィールド３１４は、ＳＤＰフォーマット命令を含み、発信側や、各ネットワーク境界での使用される。
管理アカウントデータオブジェクト３３２は、ＳＲ（セッションルータ）を修正または形成しようとしているユーザーのために、その管理能力を定義する為に使用される。個々の管理ユーザーは異なるアクセス権３３４を持つことができる。発明の好ましい実施形態によれば、アクセス権３３４は、管理ステーション１１２、１１４（図１）を介してアドミニストレータがアクセスし自身を認証した時に決められ、後は、インターフェースとして参照される。発明の好ましい実施形態によれば、アドミニストレータは現在のルータを管理し維持する。ユーザーＩＤ３３６はアドミニストレータを認証する為にパスワード３３８と組み合わせて使用される。さらに、業界で知られているように、ＲＡＤＩＵＳ認証を使用することも可能である。参照線３０７は、セッションルータコンフィギュレーションの一部として含まれるアカウントのリストへの参照を示す。ここで、セッションルータは、セッションデータオブジェクト３６２によって識別される。又、各セッションデータオブジェクト３６２は、１つ以上の管理アカウント３３２を備えている。
以下に示すテーブル１はＳＲの一部で、アクセス権の異なるタイプを識別する。
Figure 0004536999
隣接ルータデータオブジェクト３４２は、現在のＳＲに隣接しているＳＲについて記述する。このオブジェクトは、すべてのＳＲのＴＲＩＰピアについて記述する為に使用される。ここで、ピアは、内部ピア（つまり同じＩＴＡＤ１１２、１１４の内のピア）および外部ピアの両方を含んでいる。ドメインアドレスフィールド３４４は、ＴＲＩＰデータの交換のためにＴＣＰ／ＩＰ接続を確立する必要のあるアドレス（ドメイン名あるいはドットで区切られたＩＰアドレスのいずれか）を示す。ＴＲＩＰ識別子フィールド３４６も、隣接ルータデータオブジェクト３４２（それは同じＩＴＡＤ１１２、１１４の内でＳＲ番号がローカルに割り当てられている）内で使用される。どんな整数値もＴＲＩＰ識別子３４６として使用することができる。しかし、好ましくは、ＴＲＩＰ識別子３４６は４オクテットの符号なし整数値である。ＩＴＡＤ識別子３４８は、隣接ルータデータオブジェクト３４２内に設けられており、好ましくは、整数値である。
ＳＲデータオブジェクト３６２は、特定のＳＲ（すなわち現在のＳＲ）のためのコンフィギュレーションについて記述する。そこでは、各ＳＲは、１つのＳＲデータオブジェクト３６２のみを備えている。ドメインアドレスフィールド３６４は、現在のＳＲが動作しているアドレスを格納する。好ましくは、各ＳＲは、ドメインアドレス上のＴＲＩＰ接続をポート６０６９でリッスンする。さらに、ドメインアドレス３６４は、推奨されるＳＩＰポート、好ましくはポスト５０６０でＳＩＰメッセージを送受信する為に使用される。ＴＲＩＰ識別子３６６は、同一のＩＴＡＤ１１２、１１４の中ではユニークな現在のＳＲに割り当てられた整数値である。ＩＴＡＤ識別子３６８は、ＳＲデータオブジェクト３６２内に設けられ、識別目的の整数値を与える。名前（ＮＡＭＥ）フィールド３７２は、ＳＲデータオブジェクト３６２内に設けられており、現在のＳＲに与えられたテキスト名を含んでいる。管理ステーション１１２、１１４は、プレゼンテーションの目的に、テキスト名３７２を使用する。
記述フィールド３７４は、さらにＳＲについての記述を行うために使用され、ＳＲと関係する任意のテキストを含むことができる。位置フィールド３７６は、地理的（緯度と経度）なコンフィギュレーションを含み、管理ステーション１１２、１１４から、適切にＳＲの位置を特定する為に使用される。ＴＲＩＰバージョンフィールド３７８は、ＳＲでサポートされた現在のＴＲＩＰプロトコルバージョンである。ＳＩＰバージョンフィールド３８２では、ＳＲでサポートされた現在のＳＩＰバージョンが参照される。ルータバージョン３８４では、ＳＲを構築するサーバおよびクライアントのためにインストールされたソフトウェアバージョンが参照される。管理アカウントフィールド３８６は、参照線３０７によって示されているように、現在のＳＲにアクセスする、管理アカウントの配列を示す。参照線３０５によって示されているように、隣接ルータフィールド３８８は、現在のＳＲに対して隣接するルータ３４２の配列を示す。既知のＳＩＰエージェントフィールド（Known Sip Agents）３９２は、現在のＳＲに知られているＳＩＰエージェントの配列を示す。通信を行うどんなＳＩＰエージェントも、このリストに載っているべきである。なぜなら、このリストは、通信の為に設けられているからである。有効／無効フィールド３９４は、現在のＳＲが、例えば、ＳＩＰエージェント４０２を含むそのピアおよび隣接したルータ３８８と、アクティブで対話可能か否かを示すフラグを含んでいる。
ＳＲに設けられているＳＩＰエージェントデータオブジェクト４０２は、ＳＩＰ電話あるいはＳＩＰユーザーエージェントのような（これらに限定されない）特定のＳＩＰエンドポイントについて記述する。好ましくは、ＳＩＰエンドポイントはプロキシサーバである。プロキシサーバは、ステートフルであっても、ステートレスであってもかまわない。ステートフルの場合、プロキシは、出力リクエストを生成した入力リクエストと、その出力リクエストを保持する。ステートレスのプロキシは、一旦出力リクエストが生成されれば、情報をすべて忘れる。例えば、分岐するプロキシと、ＴＣＰ接続を受け入れるプロキシは、ステートフルであるべきである。ＳＩＰエンドポイントはさらにユーザーエージェントであることもある。ドメインアドレスフィールド４０４は、ＳＩＰエンドポイントのインターネットアドレスを示す。名前（ＮＡＭＥ）フィールド４０６は、ＳＩＰエンドポイントのテキスト名を提供し、管理目的のために使用される。ＳＩＰエージェントデータオブジェクト４０２内の記述フィールド４０８は、ＳＩＰエンドポイントに関する付加的なユーザー数に関する情報を示す。登録間隔フィールド４１２はＳＲで登録しているＳＩＰエージェントの予想される登録間隔を示す。この間隔を超過した場合、ＳＲは、ＳＩＰエンドポイントは使用停止しているとみなすことが好ましい。したがって、０でない登録間隔４１２が与えられた各ＳＩＰエージェント４０２では、トラヒックの為に、「登録」メッセージが、登録間隔フィールド４１２によって定義された間隔内に受理された場合に、エンドポイントは利用可能と見なされる。間隔が０にセットされたエンドポイントについては、登録が期待されないか要求されない。
キャリアフィールド４１４は、ＳＩＰエージェントデータオブジェクト４０２内に設けられている。ここで、参照線３０９によって示されているように、ＳＩＰエージェントデータオブジェクト４０２は、キャリア名３０４の配列を備えている。キャリア名のリストは、ＳＩＰエンドポイントからの境界内のトラヒックに関連する、１つ以上のキャリアの配置を示す為に利用してもよい。以下に示されているように、キャリア配置は、境界外のルートのキャリア属性と比較された時、ルーティングポリシーを得る為に使用することができる。キャリア配置は、境界内のセッションの為に、特定のＣＩＣ３１２をシードする為に使用することができる。でなければ、そのようなものは１つもない。境界内のセッションを正しくルーティングする為に、ＣＩＣを使用する場合、キャリアフィールド４１４によって定義された配列中の第１のキャリアはＣＩＣを示すために使用される。制約フィールド４１６は、現在のエージェントのための任意の既知の制約の定義を含んでいる。好ましくは、各エージェントには、少なくとも１つの制約が定義されている。以下のテーブル２は、制約の例を示す。もちろん、他の制約が考慮される場合もあり得る。
Figure 0004536999
ＳＩＰエージェントグループ４３２のデータオブジェクトも、ＳＲ（それは１つ以上のＳＩＰエージェント４０２のコレクションを定義する）の内に設けられている。又、ＳＩＰエージェントグループ４３２のデータオブジェクトは、グループ名４３１および記述４３３によって識別されるＳＩＰエージェントの使用のストラテジーを、グループ化し特定する手段を示す。通信リクエストをルーティングさせる場合、ＳＩＰエージェントグループ４３２のデータオブジェクト内にあるストラテジーフィールド（ＳＴＲＡＴＥＧＹ）４３４は、ＳＩＰエージェント４０２の選択の方法を示す。ＳＩＰエージェントグループに複数のメンバがある場合、ストラテジーフィールドは適用可能である。以下に示されるテーブル３は、ルーティング先のＳＩＰエージェントを選ぶためのストラテジーの例を示す。
Figure 0004536999
ＳＩＰエージェントグループ４３２のデータオブジェクトに戻って、エージェントフィールド４３６の数は、ＳＩＰエージェントグループのメンバの数を示す。必須ではないが、最小のフィールド値は好ましくは１である。最小のフィールド値が零（０）である場合、グループは、空で無意味であると考えられる。エージェントタイプフィールド４３８ａ、４３８ｂは、そのエージェントがＳＩＰエージェントあるいはＳＩＰエージェントグループのいずれであるかを指定する。エージェントタイプフィールドの可能な値は、グループまたはエージェントであることもある。ＳＩＰエージェントグループ４３２は、そのエージェントリスト内の別のエージェントグループを含むことができる。このグループのネスティングは、スケーラブルな配置を可能とする。そこでは、ＳＩＰエージェントがクラスタに分けることができ、又、クラスタは再度クラスタに分けることができる。以下同様である。ＳＩＰエージェントフィールド４３９ａ、４３９ｂは、参照線３１１で示されているように、別のＳＩＰエージェントグループあるいは実際のＳＩＰエージェントコンフィギュレーションへのポインターを示す。コンフィギュレーションの行われたＳＩＰエージェントへのアクセスする為のこの方法例は、柔軟なコンフィギュレーションを可能とする。一つのＳＩＰエージェントは、いくつかのＳＩＰエージェントグループの中に含まれことがあり、そして、このＳＩＰエージェントに変更（例えば、そのドメインアドレス４０４の変更）があれば、すべてのグループの参照は同時に更新される。このメカニズムは、省メモリで、重複が回避されるものである。
ローカルポリシーデータオブジェクト４６２は、現在のＳＲによって使用されるポリシーについて記述する。ポリシーは管理ステーション１１２、１１４を使って、追加、削除される。作成者フィールド４６４は、アドミニストレータの名前を含むか、そうでなければユーザーＩＤ３３６として参照される。アドミニストレータはシステムから削除され得るが、ポリシーのインスタンスは使用され続けるので、作成者フィールド４６４は、ポインターや参照ではない。追加日フィールド４６６は、ポリシーがＳＲに加えられた実際の日付を記述する。有効日付／時間フィールド４６８は、ピアと共有されるポリシーが有効となる正確な日付および時間を含んでいる。これは、現在有効でないポリシーの生成を可能とする。無効日付／時間フィールド４７２は、ネットワークからポリシーを取り下げたり削除する正確な日付および時間を示す。
発信アドレスフィールド４７４は、一様で一般的なリソース識別子（ＵＲＩ）のような、発信アドレスの一部を記述する。これは、ＴＲＩＰの場合、電話番号の一部である。その発信アドレス４７４は、任意の有効なネットワークアドレスでもよい。単なる電話番号でないポリシーを導入し、その実例を示すことによって、以下に記述されるように、本発明はＴＲＩＰの現在のバージョンに関する本質的な改良を行う。
発信アドレス４７４は、オプションの「アップデート」メッセージに関連した属性である。発信アドレス属性が、「アップデート」メッセージに含まれない場合、ポリシーは「任意の発信（ａｎｙ ａｒｒｅｎｇｍｅｎｔ）」に利用される。しかし、発信アドレス属性が存在する場合、ポリシーやルートは、上に記述された部分的な一致が完全である時のみ、通信に用いられる。アドレス属性は、アドレスファミリーフィールド、アプリケーションプロトコルフィールド、長さフィールド、発信アドレスフィールドから構成される。アドレスファミリーフィールドは、発信アドレス属性に、アドレスのタイプを設ける。２つの標準のアドレスファミリーの例は、昔からの普通の電話サービス（ＰＯＴＳ）番号およびルーティング番号である。インターネットスタイルの発信アドレス（つまり起点アドレス）のサポートのために、（ＵＲＩとして参照される）ドメインアドレスの部分アドレス用に、アドレスファミリーコード２５４が追加されている。
好ましくは、部分ドメインアドレスはユーザー名を含んでいない（つまり、username@sr.acmepacket.comの形式ではない）。sr.acmepacket.comは有効なアドレスである。更に、好ましくは、アドレスは１９２．１６８．０．１のような生のＩＰアドレスを含んでいない。
アプリケーションプロトコルフィールドは、発信アドレス４７４を用いるプロトコルを示す。プロトコルの例としては、ＳＩＰやＨ．３２３−Ｈ．２２５．０−Ｑ．９３１がある。しかし、これらに制限されない、 この発明の好適な実施形態では、ＳＩＰベースのシグナリングシステムを取り上げているので、アプリケーションプロトコルはＳＩＰとしてある。長さフィールドは、好ましくはバイト単位で、発信アドレスフィールドの長さを示している。その、発信アドレスフィールドは、アップデートポリシーやルートが、完全な発信アドレス又はその一部として利用するアドレスを示している。
着信アドレスフィールド４７６は、特定のポリシーのための着信側を示す部分的なアドレスである。このアドレスも、電話番号あるいは他の有効なＵＲＩのいずれかでもかまわない。発信アドレス４７４と着信アドレス４７６の組み合わせは、有効なポリシーの選択のために使用される。好ましくは、ワイルドカードのようなエントリを利用する為に、発信アドレス４７４や着信アドレス４７６の空欄が、””、ＮＵＬＬ、”＊”あるいは空のフィールドを示す他の一般的なやり方で指定される。
ポリシーで、起点アドレスと終点アドレスとのマッチングを行う場合、最適と最長である一致が求められる。アドレスが電話番号である場合、数字は左から右に一致させる。又、セッションアドレスとポリシーでのアドレスは左側の数字が一致するべきである。一致した最多の数字を備えた電話アドレスは最長であり、最適である。又、もしアドレスがドメインアドレスであれば、ホスト名の中のワード全体（ドットによって区分された）は右から左に一致させる。
ローカルポリシーデータオブジェクト４６２内にあるＳＩＰエージェントグループフィールド４７８は、現在のポリシーのための次の転送先サーバであるＳＩＰエージェントについて記述する。ＳＩＰエージェントグループデータオブジェクト４３２で指定されるＳＩＰエージェントグループは、１つまたは複数のＳＩＰエージェント４０２を含んでいる。さらに、複数のＳＩＰエージェントがあれば、適切なエージェントを選ぶために上記のストラテジーが使用される。有効／無効フィールド４８２は、ポリシーが使用されるかどうか示す。もし、フィールド４８２が有効の場合、ポリシーは使用されるが、フィールド４８２が無効の場合、ポリシーは使用されない。
ポリシー属性フィールド４８４の数は、発信アドレス４７４、着信アドレス４７６、ＳＩＰエージェントグループ４７８、有効／無効フィールド４８２によって定義されるポリシー属性の数を示す。ポリシー属性は同等のポリシーを比較する為に使用される。各ポリシー属性４８６ａ、４８６ｂ（すなわち、第１のポリシー属性４８６ａからｎ番目のポリシー属性４８６ｂ）は、これらの同等のポリシーを比較する為に使用される情報を含んでいる。以下に説明するフィールドは第１のポリシー属性４８６ａからｎ番目のポリシー属性４８６ｂの各々の内に設けられている。
キャリアフィールド４８８ａ、４８８ｂは、ポリシーに含まれるべき所望された或いは要求されたキャリアの１つと一致するべきものである。キャリアフィールド（それはオプションである）は、ユーザーによるキャリアの選択に基づくルーティングポリシーを示す。キャリアフィールドは、広告されたパスの一部としてキャリアを指定する手段を提供する。到達可能なルートの生成者は、時間および曜日のパラメタによって利用可能なキャリアを示すことができる。さらに、各ルート生成者は、ルートに相対的なコスト属性を割り当てることができる。それは、低コストルートを選択することを可能とする。又、各ルート生成者は、さらにルートにＱＯＳ属性を割り当てることができる。それは、ルートに最適の品質を選択することを可能とする。単一のキャリア属性に複数のキャリアエントリを加えることができることを理解すべきである。しかし、「アップデート」メッセージにつき１つのキャリア属性だけが許されることが好ましい。追加のキャリアエントリは、前のキャリアエントリへ単に追加される。
各キャリアフィールド４８８ａ、４８８ｂは、以下のキャリア属性に関連していてもよい。即ち、キャリア長さ、キャリア、時刻長さ、時刻、曜日の長さ、曜日、コスト、ＱＯＳ待ち時間／ＱｏＳジッタしてＱＯＳエンコーディングスキームである。キャリア長さ属性は、好ましくはバイトで、キャリアエントリの長さを示す。キャリア属性は、キャリアについて記述するテキストエントリ（英数字）を含んでいる。キャリアの詳細のコンフィギュレーションは、管理ステーションインターフェースを使用して、ＳＲベースで、確立することができる。特に、ＳＲがＣＩＣを生成するかあるいはキャリアに関連した特定のＭＰＬＳを行う必要がある場合に、キャリアデータオブジェクト３０２（図３Ａおよび図３Ｂ）が存在する。
時刻長さ属性４９２ａ、４９２ｂは、時刻属性の長さ（バイト）を含んでいる。時刻属性は２４時間表示時刻をコンマに区分した時間範囲のリストである。そのフォーマットは「００００−２４００」時間範囲を含んでおり、２４００が１日のエントリの終わりである。時間範囲はコンマによって区分され、境界を除いて、オーバーラップはしない。例えば、「００００−０７００，０７００−２４００」は、たとえ第１の範囲の０７００が第２の範囲の０７００とオーバーラップしても、有効なエントリである。しかしながら、一般に、これらの範囲はオーバーラップしない。又、範囲の数に制限はない。
曜日長さ属性４９４ａ、４９４ｂは、曜日属性の長さ（バイト）を含んでいる。曜日属性は、コンマに区分した週日範囲のリストを含んでいる。以下は、各曜日を指定する為に使用される文字の例である。即ち、Ｕは日曜、Ｍは月曜、Ｔは火曜、Ｗは水曜、Ｈは木曜、Ｆは金曜そしてＳは土曜である。曜日属性のエントリは、オーバーラップしない範囲を含んでいる。例えば、Ｕ−Ｓのエントリは、その週（週末を含んで）のすべて含んでいる。Ｍ−Ｆはすべての平日を示す。Ｍ、Ｈ、Ｓは月曜、木曜および土曜を示す。Ｕ−Ｗ、Ｆ−Ｓは、木曜日以外の、その週のすべてを示す。
コスト属性４９６ａ、４９６ｂは、好ましくは、３２ビットの整数値をコスト値として含んでいる。この値は実際の通貨値を反映する為に、システム全体で有効な除数を利用してもよい。ルートを広告する目的で、１つのユニバーサルな通貨を用いるが、小数点は使わない。ルートの生成者は任意のコストでルートを示すことができる、そこでは、より低いコストが、より望ましいルートである。ＱＯＳ属性４９８ａ、４９８ｂは、２つの部分、すなわち相対的なＱＯＳインジケータ、利用可能な圧縮のインジケータを含んでいる。
ＱＯＳ待ち時間／ＱｏＳジッタ４９８ａ、４９８ｂは、このルートが広告される時の、利用可能な品質のレベルを含んでいる。このフィールドに対する値は、次のグループから選ばれる。即ち、１−最高の高品質（ＳＨＱ）（ジッタがほぼ０で１００ミリセカンドの以下の待ち時間）、２−高品質（ＨＱ）（ジッタが小さく、２００ミリセカンドの以下の待ち時間）、３−通常品質（ＮＱ）（時々ジッタ有り、３００ミリセカンドの以下の待ち時間）、４−低品質（ＬＱ）（頻繁なジッタ、５００ミリセカンドの以下の待ち時間）、そして５−非常に低品質（ＶＬＱ）（頻繁なジッタ、１０００ミリセカンドの以下の待ち時間）のグループである。
ＱＯＳエンコーディングスキーム属性は、広告されたルート上の通信の推奨されたエンコーディングスキームを含む。好ましくは、広告されたポリシーより圧縮の低いレベルを使用するリクエストはルーティングさせない。例として、Ｇ．７１１が要求されるが、ルートはＧ．７２９のみをサポートする場合、セッションリクエストは別のルートを探す必要がある。
時刻４９２ａ、４９２ｂフィールドおよび曜日フィールド４９４ａ、４９４ｂ、キャリア／コストペアが有効か利用可能かどうかを確かめる為に使用される。時刻フィールド４９２ａ、４９２ｂは、好ましくは、２４時間表示時刻をコンマに区分した時間範囲のリストを備えたテキスト文字列を含んでいる。一日の終わりは２４００で示される。それは有効な時間でないが、一日の最後の秒を示す。例として、時刻エントリは「００００−０７００」、または「１７００−２４００」ということもある。曜日フィールド４９４ａ、４９４ｂは、週日のコンマに区分された範囲のリストを含んでいる。好ましくは、このフィールドでは、Ｕは日曜日を指定する。また、Ｈは木曜日を指定する。例として、週エントリの有効な日は、Ｕ（日曜を示す）、Ｔ−Ｈ（火曜日から木曜日を示す）、Ｓ（土曜を示す）等である。
コストフィールド４９６ａ、４９６ｂは、様々なポリシーの相対的なコストあるいは選択に関する表示を含む１０進の整数値である。サービスの質（ＱｏＳ）フィールド４９８ａ、４９８ｂは、ポリシー属性によって期待された最小のＱＯＳについて記述された情報を含んでいる。以下に示されるテーブル４は、ＱＯＳフィールド４９８ａ、４９８ｂ含まれている表示タイプの例を示す。
Figure 0004536999
上記のテーブルは、すべてを網羅するものではなく、多くのタイプの品質が考慮可能である。ＳＩＰ「招待」メッセージが受け取られた時、以下に更に定義する「招待」メッセージのＳＤＰ部分が、メディアタイプおよび帯域幅インジケータの両方を示す。境界内のメディアタイプおよび帯域幅インジケータを調査し、特定のポリシーによって提示されたＱＯＳフィールド４９８ａおよび４９８ｂと比較することによって、ポリシーを現在のものに加えるべきか、低く不十分な品質により拒絶されるべきかどうかが決められる。最後に、有効／無効フィールド４９９ａ、４９９ｂは、特定のポリシー属性が有効又は無効になるようにセットする為に使用することができる。
成功したＳＩＰ招待は、２つのリクエスト、即ち「ＡＣＫ」が続く「招待」からなっている。その「招待」リクエストは、特定の会議に参加してくれるか、あるいは二者の会話を確立してくれるように着信側に依頼する。着信側が呼び出しに対して、参加することに合意した後、着信側は「ＡＣＫ」リクエストを送ることにより、それがそのレスポンスを受け取ったことを確認する。着信側が呼び出しに対して、参加したくなければ、「ＡＣＫ」の代わりに「ＢＹＥ」リクエストを送る。「招待」リクエストは、典型的には例えばセッション記述を含んでいる。それは、例えば、ＳＤＰフォーマットで書かれて、セッションに加わる為に十分な情報を、着信側に提供する。マルチキャストセッションのために、セッション記述では、そのセッションに配布可能なメディアタイプおよびフォーマットが列挙される。ユニキャストセッションのために、セッション記述では、着信側がメディアデータを送るのに利用したいメディアタイプおよびフォーマットが列挙される。いずれの場合も、着信側が呼び出しを受理したい場合、使用したいメディアのリストを含む同様の記述を返すことにより、「招待」に答える。マルチキャストセッションのために、着信側の記述で示されたメディアを受け取ることができないか、ユニキャストによってデータを受け取りたい場合には、着信側は単にセッション記述を返すべきである。
セッションルータ上に格納されたポリシー（図３Ａ）について記述したが、図４はセッションルータ装置の構造を示すブロックダイヤグラムである。セッションルータ１２２、１２４、１２６、１２８（図１）は、ＴＣＰ／ＩＰデータや他のデータの送受信の可能な、少なくとも１つのイーサネットインターフェース６０２あるいは他のパケットインターフェースを備えているコンピュータである。好ましくは、コンピュータは２つ以上のイーサネットインターフェースを含んでいる。コンピュータの１つの例は、ＩＵラックマウントユニット内に設けられたペンティアムＩＩＩベースのコンピュータシステムである。ニューヨーク州アーモンクのインターナショナルビジネスマシーンズコーポレーション（ＩＢＭ）、テキサス州ヒューストンのコンパックコンピュータコーポレーション、あるいは、ターンキー１Ｕコンピュータシステムの他のメーカーのＩＵユニットも、セッションルータ（ＳＲ）として利用するのに十分である。別の実施形態では、ＳＲは、メディア通信のために、追加の専用イーサネットサブシステムを持つことができるであろう。更に別の実施形態では、ＳＲは、例えばＶＸＷＯＲＫＳのような組み込みオペレーティングシステムを使用する高速２プロセッサからなる。
ここでは、ＳＲ１２２（図１）は、任意の関連データ、コンピュータオペレーティングシステム或いはＳＲソフトウェアの格納のために、ローカルの記憶装置６０４を含んでいる。ＳＲ１２２（図１）はさらにプロセッサ６０６を含んでいる。このプロセッサ６０６は、ローカルメモリ６０８に設けられているソフトウェア６０７を実行する。フラッシュメモリ装置６１２はコンフィギュレーションデータを格納する為に設けられ、バックアップや機能の回復に利用される。ハードディスクコントローラー６１５は、ローカルの記憶装置６０４およびフラッシュメモリ装置６１２と通信する為に、ＳＲ１２２（図１）に設けられている。フロッピーディスクドライブ６１４およびフロッピーディスクコントローラー６１６はＳＲ１２２（図１）の内にメンテナンス目的に設けられる。ビデオアダプター６１８もＳＲ１２２（図１）の内にローカルのメンテナンス目的に設けられる。ＳＲ１２２（図１）の内に他の構造の要素が提供され得ることは理解すべきである。そのような要素は、例えば、当業者に知られた計算上の要素、２次キャッシュ、数値のコプロセッサあるいはネットワークプロセサ等である。好ましくは、ローカルメモリ６０８、イーサネットインターフェース６０２、ハードディスクコントローラー６１２、フロッピーディスクコントローラー６１６、ビデオアダプター６１８およびプロセッサ６０６は、ＰＣＩバス６１３経由で、ＳＲ１２２（図１）の内で通信を行う。パワークイックプロセッサを使用した時のＰＯＷＥＲ ＰＣバス等、別のバス構造を使用することもできる。
図５は、ＳＲのローカルメモリ６０８（図４）内に常駐するソフトウェア６０７、又はプロトコルを示すブロックダイヤグラムである。オペレーティングシステム６３２は、ＳＲの機能を制御する為に設けられている。任意のオペレーティングシステムを、ＳＲに利用することが可能である。メモリ６０８（図４）内のオペレーティングシステムとしてＬＩＮＵＸが好ましいが、ＬＹＮＸ、ＰＳＯＳ、ＳＯＬＡＲＩＳあるいはＶＸＷＯＲＫＳのようなリアルタイム組み込みオペレーティングシステム等の他のオペレーティングシステムを利用可能である。好ましくは、メモリ６０８（図４）に設けられているソフトウェアプロトコルは、ＩＰ６３５を利用する。
ＴＲＩＰ６３４の（ＴＲＩＰロケーションサーバによって実行される）処理は、ソケットベースの送信コントロールプロトコル（ＴＣＰ）６３６上で、ＳＲによって実行され得る。（ＳＩＰプロキシサーバによって実行される）ＳＩＰ６３８処理、ライトウェイトディレクトリーアクセスプロトコル（ＬＤＡＰ）６４２およびエクステンシブルマークアップランゲージ（ＸＭＬ）６４４は、好ましくは、ユーザー／ユニバーサルデータグラムプロトコル（ＵＤＰ）６４６を利用する。ＵＤＰはコネクションレスである。独自仕様のポリシーベースのルーティングアルゴリズムも利用可能である。それらは、ＴＲＩＰ６３４、ＳＩＰ６３８およびＬＤＡＰ６４２に基づき、同様に統計的技法を用いることが可能である。好ましくは、ポリシーを管理する為に、管理ステーション１１２、１１４（図１）はＵＤＰ６４６のデータグラムの中でＸＭＬ６４４を使用して、ＳＲ１２２（図１）と通信する。
図６は、図４に示すソフトウェア６０７によって定義される、稼働開始の際にセッションルータによって実行される動作を示すフローチャートである。ここに記述されたすべてのフローチャートに関して、各ブロックは所定の論理的な機能を実装する為の１つ以上の実行可能な命令を含む、モジュール、セグメントあるいはコード部分を表す。いくつかのインプリメンテーションでは、ブロックに書かれた機能は、これとは異なる順序となり得ることを理解すべきである。例えば、連続して示された２つのブロックが実質的に同時に実行されることもある。あるいは、ブロックは、その機能によっては、逆の順に実行されることもあり得る。
ブロック６７２によって示されているように、ＳＲは、電源を入れた時に、オペレーティングシステム６３２（図５）を立ち上げる。好ましくは、オペレーティングシステムはＬＩＮＵＸであるが、ＬＹＮＸ、ＰＳＯＳ、ＳＯＬＡＲＩＳあるいはＶＸＷＯＲＫＳのような他のオペレーティングシステムも利用可能である。その後、ブロック６７４によって示されているように、ＳＲ稼働開始スクリプトは、オペレーティングシステムのブートアッププロセスの一部として実行される。診断モード（オペレーターが介在するまで処理を進めないモード）でＳＲを立ち上げることを可能にする為に、診断モードに対するテスト（ブロック６７６）が完了される。ＳＲが診断のモードでスタートしない場合、特定のデーモンやプロセスが実行するように設定されているかどうかを、系統的にチェックされる（ブロック６７８、６８２、６８４）。特に、システムロギングメカニズム（ブロック６８６）を開始した後に、ＳＲが、ＴＲＩＰ（ブロック６７８）、ＳＩＰ（ブロック６８２）およびＬＤＡＰ（ブロック６８４）を実行するかどうかを決定される。その後、ＳＲがデーモンを実行した時（ブロック６８８、６９２、６９４）、それぞれのデーモンがサービスを開始する。
稼働開始スクリプトがＴＲＩＰロケーションサーバ（ＬＳ）６３４の動作を開始する場合（ブロック６８８）、ＴＲＩＰ ＬＳ６３４はＳＲのためのルーティング情報を処理し出力する。ＴＲＩＰ ＬＳ ６３４の最初の処理の１つは、格納されたコンフィギュレーションから隣接したルータレコード３４２（図３Ａ）を読むことである。基本的に、ＴＲＩＰ ＬＳ ６３４は、他のＴＲＩＰ ＬＳから受け取ったルーティング情報に基づいて、エンドポイント照合リクエストに答える。夫々の隣接したルータレコード３４２（図３Ａ）については、それらが内部ルータであるか外部ルータかを確かめる検査がある。内部であれば、ＩＴＡＤ識別子３４８（図３Ａ）が、このＳＲのＩＴＡＤ識別子３６８と等しいことを示す。２つのＩＴＡＤ識別子が等しくない場合、隣接したルータは、外部のものとして分類される。
その後、ＴＲＩＰ ＬＳ ６３４は特定のＴＲＩＢを初期化し始める。ＴＲＩＢの各々は、頻繁に修正される一時データを含んでいる。動的な特性を持ったこれらのデータベースに格納するメカニズムは、メモリ内の２重にリンクしたリスト、ＩＳＡＭ（Indexed Sequential Access Method）によるデータベース、あるいは他の、高速アクセスを提供すると共に各挿入および削除に対応するメカニズムである。発明の好ましい実施形態によれば、標準のテンプレートライブラリーリストが使用される。ＴＲＩＢの初期化は、ライブラリーリストを使用する場合、空のリストの初期化を含んでいる。初期化が完了すると、１つのＴＲＩＢが外部の隣接したルータの夫々のために存在し、１つのＴＲＩＢが内部で隣接したルータの夫々ために存在し、１つの出力ＴＲＩＢが存在し、また、１つのローカルＴＲＩＢが存在する。それらのすべては空であり、新たなエントリの受け入れ準備ができている。
その後、一連の格納された（ローカル）ポリシーデータベースは個々のポリシーを保持しており、ポリシーデータベースは開かれる。このデータベースは、ＳＱＬ（Structured Query Language）によるデータベースサーバあるいはＩＳＡＭデータベースを含む固定記憶の任意の形式で構築される。そして、カード型（フラットファイル）、あるいはＸＭＬデータとして、それらを格納することができる。好ましい実施形態によれば、ＳＱＬサーバが使用される。一旦、クライアント（この場合、ＴＲＩＰ ＬＳ ６３４）が、ＳＱＬクライアントインターフェースを介して、ＳＱＬデータベースを開けば、ローカルポリシー４６２（図３Ａ）が一つずつ読まれる。まず、ポリシーがチェックされ、それらが現在アクティブかどうか確かめられる。このチェックは、ローカルポリシーデータオブジェクト４６２（図３Ａ）にある有効日付／時間フィールド４６８（図３Ａ）と現在の日付／時間を比較することで行われる。ポリシーでの有効日付／時間フィールド４６８（図３Ａ）が、現在の日付／時間未満である場合、ポリシーはアクティブであるとわかる。そうでなければ、ポリシーは将来の活性化の為に保留される。ポリシーがアクティブな場合、そのポリシーは処理に回される。ポリシーが将来の活性化の為に保留されている場合、タイマーが特定の日付／時間にポリシーを活性化する為にセットされる。一旦タイマーがセットされれば、プロセスは処理の残りをスキップし、直接、次のポリシーに進む。タイマーの時間がくると、ポリシーはその将来の時間に処理される。
好ましい実施形態で使用されルータイマーは、典型的なタイムアウトキューメカニズムである。データオブジェクトのアドレスは、一体になったタイムアウトリストに加えることができる。また、将来、タイマーの時間がくると、データオブジェクトが参照される。有効日付／時間４６８（図３Ａ）の値がゼロ（０）であれば、ポリシーが直ちにアクティブであることを示す。ローカルポリシーデータオブジェクト４６２の中の無効日付／時間フィールド４７２がゼロ（０）以外の場合、ポリシーの非活性化が、キューに入れられる。ポリシーが非活性化される場合、ＳＱＬデータベースによって管理され、格納されたローカルポリシーからそのポリシーが取り除かれ、有効になりえないポリシーが処理されないようにしている。無効日付／時間フィールド４７２（図３Ａ）値がゼロ（０）でなく、かつ無効日付／時間フィールド４７２（図３Ａ）の値が現在の日付／時間未満である場合、そのレコードは削除され、このレコードのための処理はスキップされる。無効日付／時間フィールド４７２が現在の日付／時間より大きな場合、タイマーはセットされ、後にこのポリシーを自動的に非活性化する。一旦、ポリシーの為にタイマーがセットされ、このポリシーが現在アクティブである場合、ポリシーはローカルＴＲＩＢに加えられる。その後、ポリシーは、それらが外部と共有されるかどうか決める為に、コンフィギュレーションと照合される。よりよくこのチェックを理解する為に、ＩＴＡＤベースのポリシーの詳細な記述を以下に設ける。
上に記述されているように、ＴＲＩＢは、ＴＲＩＰ ＬＳによって使用され、生のポリシー情報に対してどのような変更をおこなったかを、決定プロセスによって「思い出す」。下記は、発明の好ましい実施形態による、ＴＲＩＢおよびＴＲＩＰ決定プロセスの実行に関する情報を示す。好ましくは、各ＴＲＩＢは、下記の要素のすべて又は一部を含んでいる。
Figure 0004536999
ＴＲＩＢ ＴＲＩＰ ＩＤリストリンク、同じ受信ポリシーリンク、集成クラス、活性期間開始および活性期間終了の各エントリは、特定の実行に依存することもあるし、依存しないこともある。
すべてのポリシーが、外部と共有されるとは限らない。ポリシーが外部と共有されることになっていても、ポリシースクリーンがチェックされ、ポリシーが外部と共有されることになっているか、外部のＩＴＡＤから受理されたかどうかに関して確認される。図７は、発明の好ましい実施形態によるポリシースクリーンを示すブロックダイヤグラムである。これらのポリシースクリーンもポリシー情報ベース（ＰＩＢ）と呼ばれる。これらのデータオブジェクトは、図３Ａおよび図３Ｂの中でＳＲデータが用意されるのと同じ方法で用意される。しかしながら、これらのデータオブジェクトは、発信側か着信側のいずれかの境界外のＩＴＡＤのための、境界内又は境界外のデータポリシーをスクリーンする為に使用される。図３Ａおよび図３Ｂに示されているような、ＳＲのコンフィギュレーションと同じ方法で、ＳＲの各クラスタのためにデータテーブルのコンフィギュレーションが行われる。
好ましくは、各ＩＴＡＤは、ＩＡＮＡ（Internet Assigned Numbers Authority）によって割り当てられる３２ビットの整数値によって定義される。各ＳＲ（クラスタ）は、境界外のＩＴＡＤから送受信され、広告されたルートの集合を管理する為に使用されるポリシースクリーンのコンフィギュレーションの行われたセットを備えている。図７を参照すれば、隣接ＩＴＡＤ７０２のデータオブジェクトは、隣接ルータ３４２（図３Ａ）のデータオブジェクトに含まれているＩＴＡＤ識別子３４８（図３Ａ）に類似した、外来ＩＴＡＤ識別子７０４を含んでいる。コンフィギュレーションの行われた隣接ＩＴＡＤ７０２のデータオブジェクトがない場合、ルートはＩＴＡＤの外部で広告されず、また、境界外のＩＴＡＤからの受信されたルートは使用されない。必要があれば、これはルーティングアルゴリズム上の高いセキュリティを提供する。個々の隣接したＩＴＡＤ７０２コンフィギュレーションについては、そのＩＴＡＤについて記述する名前フィールド７０６および記述フィールド７０８がある。これらのフィールドは記述的な目的だけのために使用され、アルゴリズムの結果に影響しない。
個々の隣接したＩＴＡＤ７０２は、ポインター７１２によって参照される境界内のポリシースクリーン７１４のデータオブジェクトの配列を備えている。この配列は、作成者フィールド７２４、追加日フィールド７２６、活性化日付／時間フィールド７２８、非活性化日付／時間フィールド７３２、許可／拒絶フィールド７３６、部分的着信アドレスフィールド７３６、そしてポリシー属性数フィールド７４２を含む、ポリシーと同じ属性のうちのいくつかを備えている。「アップデート」メッセージが境界外のＴＲＩＰサーバから受け取られると、着信アドレス７３６の一部と比較された到達可能なルートアドレス上の最長の一致は、次の状況のうちの１つに当てはまる。即ち、部分的な一致も見つけられないか、部分的な一致は見つけられたが許可／拒絶フィールド７３６は拒絶となっているか、あるいは、部分的な一致は見つけら許可／拒絶フィールド７３６は許可となっている、というものの１つに当てはまる。
この第１と第２の状況で、「アップデート」メッセージは廃棄され、変更はローカルのルーティングさせるデータベース（つまりＴＲＩＢ）に対して行なわれない。第３の状況では、広告されたルートは受理され、ＴＲＩＢデータベースに加えらる。部分的な一致が生じる場合、キャリア７５４、７６８、時刻７５６、７７２、曜日７５８、７７４、コスト７６２、７７６、およびＱＯＳ７６４、７７８を含む、すべてのデフォルト（ポリシー）属性７５２ａ、７５２ｂのセッティングは、ポリシー属性７６６、７８２が有効な場合、すべてルートの為のデフォルトとして扱われる。加えて、デフォルトの発信アドレスフィールド７３８は、デフォルト発信アドレス（例えばＵＲＩ）を割り当てる為に使用される。これは、すべてのルーティングの決定が完全に同等のルーティングデータを持ち得ることを保証することにより、機能強化なソースベースのルーティングを可能とする。この種類のルーティングポリシーの例の動作が、以下に示される。
発明の好ましい実施形態では、可能な２種類の部分的な一致が示される。部分的な一致の第１の種類では、ＴＲＩＰピアサーバから送られて受信した「アップデート」メッセージの中の広告された到達可能なルートアドレスは、部分的な着信アドレス７３６より長い。部分的な一致の第２の種類では、ＴＲＩＰピアサーバから送られて受信した「アップデート」メッセージの中の広告された到達可能なルートアドレスは、部分的な着信アドレス７３６より短い。部分的な一致の第２の種類によれば、ポリシーが境界外のＩＴＡＤから受け取ったポリシーより狭い（限定的な）状況が生じる。この場合、「アップデート」メッセージ中のより広い値の代わりに、（より狭い）部分アドレス７３６をルートポリシーとして用いることで、ポリシーがより狭くなる。
隣接したルータ３４２（図３Ａ）が、境界外のＩＴＡＤ識別子３４８（図３Ａ）（境界外のＩＴＡＤは、ＳＲのベースコンフィギュレーション３６２（図３Ｂ）の中で、ＩＴＡＤ識別子３６８（図３Ｂ）と等しくないＩＴＡＤである）と共に、ＳＲに設けられている場合、その境界外のＩＴＡＤにエクスポートされる広告を制御する為の特別な規則が存在する。これらの規則は、図７の境界外ポリシースクリーン８０２のデータオブジェクト内に定義されている。図３Ａおよび図３Ｂの中のＳＲデータと同じ方法で、このデータは、このＳＲの中で用意される。隣接ＩＴＡＤ７０２のデータオブジェクトは、ポインター８０４によって指されるＩＴＡＤ識別子７０４毎に、境界外のポリシースクリーン８０２のレコードの配列を備えている。この配列は、作成者フィールド８０６、追加日フィールド８０８、活性化日付／時間フィールド８１２、非活性化日付／時間フィールド８１４を含むポリシーと同じ属性のうちのいくつかを備えている。許可／拒絶パラメタ８１６は、ポリシーがピアに広告されることになっているかどうかを制御する為に使用される。
境界外のポリシースクリーン８０２を介して広告されるＴＲＩＢポリシーとの関係においても、３つの可能性が生じる。第１の可能性は、ＴＲＩＢ内の到達可能なルートと、スクリーンの着信アドレス８１８との、部分的な一致が存在しないというものである。第２の可能性は、ＴＲＩＢ内の到達可能なルートと、スクリーンの着信アドレス８１８との、最適（部分的）な一致が存在し、許可／拒絶フィールド８１６が拒絶にセットされているというものである。第３の可能性は、ＴＲＩＢ内の到達可能なルートと、スクリーンの着信アドレス８１８との、最適（部分的）な一致が存在し、許可／拒絶フィールド８１６が許可にセットされているというものである。ポリシー属性フィールド８１７の数も、境界内のポリシースクリーン７２２に含まれるポリシー属性フィールド７４２の数と同様の目的のために設けられている。
第１と第２のケースでは、ＴＲＩＢポリシーと関係する広告は、境界外のＩＴＡＤに対して行われない。しかしながら、第３のケースでは、２つの可能性がある。第１の可能性は、着信アドレスが、部分的な着信アドレス８１８より長い又は同じというものである。この状況で、境界外のＩＴＡＤへ広告されたポリシーは、集成された到達可能なルートを含んでいる。第２の可能性は、着信アドレスが、部分的なアドレス８１８より短いというものである。この状況で、境界外のＩＴＡＤへの広告されたポリシーは、より狭い（つまり、より限定的な）部分的な着信アドレス８１８を含んでいる。
境界外のポリシースクリーンのポリシーの（ＰＯＴＳあるいはルーティング番号アドレスのための）最適の一致というものは、ポリシーの到達可能なルート属性アドレスと境界外のポリシースクリーン８０２の属性とが、左からスタートして、最も連続して一致する文字を共有するようなものであることを理解すべきである。境界外のポリシースクリーン８０２の属性８１９、８２１は、キャリアフィールド８２２、８３６、時刻フィールド８２４、８３８、曜日フィールド８２６、８４２、コスト基準フィールド８２８、８４４、およびＱＯＳ基準フィールド８３２、８４６によって定義され、ルートの属性とのマッチングも行われている。ルートの各キャリアについては、境界外のスクリーン属性（つまりキャリア、時刻、曜日、コスト基準およびＱＯＳ基準）との一致があるべきである。一致が正確でない場合、境界外のスクリーンのより狭い（つまり、より限定的な）属性が適用される。例えば、与えられたキャリア用に、ルートとして、Ｍ−Ｆ、００００−２４００が定義され、境界外のスクリーンはＴ−Ｆ、０７００−１７００を定義するかもしれない。この場合、境界外のスクリーンによって定義された、より狭い属性が使用されるルートである。
属性が一致し、一致した属性の組み合わせについて、有効／無効フィールド８３４、８４８が有効にセットされており、外部のＩＴＡＤに広告されたポリシー属性が境界外のスクリーン中のものの一部であることが保証されるならば、そのルートは利用可能である。さらに、上記の通り、部分的な着信アドレス８１８自体は、外部に広告された到達可能なルート属性アドレスに影響を及ぼすこともある。この機能性は、境界外のスクリーンで特定される属性に基づいてルート広告を制御する、いくつかの発明性のあるオプションを提供する。
個々の隣接した内部ルータについて、ＴＣＰ／ＩＰソケットが開かれ、また、隣接したルータは「オープン」メッセージを使用して、ネゴシエーションを開始する。固定サイズのＴＲＩＰヘッダーに加えて、「オープン」メッセージは次のフィールドを含んでいる。即ち、バージョン、ホールド時間、自身のＩＴＡＤ、ＴＲＩＰ識別子、オプションパラメタの長さ、またその他のオプションパラメタである。これらのフィールドの詳細な記述は、Ｒｏｓｅｎｂｅｒｇらによって、「ＩＰの上のテレフォニールーティング（ＴＲＩＰ）」の中で提供されており、そのセクション４．２は、ドラフト番号draft-ietf-iptel-trip-04.txtと２０００年１１月の日付を備え、インターネットドラフトの１つであり、その内容をこの出願の一部とする。
この時点で、有効なコミュニケーションソケットが、同じＩＴＡＤの内の、すべての利用可能なローカルピア、あるいはセッションルータの間に存在する。有効な接続がなされた後、ポリシーの交換が行われる。そして、ポリシーは「アップデート」メッセージを使用して交換される。ＴＲＩＰヘッダーに加えて、「アップデート」メッセージは、ルーティング属性のリストを含んでいる。これらの属性は下記のものを含む。即ち、取り下げられたルート、到達可能なルート、次の転送先サーバ（ＳＩＰプロキシアドレス）、広告パス、ルートパス、要素の集成、ローカルの優先度、コミュニティー、多重出口弁別子、ＩＴＡＤトポロジーおよび認証である。発明の好ましい実施形態によれば、次の属性も、ルーティング属性の「アップデート」メッセージリストに含まれている。即ち、発信アドレス（ＵＲＩ）、キャリア、時刻、曜日、コスト、およびＱＯＳである。
ポリシーコミュニケーションの主要な手段として、発信アドレス（ＵＲＩ）、キャリア、時刻、曜日、コスト、およびＱＯＳに加えて、取り下げられたルート、到達可能なルートおよび次の転送先サーバ（ＳＩＰプロキシアドレス）も利用される。どのようにＴＲＩＰ「アップデート」メッセージを処理することができるか、また、それがどのようにローカルポリシー４６２（図３Ａ）を生成することができるか、が以下に明確にされる。
広告パス、ルートパス、要素の集成、ＩＴＡＤトポロジーおよび認証属性は、すべて「アップデート」メッセージの受理か拒絶を管理する為に使用される属性である。広告パスおよびルートパス属性は二重の広告および循環的な参照を検知する為に使用される。これはＢＧＰ−４の二重検知方法に似ている。要素集成の属性は、発信側によって受け取られた他の別々の広告から広告が再構成されたことを外部のＩＴＡＤに示す。発明の好ましい実施形態によれば、集成は、要素集成の属性によって提供される方法では実行されない。しかしながら、その属性が受け取られる場合、それは次のルータに渡される。「アップデート」メッセージに含まれたＩＴＡＤトポロジー属性は、同じＩＴＡＤの内のローカルサーバへの情報を注流させる為に使用される。送信側は認証を実行し、受信側は認証を理解する。そして、広告に対して変更されることなく受理されることが保証される。これらのパラメタのどれも、実際の格納されたポリシーには影響しない。
発明の好ましい実施形態によれば、ローカルの優先度、コミュニティーおよび多重出口弁別子属性は、ポリシー管理のいくつかの方法を示すためにＴＲＩＰによって使用されるが、現在のネットワーク１００（図１）によって計画されるルーティングの種類には適していない。さらに、これらのパラメタは、ＩＴＡＤ境界を超えて一般に共有されない。
ルーティングさせる属性の詳細な記述は、Ｒｏｓｅｎｂｅｒｇらによって、「ＩＰ（ＴＲＩＰ）の上のテレフォニールーティング」の中で提供されており、そのセクション４．３は、ドラフト番号draft-ietf-iptel-trip-04.txtと２０００年１１月の日付を備え、インターネットドラフトの１つであり、その内容をこの出願の一部とする。交換されるＴＲＩＢの例が、以下に示される。上に記述された、現在のＩＴＡＤベースのスクリーンメカニズムは、ポリシーが共有されることになっているかどうかを決める為に使用される。ＴＣＰ／ＩＰによる有効な通信セッションを得て、「アップデート」メッセージによってポリシーを交換する上記のプロセスは、隣接した外部ルータで繰り返される。
そして、ＴＲＩＢはすべて初期化され実装される。その後、ＴＲＩＰサーバは受信ルートを処理し、ＳＩＰプロキシサーバの、セッションリクエストをルーティングに使用するローカルＴＲＩＢを計算する。さらに、外部ＴＲＩＢが、個々の境界外のＩＴＡＤピアのために作成される。
図８は、ＴＲＩＰ決定プロセスによって定義されたロジックを示すブロックダイヤグラムである。図８によって示されているように、楕円枠８５２、８５４、８５６、８５８、８６２および８６４は、様々なＴＲＩＢを表わす。また、ブロック８７２、８７４、８７６および８７８は、ＴＲＩＰによって定義された決定プロセスの様々な段階を表わす。楕円枠８５２は、ローカルポリシーであり、ローカルのＳＲで定義されたルートのセットを表わす。楕円枠８５６は、Ａｄｊ−ＴＲＩＢ−Ｉｎ（外部）であり、外部のＴＲＩＰピアから受け取ったルート広告のセットを表わす。好ましくは、各外部ピアに１つのＡｄｊ−ＴＲＩＢ−Ｉｎ（外部）８５６がある。
楕円枠８５８は、Ａｄｊ−ＴＲＩＢ−Ｉｎ（内部）であり、内部ＴＲＩＰピアから受信したルート広告のセットを表わす。好ましくは、ＩＴＡＤ（ＴＲＩＰ注流メカニズムによって占められた）の内に、ＴＲＩＰの各インスタンスについて、１つのＡｄｊ−ＴＲＩＢ−Ｉｎ（内部）８５８がある。これらの内部ＴＲＩＢの内容は、すべての内部ピアに広告される。これらは、図８においてＡｄｊ−ＴＲＩＢ−Ｉｎ（内部）８５８から出る矢印「内部ピア」によって示されている。楕円枠８５４は、Ｅｘｔ−ＴＲＩＢであり、内部ピアに広告される境界外のＩＴＡＤから受け取った、ローカルポリシー８５２からのルートのセットを示す。楕円枠８６２は、Ｌｏｃ−ＴＲＩＢであり、ＳＲの内のルーティング決定を行うために使用されるルートのセットを表わす。楕円枠８６４は、Ａｄｊ−ＴＲＩＢ−Ｏｕｔであり、外部ピアに広告されるルートのセットを表わす。好ましくは、そこに、１つの外部ピアに対して、１つのＡｄｊ−ＴＲＩＢ−Ｏｕｔ８６４が存在する。
ＴＲＩＰは、数値の値としてローカルの優先度を定義し、それはローカルルートへ組み込まれ、内部ピアに渡される。この優先度は、同じ終点へのルートのセット間での選択に利用できる。発明の好ましい実施形態によれば、ＴＲＩＰは、発信アドレス、キャリア、曜日、時刻、コストおよびＱＯＳ含む多くの属性を、ルートへ加えることにより機能強化が行われた。ルート属性へのセッション招待の属性のマッチングが含まれているので、セッション招待へのこれらの属性の適用は、好ましくは、実行時間で行われる。個別のルート（つまり発信アドレス、着信アドレスおよび次の転送先サーバのアドレス）のすべては、（ルートに優先度の値を適用し、優先度の最も高いルートだけを選択する代わりに）、ＴＲＩＢの中で保持される。基本的に、すべてのルートに対する優先度は同じである。
ＴＲＩＰ決定プロセスの第１段階では、優先度の値を決定する為にＳＲに定義されたＰＩＢが使用される。しかしながら、優先度の値を適用する代わりに、境界内のスクリーニングは、境界内のスクリーンデータを使用して実行される。このスクリーンデータは、受理可能な受信ルートを選択し、それらにデフォルト属性を加える為に、境界内のポリシースクリーン７２２（図７）に設けられている。Ａｄｊ−ＴＲＩＢ−Ｉｎ（外部）８５６が変更された時にのみ、第１段階が実行されることに注意されたい。さらに、境界外スクリーニング８０２（図７）は、境界外のスクリーンデータを使用して実行され、このスクリーンデータは境界外のポリシースクリーン８０２（図７）内に設けられている。
そのスクリーニングされた外部ルートのセットは、ローカルポリシースクリーニングに加えて、決定プロセスの第２段階の第１の部分の入力となる。以前のＴＲＩＰ仕様によれば、この段階では、優先度の最も高いルートが選択される。ルートがすべてＳＲ内で等しい優先度を持つので、この段階ではＥｘｔ−ＴＲＩＢ８５４をロードする為に、ローカルポリシーにスクリーニングされた外部ルートが加えられる。この段階では、さらに、ローカルポリシーによって参照されたＳＩＰエージェントが使用されているかどうかが考慮される。ここでは、アクティブでサービス中のＳＩＰエージェントのためのルートだけが含まれている。その後、このルートのセットは、すべての内部ピアに広告される。ローカルポリシー８５２又はＡｄｊ−ＴＲＩＢ−Ｉｎ（外部）８５６が変更された時にのみ、第２段階の第１の部分が実行されることに注意されたい。
Ｅｘｔ−ＴＲＩＢ８５４とＡｄｊ−ＴＲＩＢ−Ｉｎ（内部）８５８は、決定プロセスの第２段階の第２の部分への入力を含んでいる。ＴＲＩＰ仕様によれば、この段階では、優先度の最も高いルートが選択される。ＳＲについては、入力ＴＲＩＢが、Ｌｏｃ−ＴＲＩＢ８６２の出力を作成する為にマージされる。このルートのセットは、セッション招待を送る為に使用される。
外部ピアに広告するルートのセットを生成する為に、決定プロセスの第３の段階が、Ｌｏｃ−ＴＲＩＢ８６２上で動作する。この段階では、各外部ピア（つまりＡｄｊ−ＴＲＩＢ−Ｏｕｔ８６４）に一組のルートを選ぶために、ＰＩＢに定義された境界外のスクリーン８８４が用いられる。この段階はさらにルートの集成を行う。ローカルポリシー８５２のいずれか或いはＡｄｊ−ＴＲＩＢ−Ｉｎ８５６、８５８の１つについて、入力ルートが、追加、変更、撤去されるごとに、決定プロセスの３つの段階が実行される。
システムリソース上の負担となり得る、この決定プロセスの実行が余りに頻繁となることを回避する為に、好ましくは、入力ＴＲＩＢが変更された場合に、ＴＲＩＰ ＬＳは、短いタイマー（例えば数秒のオーダー）をセットする。このタイマーが終了（作動）した時、決定プロセスが実行されルータイマーが終了する前に、別の変更が生じる場合、タイマーはリセットされる。第１の変更が生じる場合、別のタイマー（それは第１のタイマーより長い）がセットされる。このより短いタイマーが終了し、決定プロセスが実行される場合、この第２のタイマーは取り消される。短いタイマーが連続的な変更のために繰り返しリセットされる場合、より長いタイマーは結局終了し、決定プロセスが実行される。より長いタイマーは、適切な時間内に走ることを決定プロセスに強いて、短いタイマーがずっと決定プロセスの実行を遅らせるのを防げる。決定プロセスが実行されている間に、入力ＴＲＩＢを変更することができないように、入力ＴＲＩＢへの変更の処理と決定プロセスの処理は同一スレッドで実行される。
図９Ａおよび図９Ｂは、発明の好ましい実施形態によるＴＲＩＰ「アップデート」メッセージの主なコンポーネントを示すブロックダイヤグラムである。メッセージ９０２はいくつかの属性（９０８、９１２、９１４）を含んでいる。メッセージの全長は、長さフィールド９０４で定義される。また、メッセージタイプはタイプフィールド９０６で定義される。好ましくは、属性の数に制限はないが、最大のメッセージサイズで制限される。各メッセージは、単一のポリシーの一部である一組の属性の通信の為に、設けられている。
メッセージがＴＲＩＰサーバデーモンに入力されると、解析される。好ましくは、Ｃ＋＋ソフトウェアが、メッセージおよびそれらの属性を解析する為に使用される。属性フラグ９２４および属性タイプコード９２６の解析により一旦属性が解析されれば、それら属性は、取り下げられたルート９４２、到達可能なルート９６２、次の転送先サーバ９８２、発信アドレス９９２およびキャリア１０１２のタイプを含む図９Ａおよび図９Ｂの中で識別されたタイプのうちの１つへ抽出される。属性長さフィールド９２８は、解析部（パーサ）が可変長さの属性を受け入れるか、或いは未知の属性をスキップすることができるように、後続の属性の長さを決定する為に使用される。
そして、解析された属性は、受け取られた順に処理される。したがって、好ましくは、取り下げられたルート９４２の属性は、到達可能なルート９６２の属性の前に処理される。取り下げられたルート９４２、到達可能なルート９６２、および発信アドレス９９２の属性は、すべては同じフォーマットを備えている。アドレスファミリーフィールド９４４、９６４および９９４は、ＰＯＴＳあるいはルーティング番号を参照する。２５４のアドレスファミリーコードは、ＵＲＩアドレスを示すために付け加えられた。プロトコルフィールド９４６、９６６および９９６は、通常、ＳＩＰあるいは値１にセットされる。長さフィールド９４８、９６８および９９８は、アドレス部分９５２、９７２および１００２の実際の長さ（好ましくは、バイトで）を示す。以前に述べたように、アドレス部分は部分的な電話番号あるいは部分的なＵＲＩのいずれかでもよい。次の転送先サーバ９８２およびキャリア１０１２のタイプが、同様の方法で解析されることに注意されたい。
下記は、ＴＲＩＰ「アップデート」メッセージの例を示す。なお、どのように「アップデート」メッセージが処理されるかを説明する為に、ここでは、ＴＲＩＢと「アップデート」メッセージの内容は、実際に用いられるバイナリのデータの代わりに単純なテキストとして、示しているということに注意されたい。
例：
ＴＲＩＰアップデート
取り下げられたルート： none
到達可能なルート： 1 [seq. Num.: 1, origin TRIP ID: 111]
次の転送先サーバ： sip:server.com
ＩＴＡＤトポロジー： 222
発信アドレス： tel:1-617
キャリア； NextGen/0000-2400/U-S/0.50/SHQ G.711
この例では、発信アドレス９９２はＵＲＩであり、到達可能なルート９６２は、部分的な電話番号であるということを理解すべきである。さらに、キャリア１０１２は、５つの部分、即ち、名前／時間／日／コスト／品質を備えていることも理解すべきである。到達可能なルート９６２の属性の隣の鍵括弧内のテキストは、リンク状態属性のシーケンス番号および起点ＴＲＩＰ ＩＤを示す。この例においては、取り下げられたルートはないので、対応するテキストは省略される。
ポリシーがロードされ、決定と広告が行われ、ＴＲＩＢの各々への変更が、好ましくは、以下のフォーマットによって行なわれる。
Figure 0004536999
この処理例について更に議論する前に、そのルータトポロジーを定義する必要がある。トポロジーは次のＳＲを含む。
・sr.acme.comに設けられているＩＴＡＤ２０２４のＴＲＩＰ ＩＤ１１１。
・sr2.acme.comに設けられているＩＴＡＤ２０２４のＴＲＩＰ ＩＤ２２２。
・sr3.acme.comに設けられているＩＴＡＤ２０２４のＴＲＩＰ ＩＤ３３３。
・external.carrier.comに設けられているＩＴＡＤ２０５５のＴＲＩＰ ＩＤ７８９。
図１０は、ＩＴＡＤトポロジーの例を示すブロックダイヤグラムである。必要な場合、ＩＴＡＤおよびＴＲＩＰ ＩＤの組み合わせは、ここでは、＜ＩＴＡＤ＞：＜ＴＲＩＰ ＩＤ＞のように表わされる。したがって、ＩＴＡＤ１０２４とＴＲＩＰ ＩＤ１１１の組み合わせは１０２４：１１１として書かれることになる。この例の全体にわたって、ＳＲは、それらのドメインアドレス３６４（図３Ｂ）、或いはそれらのＴＲＩＰ識別子３６６（図３Ｂ）およびＩＴＡＤ識別子３６８（図３Ｂ）のいずれかによって識別される。ＳＲ１０２４：２２２および５５５：７８９は１０２４：１１１に隣接している。また、ＳＲ１０２４：２２２および１０２４：３３３は互いに隣接している。
この例では、ＴＲＩＰ ＩＤ１１１を有するＩＴＡＤ２０２４におけるＳＲ（sr.acme.com）２０００から見た、ＴＲＩＢの初期化と処理について記述する。ＳＲ（sr.acme.com）２０００は、２つの隣接したピア（ＳＲ１０２４：２２２および５５５：７８９）、１つの外部ピア（ＴＲＩＰ ＩＤ７８９を有するＩＴＡＤ２０５５におけるexternal.carrier.com ２００３）および１つの内部ピア（ＴＲＩＰ ＩＤ２２２を有するsr2.acme.com ２００１）を備えている。ＳＲ（sr.acme.com）およびＳＲ（sr2.acme.com）が内部ＴＲＩＰピアであるので、それらは同じＩＴＡＤ番号を備えている。さらに、ＩＴＡＤ２０２４は、もう１つ別のＳＲ（すなわちＴＲＩＰ ＩＤ３３３を有するＳＲ（sr3.acme.com）２００２であり、それは、ＴＲＩＰ ＩＤ２２２を有するsr2.acme.com ２００１にのみ隣接している）を有している。
ＳＲ（sr.acme.com）２０００のローカルポリシー情報は、ルータ初期化の一部として以下に論ずる。この例の目的から、以下のことを述べておく。
・sr2.acme.com ２００１はローカルポリシー情報を持っていない。
・sr3.acme.com ２００２は、土曜日または日曜日の任意の時間に、０．１０のコストで遠いキャリアを使用するゲートウェイＤ ２００６経由で、任意のアドレスから、１−９７８で始まる任意の番号へのアクセスを許可するローカルポリシーを備えている。
・external.carrier.com ２００３（外部である為、この例では、この時点で、sr.acme.com ２０００にとって未知である）は、月曜日から金曜日の任意の時間に、０．５０のコストで、この外部キャリアを使用するゲートウェイＥ２００７経由で、任意のアドレスから、１で始まる任意の番号へのアクセスを許可するローカルポリシーを備えている。
現在の例において、５つのＴＲＩＢ（その各々はＳＲ２０００との関連から説明される）がある。隣接ＴＲＩＢ入力（Ａｄｊ−ＴＲＩＢ−Ｉｎ）は、外部の隣接ＴＲＩＢ入力（Ｅｘｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎ）および内部の隣接ＴＲＩＢ入力（Ｉｎｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎ）へ分解される。これは、様々なポリシー入力がどのように処理されるかについて更に詳しく議論することを可能とする。１つの外部（ＩＴＡＤへの）ピア当たり、１つのＥｘｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎがあり、したがって、ＳＲは、Ｅｘｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎを１つを持つ。同様に、１つの内部ＳＲ当たり、１つのＩＮＴ−Ａｄｊ−ＴＲＩＢ−Ｉｎがあり、したがって、この例は１つのＩＮＴ−Ａｄｊ−ＴＲＩＢ−Ｉｎから始めることができる。
内部ピアへの広告のために、処理済みの外部ルート情報とローカルのルート情報を含む１つの外部ＴＲＩＢ（Ｅｘｔ−ＴＲＩＢ）と、ルーティング決定を下すためにこのルータによって使用されるルーティング情報を含んでいる１つのローカルＴＲＩＢと、外部ピアへの広告のために処理済みのルートを含んでいる１つの隣接ＴＲＩＢ出力（Ａｄｊ−ＴＲＩＢ−Ｏｕｔ）が存在する。
この時点で、ＴＲＩＢがすべて初期化される。ＳＲが２つのピア（１つは外部、１つは内部）を持つので、初期化されたＴＲＩＢは以下のとおりである。
Figure 0004536999
初期化では、サーバは、そこに格納されているすべてのポリシー読み込み、ｌｏｃａｌ−ＴＲＩＢ、Ｅｘｔ−ＴＲＩＢおよび Ａｄｊ−ＴＲＩＢ−Ｏｕｔを実装する。この例では、次のローカルのコンフィギュレーションデータを仮定する。
キャリア： NextGen
名前： NextGen
記述： Local NextGen Carrier
サービス状態： 有効
ID: 10107654

キャリア： LastGen
名前： LastGen
記述： Local LastGen Carrier
サービス状態： 有効
ID: 10107655

キャリア： Enterprise
名前： Enterprise
記述： Local Enterprise Carrier
サービス状態： 有効
ID: 10107656

キャリア： External
名前： External
記述： Default Carrier associated with Inbound
ITAD 2055からアップデート
サービス状態： 有効
ID: 10109999

管理アカウント
ユーザーＩＤ：Cliff
パスワード： Rocket
アクセス権： Super User

隣接ルータ
第１エントリ
名前： external
ドメインアドレス： external.carrier.com
ＴＲＩＰ識別子： 789
ＩＴＡＤ識別子： 2055
第２エントリ
名前： sr2
ドメインアドレス： sr2.acme.com
ＴＲＩＰ識別子： 222
ＩＴＡＤ識別子： 2024

ＳＩＰエージェント
第１エントリ
ドメインアドレス： gateway1.acme.com
名前： Gateway A
記述： Gateway to NextGen Carrier
登録間隔： 30
キャリア[ ]: { NextGen }
第２エントリ
ドメインアドレス： gateway2.acme.com
名前： Gateway B
記述： Gateway to NextGen, LastGen Carriers
登録間隔： 30
キャリア[ ]: { LastGen, NextGen }
第３エントリ
ドメインアドレス： gateway3.acme.com
名前： Gateway C
記述： Gateway to Business
登録間隔： 30
キャリア[ ]: { Enterprise }

ＳＩＰエージェントグループ： Group A
ストラテジー： Hunt
エージェント数： 1
エージェントタイプ： SIP Endpoint
ＳＩＰエージェント： Gateway A

ＳＩＰエージェントグループ： Group B
ストラテジー： Hunt
エージェント数： 1
エージェントタイプ： SIP Endpoint
ＳＩＰエージェント： Gateway B

ＳＩＰエージェントグループ： Group C
ストラテジー： Hunt
エージェント数： 1
エージェントタイプ： SIP Endpoint
ＳＩＰエージェント： Gateway C

ＳＩＰエージェントグループ： Group A+B
ストラテジー： Hunt
エージェント数： 2
エージェントタイプ： SIP Endpoint
ＳＩＰエージェント： Gateway A
エージェントタイプ： SIP Endpoint
ＳＩＰエージェント： Gateway B

ＳＲ
ドメインアドレス： sr.acme.com
ＴＲＩＰ識別子： 111
ＩＴＡＤ識別子： 2024
名前： Acme SR
記述： SR for Acme Packet
場所： 130 New Boston Street; Woburn MA
ＴＲＩＰバージョン： 1.0
ＳＩＰバージョン： 2.0
ルータバージョン： 0.1
管理アカウント[ ]: { Cliff }
隣接ルータ[ ]: { external.carrier.com, sr2.acme.com }
ＳＩＰエージェント[ ]: { Gateway A, Gateway B, Gateway C}

第１エントリ
作成者： Cliff
追加日： 10:/01/2000
有効日付／時間： 0
無効日付／時間： 0
発信アドレス（ＵＲＩ）： *
着信アドレス（ＵＲＩ）： tel:1-781
次の転送先： Group B
サービス状態： 有効
ルート属性数： 2
第１属性
キャリア： NextGen
サービス状態： 有効
時間： 0000-2400
曜日： S
コスト: 0.10
QoS: SHQ G.711
第２属性
キャリア： LastGen
サービス状態： 有効
時間： 0000-2400
曜日： U
コスト: 0.15
QoS: SHQ G.711
第２エントリ
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
発信アドレス（ＵＲＩ）： *
着信アドレス（ＵＲＩ）： tel:1-781
次の転送先： Group A
サービス状態： 有効
ルート属性数： 2
第１属性
キャリア： NextGen
サービス状態： 有効
時間：0000-0700,1700-2400
曜日： M-F
コスト: 0.20
QoS: SHQ G.711
第２属性
キャリア： NextGen
サービス状態： 有効
時間：0700-1700
曜日： M-F
コスト: 0.30
QoS: SHQ,G.711
第３エントリ
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
発信アドレス（ＵＲＩ）： *
着信アドレス（ＵＲＩ）： tel:1-781-933
次の転送先： Group C
サービス状態： 有効
ルート属性数： 1
第１属性
キャリア： Enterprise
サービス状態： 有効
時間： 0000-0700,1700-2400
曜日： M-F
コスト: 0.25
QoS: SHQ G.711
第４エントリ
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
発信アドレス（ＵＲＩ）*
着信アドレス（ＵＲＩ）： acme.com
次の転送先： Group C
サービス状態： 有効
ルート属性数： 1
第１属性
キャリア： Enterprise
サービス状態： 有効
時間： 0000-2400
曜日： M-F
コスト: 0.25
QoS: SHQ G.711
第５エントリ
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
発信アドレス（ＵＲＩ）： *
着信アドレス（ＵＦＩ）： tel:1-617
次の転送先： Group A = B
サービス状態： 有効
ルート属性数： 1
第１属性
キャリア： NextGen
サービス状態： 有効
時間： 0000-2400
曜日： U-S
コスト: 0.25
QoS: SHQ G.711
隣接ＩＴＡＤ
ＩＴＡＤ識別子： 555
名前： External Network
記述： External ITAD
境界内スクリーン：
スクリーン#1:
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
許可
部分的着信アドレス： *
ポリシー属性数： 1
第１ポリシー属性
キャリア： External
サービス状態： 有効
時間： 0000-2400
曜日： U-S
コスト: 0.20
QoS: SHQ G.711
境界外スクリーン：
スクリーン#1:
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
許可
部分着信アドレス（ＵＲＩ）： 1-781
ポリシー属性数： 2
第１ポリシー属性
キャリア： Enterprise
サービス状態： 有効
時間： 0000-2400
曜日： U-S
コスト基準： 0.00-0.50
ＱＯＳ基準： SHQ G.711
第２ポリシー属性
キャリア： LastGen
サービス状態： 有効
時間： 0000-2400
曜日： U-S
コスト基準： 0.00-0.50
ＱＯＳ基準： SHQ G.711
スクリーン#2:
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
許可
部分着信アドレス（ＵＲＩ）： 1-978
ポリシー属性数： 0
以下に示される「アップデート」メッセージ処理のより詳細な説明に先立って、上に定義したローカルポリシーの説明を行う。ローカルポリシーの、キャリア以外の他の属性にも、焦点を合わせることに注意されたい。定義された第１の３つのキャリア（つまりＮｅｘｔｇｅｎ、ＬａｓｔｇｅｎおよびＥｎｔｅｒｐｒｉｓｅ）は、ローカルのＳＲポリシー定義のために使用される。最後のキャリア（つまりＥｘｔｅｒｎａｌ）は、ＩＴＡＤ２０５５からの「アップデート」メッセージによってＩＴＡＤ２０２４に入る任意のルートに割り当てられるデフォルトキャリアとして使用される。
隣接したルータは、内部および外部ピアsr.acme.com ２０００ ＴＲＩＰに関する情報を含んでいる。そしてこの情報は、接続を開始し、かつメッセージ内容を有効にする為に使用される。隣接したＳＩＰエージェントは、このＳＲが、アクセスを制御する３つのゲートウェイを示す。定義された３つのＳＩＰエージェントグループ（つまりグループＡ、ＢおよびＣ）は、単に単一のエージェントグループであり、ゲートウェイ毎に１つ存在する。最後のＳＩＰエージェントグループ（グループＡ＋Ｂ ２００９）は、ゲートウェイＡ ２００４およびゲートウェイＢ ２００５の両方を含んでいる。複数のエージェントを有するグループのコンフィギュレーションは、同じポリシーをサービスするゲートウェイに対して、異なるストラテジー（例えばハント（Ｈｕｎｔ）、ラウンドロビンなど）および基準（例えばアクティブセッションの数のような制約）を使用してアクセスすることを可能とする。
ＳＲは、このセッションルータに特有のデータ（つまり、稼働開始、メッセージ評価および「アップデート」メッセージ処理のために使用されるデータ）について記述する。ローカルポリシーは、好ましくは、ＳＲに隣接しているゲートウェイに関係する。キャリアＮｅｘｔＧｅｎ、ＬａｓｔＧｅｎおよびＥｎｔｅｒｐｒｉｓｅはＳＲsr.acme.com ２０００のために定義されている。第１から第４のポリシーは、関連する時間フレームおよびコストに依存して、特定の発信アドレスから特定の着信アドレスへセッションが送ることができる、隣接したゲートウェイを通るルートを示す。隣接したＩＴＡＤのエントリは、現在のルータとポリシーを交換する外部のＩＴＡＤを示す。
スクリーン（境界内の７２２（図７）、および境界外の８０２（図７））は、このＩＴＡＤ２０２４と、このＳＲ２０００が通信できる外部のＩＴＡＤの間の情報のフィルータリングを行うために使用される。この時、外部のＩＴＡＤがキャリア属性を送信したり処理しないので、外部デフォルトキャリアが、ＩＴＡＤ２０５５から受け取ったポリシーを拡張する為に確立される。この例のＩＴＡＤ２０２４は、これらの属性を処理する。境界内のスクリーンは、任意の番号（＊によって表示された）に関連付けられたポリシーを受理する為に確立される。これらのポリシーが受理される場合、それらは、ポリシーの時刻または曜日の制限にかかわらず、キャリアＥｘｔｅｒｎａｌに関連付けられる。このルーティングされたネットワークは、ゲートウェイＣ ２００８と名付けられたビジネスゲートウェイと、ゲートウェイＡ ２００４およびゲートウェイＢ ２００５と名付けられた２つのキャリアゲートウェイ、およびゲートウェイＥ ２００７（それは、外部キャリアによって表わされる外部のＩＴＡＤ内にある）の間のポリシーベースのルーティングが行われる。キャリアＬａｓｔｇｅｎおよびＥｎｔｅｒｐｒｉｓｅを使用し、１−７８１で始まる番号を持ち、所定の時間フレーム内のポリシーだけが、ＩＴＡＤ２０５５に広告されるように、１つの境界外のスクリーンが設定される。異なるＩＴＡＤエントリは同じ部分着信アドレスのスクリーンと異なるポリシー属性を持てるが、各ＩＴＡＤエントリは、好ましくは、与えられた部分着信アドレスのスクリーンをただ１つだけ備えている。（隣接＝ピア）。
任意のキャリアを使用し、１−９７８で始まる番号へのポリシーだけが、ＩＴＡＤ２０５５へ広告されるように、別の境界外のスクリーンが定義される、 特定のキャリアエントリが無いということは、どんなキャリアもスクリーンを通れることを示す。スクリーンの使用は、ルート決定段階およびルート配布に更なる柔軟性と制御性を与える。ＴＲＩＰサーバがローカルポリシーデータベースを開き、ポリシーをロードし始めた後、以下に詳述される次のような状況が生じる。
格納されたローカルポリシーデータベース中の第１のポリシーは次のとおりである。
第１エントリ
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
発信アドレス（ＵＲＩ）： *
着信アドレス（ＵＲＩ）： tel:1-781
次の転送先： Group B
サービス状態： 有効
ルート属性数： 2
第１属性
キャリア： NextGen
サービス状態： 有効
時間： 0000-2400
曜日： S
コスト: 0.10
QoS SHQ G.711
第２属性
キャリア： LastGen
サービス状態： 有効
有効
時間： 0000-2400
曜日： U
コスト: 0.15
QoS: SHQ G.711
第１のポリシーは、現在の時間と活性化日付／時間の比較によりそれがアクティブだったかどうか確かめる為に再検討される。ポリシーが現在アクティブでない場合、将来の特定の時間に、格納されたローカルポリシーデータベースから、このポリシーを再注入する為に、タイマーがセットされる。ポリシーが現在アクティブでない場合、それ以前に処理は行われない。同じ発信アドレスフィールド４７４（図３Ａ）および着信アドレスフィールド４７６（図３Ａ）を備えたポリシーの中から、１つのポリシーが選択されていた場合、将来の特定の時間に、そのルートが取り下げられるように、非活性化タイマーをスタートさせることができる。ここでは、有効日付／時間４６８（図３Ａ）の値が０であり、および無効日付／時間４７２（図３Ａ）の値が０であるので、ポリシーは常にアクティブである。したがって、ポリシーは、直ちにＥｘｔ−ＴＲＩＢに加えられるべきである。
ＴＲＩＰ ＬＳは、決定段階１で、１つのルートを他のものより優先したりはしない。「招待」メッセージが処理される場合、これらの決定はＳＩＰプロキシサーバに委ねられる。これは、等価と見なされるルート上の分配パターン或いは日時のような基準に基づく、より複雑なルート選択を可能とする。好ましくは、ローカルの優先度属性は一つの値にセットされる。ＴＲＩＰ ＳＲの稼働開始シナリオは、決定段階１の特定の場合および決定段階２の第１の部分であり、ピア接続がまだ開かれていないので、Ａｄｊ−ＴＲＩＢ−ＩｎＳはすべて空である。発明の好ましい実施形態によれば、ここに記述されるようなルートが、標準のＴＲＩＰやＢＧＰ−４のルートよりも多くの情報を含み得るので、終点アドレスのみについて、ルートが多少とも特定されたりはしないと考えられる。
Figure 0004536999
ＳＲが起動プロセス中なので、まだ、広告すべきものはなく、Ｅｘｔ−ＴＲＩＢの中のエントリは、内部ピアに対して広告されない。更に、ＩＮＴ−Ａｄｊ−ＴＲＩＢ−Ｉｎからの入力はなく、したがって、第２段階の第２の部分は、Ｅｘｔ−ＴＲＩＢと同じｌｏｃａｌ−ＴＲＩＢを生成する。発明の好ましい実施形態により使用される決定段階は、標準のＴＲＩＰの実行によって使用されるものとは違っている。
Figure 0004536999
他の属性が同じである限り、このルートについて、マルチキャリアルーティングを行うために必要とされる数のキャリアエントリが設けられることに注意されたい。ここでも、ピア接続がまだ開かれていないので、各々のＩｎｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎは空であり、無視することができる。次のステップは、このポリシーが外部と共有されることになっているかどうか確かめることである。これをする為に、ＩＴＡＤ２０５５（ポリシー交換対象である唯一のＩＴＡＤ）の境界外のポリシースクリーンを調べる。
スクリーン#1:
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
許可
部分的着信アドレス： 1-781
ポリシー属性数： 2
第１ポリシー属性
キャリア： Enterprise
サービス状態： 有効
時間： 0000-2400
曜日： U-S
コスト基準： 0.00-0.50
ＱＯＳ基準： SHQ G.711
第２ポリシー属性
キャリア： LastGen
サービス状態： 有効
時間： 0000-2400
曜日： U-S
コスト基準： 0.00-0.50
ＱＯＳ基準： SHQ G.711
スクリーン#2:
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
許可
部分的着信アドレス： 1-978
ポリシー属性数： 0
第１のスクリーンの部分的着信アドレスが、第１のローカルポリシーの着信アドレスの最初の４バイトに一致するので、これが最長且つ最適な一致であり、外部と共有すべきかどうか決める為に、この境界外のポリシースクリーンが選択される。（第２のスクリーンの部分的着信アドレスは、第２の桁（ディジット）で一致しない。）図１１は、与えられたポリシーが外部に広告されるかどうか決める為に、最適のマッチングスクリーンを使用するプロセスを示すフローチャートである。ブロック２１０２によって示されているように、スクリーンの活性化日付／時間と非活性化日付／時間を決める為にチェックがなされる。活性化日付／時間と非活性化日付／時間が両方とも０であるので、現在のポリシーはアクティブなままである。その後、ブロック２１０４によって示されているように、スクリーンの許可／拒絶状態を決めるチェックが行われる。許可／拒絶属性は許可にセットされているので、現在のポリシーはアクティブなままである。
その後、ブロック２１０６によって示されているように、外部のＩＴＡＤ２０５５の最も良く一致する境界外のポリシースクリーンの属性に対して、現在のポリシーの属性を決める為のチェックが行われる。最も良く一致するスクリーンは、そのキャリアリストにＬａｓｔＧｅｎキャリアを持ち、ＬａｓｔＧｅｎキャリアが有効になっているので、現在のポリシーはアクティブなままである。ＮｅｘｔＧｅｎキャリアは、ＩＴＡＤ２０５５に対して選択された境界外のポリシースクリーンの中にない。したがって、ルートはアクティブなままで、キャリア属性なしで外部的に広告されることとなる。ＩＡＮＡがキャリア属性を承認した場合には、このポリシーは、ＬａｓｔＧｅｎキャリアを含むがＮｅｘｔＧｅｎキャリアは含まない形で広告されることとなる。
ブロック２１０８によって示されているように、それらがより限定的な場合、時刻および曜日を有効にして、ポリシーは隣接ＴＲＩＢ出力へ追加される。このケースでは、時刻、曜日、コストおよびＱｏＳ（品質）属性は、境界外のポリシースクリーンにおいて限定的ではない。したがって、ポリシーのキャリア属性は変えられることなく、隣接したルータに送られる。
外部のＴＲＩＰピアがキャリア属性を処理することができるような状況で、ポリシーの内容は、次のとおりとなる。
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
発信アドレス（ＵＲＩ）： *
着信アドレス（ＵＲＩＪ）： tel:1-781
次の転送先： gateway2.acme.com
サービス状態： 有効
ルート属性数： 1
第１属性
キャリア： LastGen
サービス状態： 有効
時間： 0000-2400
曜日： U
コスト: 0.15
QoS: SHQ G.711
好ましくは、ポリシーおよびキャリアエントリのサービス状態フィールドは、広告されたポリシーでなく、ローカルのコンフィギュレーションの一部である。ポリシーあるいはそのキャリアのうちの１つが無効である場合、そのポリシー又はその部分は、任意のＴＲＩＢに入力されず広告もされない。ＳＲは、それが制御するゲートウェイに流れ込むトラヒックを把握している必要があるので、広告（つまり、外部広告、あるいは内部広告）が行われる場合、ローカルゲートウェイの次の転送先サーバアドレスがＳＲに置き換えられる。
前のスクリーニング例と対比して、次のスクリーニングシナリオを説明する。ＩＴＡＤ２０５５のための第１の境界外のポリシースクリーンが次の通りと仮定する。
スクリーン#1:
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
許可
部分的着信アドレス： 1-781
ポリシー属性数： 2
第１ポリシー属性
キャリア： Enterprise
サービス状態： 有効
時間： 0700-1500
曜日： U-S
コスト基準： 0.00-0.50
ＱＯＳ基準： SHQ G.711
第２ポリシー属性
キャリア： LastGen
サービス状態： 有効
時間： 0700-1500
曜日： U-S
コスト基準： 0.00-0.50
ＱＯＳ基準： SHQ G.711
この場合、生成されるポリシーはより、限定的なオペレーションの許可時間に合わせて変更される。したがって、このポリシーは、外部のＴＲＩＰサーバに適用されるとともに、次のキャリア属性を含む。（下記のものは広告されたポリシーであるので、サービス状態フィールドが除かれていることに注意されたい）
第１属性
キャリア： LastGen
時間： 0700-1500
曜日： U
コスト: 0.15
QoS: SHQ, G.711
境界外のポリシースクリーニングは、どのポリシーをエクスポートすべきかを制御する為の強力なツールである。エクスポートされる為に、このポリシーは、これらのテストすべてに合格しなければならないので、それは多くの柔軟性を必要とする。さらに、到達可能なルートや着信アドレス属性を絞ることが可能であることに注意されたい。したがって、この従前のポリシーは１−７８１を参照することができたが、境界外のスクリーンは１−７８１−９３３を参照することができていた。この場合、エクスポートされたポリシーは、１−７８１ではなく、より絞られた１−７８１−９３３を広告されることとなる。
下記は上記の例を拡張し、Ａｄｊ−ＴＲＩＢ−Ｏｕｔのエントリを参照する。
Figure 0004536999
ＩＡＮＡがキャリアおよびＱＯＳ属性のＴＲＩＰ拡張を承認するまで、上記、発信アドレスおよびキャリアの列は、外部ピアへは送られないことに注意されたい。他の４つのルートに同じプロセスを適用した後に、sr.acme.comのＴＲＩＢは以下のようになる。
Figure 0004536999
Figure 0004536999
Figure 0004536999
Figure 0004536999
Figure 0004536999
グループＡ＋Ｂ １００９が、現実に２つのゲートウェイを参照することに注意されたい。「招待」が到着し、そのために選ばれた最適のポリシーが、次の転送先サーバとしてグループＡ＋Ｂ２００９を有している場合、各ゲートウェイの現在および以前のセッションに関する統計値情報は、セッションリクエストがどのゲートウェイに向けられるか決める為に使用される。そして、ローカルに格納されたポリシーと共に、Ｅｘｔ−ＴＲＩＢ、ローカルＴＲＩＢおよびＡｄｊ−ＴＲＩＢ−Ｏｕｔの初期化が完了する。
次のステップはピアに接続を開くことである。好ましくは、次の２種類のピアがある。つまり、ローカルピアおよび外部ピアである。ローカルピアはsr.acme.com ２０００と、そのローカルポリシーを共有する為に、注流スキームを使用する。例えば、ＴＲＩＰの注流プロセスは以下のように記述される。ＴＲＩＰ ＬＳが、内部ピアから「アップデート」メッセージを受け取る場合、ＴＲＩＰ ＬＳは、そのメッセージからの新しい情報を、他のすべての内部ピアに注流させる。注流は、ドメインの内部トポロジーへのどんな制約も加えることなく、ドメイン内のＴＲＩＰ ＬＳのすべてを効率的に同期させる為に用いられる。
内部ＳＲピアへの接続が開かれる。ソケットが開かれ、ＴＲＩＰ「オープン」メッセージとバージョンネゴシエーションが実行された後、「アップデート」メッセージは、両方向に注流され始める。sr2.acme.com ２００１からのメッセージは、そのＥｘｔ−ＴＲＩＢエントリのすべてをsr.acme.com ２０００と共有し、sr.acme.com ２０００の方へ向かって送られ始める。反対に、sr.acme.comは、sr2.acme.com ２００１に、そのＥｘｔ−ＴＲＩＢエントリをすべて送り始める。このように、内部ＳＲは、Ｅｘｔ−ＴＲＩＢエントリを交換し、新しくアクセス可能なピアへの他の内部ピアのためのＩＮＴ−Ａｄｊ−ＴＲＩＢ−ＩｎＳの中の任意のエントリを伝搬させる。同様に、外部に隣接したＳＲは、Ａｄｊ−ＴＲＩＢ−Ｏｕｔエントリを交換する。この時、「アップデート」メッセージは、Ｅｘｔ−ＴＲＩＢの中のエントリの為に、次の内容で内部ピアへ送られる。
ＴＲＩＰアップデート：
取り下げられたルート： None
到達可能なルート： 1-781 [Sequence Number: 1,TRIP ID: 111]
次の転送先サーバ： sr.acme.com
ＩＴＡＤトポロジー： 222
発信アドレス： *
キャリア： NextGen/0000-2400/S/O.10/SHQ G.711
キャリア： NextGen/0000-0700, 1700-2400/M-F/0.20/SHQ G.711
キャリア： NextGen/0700-1700/M-F/.30/SHQ G.711
キャリア： LastGen/0000-2400/U/0.15/SHQ G.711

ＴＲＩＰアップデート：
取り下げられたルート： None
到達可能なルート： 1-781-933 [Sequence Number: 1,TRIP ID: 111]
次の転送先サーバ： sr.acme.com
発信アドレス： *
キャリア： Enterprise/0000-0700,1700-2400/M-F/0.25/SHQ G.711

ＴＲＩＰアップデート：
取り下げられたルート： None
到達可能なルート： acme.com [Sequence Number: 1,TRIP ID: 111]
次の転送先サーバ： sr.acme.com
発信アドレス： *
キャリア： Enterprise/0000-2400/M-F/0.25/SHQ G.711

ＴＲＩＰアップデート：
取り下げられたルート： None
到達可能なルート： 1-617 [Sequence Number: 1,TRIP ID: 111]
次の転送先サーバ： sr.acme.com
発信アドレス： *
キャリア： NextGen/0000-2400/U-S/0.10/SHQ G.711
「アップデート」メッセージヘッダーでは、シーケンス番号と呼ばれる生成／バージョン番号が含まれることに注意されたい。ＴＲＩＰによって定義されるように、シーケンス番号は、ルートの１つのバージョンが、ルートの別のバージョンより新しくなる時を決める為に使用される。より大きなシーケンス番号はより新しいバージョンを示す。シーケンス番号は、ローカルＩＴＡＤへルートを生成するＴＲＩＰ ＬＳによって割り当てられる。
ＳＲがルート（例えば、新しいレートを持ったキャリアを含むもの）の新しいインスタンスを生成する場合は常に、バージョン番号は１だけインクリメントされる。この番号は、注流中（そこで同じＩＴＡＤの内のＳＲはルートのインスタンスを受け取る）に重複を検知する為に、ＴＲＩＰ ＩＤと組み合わせて使用される。さらに、ここでは、この隣接したエージェントに送られた最初の「アップデート」メッセージなので、すべての既知の内部隣接ルータの完全なリストである現在のＩＴＡＤトポロジーが含まれている。好ましくは、ＳＲのそのローカルのトポロジーに対する知識が変わる場合、これが利用される。
ＳＲはそれ自身（sr.acme.com ２０００）、内部広告中の実際のゲートウェイを置き換える。上記第２の「アップデート」メッセージでは、gateway3.acme.com ２００８の次の転送先サーバの代わりに、次の転送先サーバは、sr.acme.com ２０００にセットされる。しかしながら、ＴＲＩＰ ＬＳは、その決定のために、本当の次の転送先サーバ（ゲートウェイ）を使用する。最初の２つのルートが同じ発信アドレスと同じ着信アドレスを持つので、（たとえＥｘｔ−ＴＲＩＢに５つの「アップデート」メッセージがあっても）４つの「アップデート」メッセージ（つまりルート）だけが送られる。次の転送先サーバが、ＴＲＩＰ ＬＳのドメインアドレスと置き換えられる場合、キーとなるフィールドの３つがすべて同じなので、これらの２つのルートは一つへ結合される。
新しいキャリアと発信アドレス属性がある場合、ＴＲＩＰ ＬＳが、「アップデート」メッセージを使って、一度に複数のルートに送る可能性は少ない。「アップデート」メッセージの内容に含まれる制限に加えて、「アップデート」メッセージに含まれた各ルートは、同じ発信アドレスとキャリアエントリを備えている。しかしながら、取り下げられたルートおよび到達可能なルート属性は、同じ「アップデート」メッセージの中に含まれることは可能である、 別の可能性は、より一般的なルートの取り下げ、および正確に同じ属性を備えた１つ以上の特定のルートによる置き換えである。srsr2.acme.com 2001は、sr.acme.com ２０００で使用する為に、Ｅｘｔ−ＴＲＩＢエントリを注流し始める。ローカルピアとの接続が確立された後、外部ピアとの接続が進む。
sr2.acme.com ２００１からの次の「アップデート」メッセージを考慮されたい。
ＴＲＩＰアップデート：
取り下げられたルート： None
到達可能なルート： 1-978 [Sequence Number: 1, TRIP ID: 333]
次の転送先サーバ： sr3.acme.com
ＩＴＡＤトポロジー： 111, 333
発信アドレス： *
キャリア： Faraway/0000-2400/U,S/0.10/SHQ G.711
この「アップデート」メッセージがsr2.acme.com ２００１から受け取られた場合、そのバージョンを１とする（それはルート生成者がそれをちょうど作成したばかりであることを示す）。さらに、例えば、（sr.acme.comに隣接していない）新しいローカルのルータの存在を示す、ＩＴＡＤトポロジー、をＴＲＩＰ ＩＤ３３３と共に送る。このトポロジーの変更は、ＴＲＩＰ ＩＤ３３３から（ＴＲＩＰ ＩＤ２２２あるいはsr2.acme.com経由で）sr.acme.comがＥｘｔ−ＴＲＩＢポリシーの注流を受け取るという点で重要である。そして、ＳＲ（sr.acme.com）２０００は、新しく発見された内部ＳＲ（sr3.acme.com）２００２のために、新しいＡｄｊ−ＴＲＩＢ−Ｉｎ、を作成する。
Figure 0004536999
仮に未知のキャリア名が受け取られれば、インテリジェントデフォルトを備えたローカルでサポートされたキャリアのリストに、エントリが加えられなければならないこととなる。このイベントはトラップされ、管理ステーションへ転送される。
sr2.acme.com ２００１（ＴＲＩＰ ＩＤ２２２）は、sr.acme.com ２０００からの「アップデート」メッセージの注流を受け取るので、それらはsr3.acme.com ２００２へ転送される。同様に、sr3.acme.com ２００２からsr2.acme.com ２００１へ送られた付加的な「アップデート」メッセージも、sr.acme.com ２０００へ転送される。ここでも、各ＴＲＩＰ ＬＳは、ローカルピアへのルート広告を生成する前に、そのローカルポリシーの中で、本当の次の転送先サーバをそれ自体で置き換える。
この時、新しく作成されたＩＮＴ−Ａｄｊ−ＴＲＩＢ−Ｉｎから、この新しいポリシー情報が、修正済の決定段階に送られる。（ＴＲＩＰ ＩＤ２２２およびＴＲＩＰ ＩＤ３３３のための）Ｉｎ−Ａｄｊ−ＴＲＩＢ−ＩｎとＥｘｔ−ＴＲＩＢは、着信アドレスや発信アドレスのフィールドと一致する他のポリシーを含まないので、選択の問題はない。たとえ一致しても、すべてポリシーはまだ選択されており、ＳＩＰプロキシサーバによって照会された時、ＴＲＩＰ ＬＳは最終選択を行なう。ローカルポリシーが既に使用され、２０５５：７８９のためのＥｘｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎはまだ空なので、Ｅｘｔ−ＴＲＩＢの内容は、このプロセスの間に変わらない。
sr.acme.comのためのローカルＴＲＩＢの内容は、現時点で、次のとおりである。
Figure 0004536999
その後、ローカルＴＲＩＢは、決定段階３で処理される。決定段階３の一部として、境界外のスクリーンコンフィギュレーションは、このローカルポリシーを外部ピアへ広告することが可能かどうかを確かめる為に調べられる。このプロセスは、前に、ローカルポリシーが受理された時、この例の中で説明した。そして、この同じプロセスが行われる場合、このルート（それはスクリーンより限定的である）が、ＳＲのすべての外部ピアに広告されるべきことが分かる。ここでのＡｄｊ−ＴＲＩＢ−Ｏｕｔの内容は、次のテーブルの中で示されるようなものである。
Figure 0004536999
以下に、ＩＴＡＤ２０５５の為のスクリーンを示す。
スクリーン#1:
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
許可
部分的着信アドレス： 1-781
ポリシー属性数： 2
第１ポリシー属性
キャリア： Enterprise
サービス状態： 有効
時間： 0000-2400
曜日： U-S
コスト基準： 0.00-0.5 0
ＱＯＳ基準： SHQ G.711
第２ポリシー属性
キャリア： LastGen
サービス状態： 有効
時間： 0000-2400
曜日： U-S
コスト基準： 0.00-0.50
ＱＯＳ基準： SHQ G.711
スクリーン＃１は、次のものからのポリシーを許可する。即ち、「発信：＊」、「着信：電話番号：１−７８１」、「グループＢ」、しかし、キャリアＬａｓｔｇｅｎが好ましい。
ＩＴＡＤ２０５５のためのＡｄｊ−ＴＲＩＢ−Ｏｕｔからは、「発信：＊」、「着信：電話番号：１−７８１」、「グループＢ」のポリシーは、除外される。なぜなら、一致するキャリアが無いからである。キャリア（Ｅｎｔｅｒｐｒｉｓｅ）は、スクリーンを通過できルータだ一つのキャリアなので、「発信：＊」、「着信：電話番号：１−７８１−９３３」、「グループＣ」のポリシーは、その全体に追加される。
「発信：＊」、「着信：acme.com」、「グループＣ」のポリシーと、「発信：＊」、「着信：電話番号：１−６１７」、「グループＡ＋Ｂ」のポリシーは、一致する部分的着信アドレスが定義されていないので除外される。下記は、ＩＴＡＤ２０５５のためのスクリーン＃２に関する情報である。
スクリーン#2:
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
許可
部分的着信アドレス： 1-978
ポリシー属性数： 0
第２の境界外のスクリーンが、マッチすべきキャリアを何も指定していないので、スクリーン＃２は、「発信：＊」、「着信：１−９７８」、「グループＣ」のポリシーを許可する。したがって、この時、たとえ遠いキャリアが、sr.acme.com ２０００に知られていなくても、このポリシーはスクリーンを通ることが許される。中にキャリアを含まないスクリーンは、そのポリシーがどのキャリアを含んでいるかには関係なく、どんなマッチングポリシーも通ることが許される。同様に、中にキャリアを含まないポリシーは、自由なセッションアクセス（つまり、何時でも、コスト無しで使用可能なアクセス）に対応する。
ここに詳述していないが、Ａｄｊ−ＴＲＩＢ−Ｏｕｔを作成するとき、効率の為にルートの集成を行うことも可能である。この手続きの詳細な記述は、Ｒｏｓｅｎｂｅｒｇらによって、「ＩＰ（ＴＲＩＰ）の上のテレフォニールーティング」、ＩＰＴＥＬワーキンググループインターネットドラフト（２０００年１１月）の中で提供されており、その内容をこの出願の一部とする。例えば、１−９７８のルートおよび１−９７８−２４６のルートが受け取られる場合、他のすべての属性が同じなら、それらは、より限定的でない１−９７８のルートへと結合される。１−９７８−２４０、１−９７８−２４１、１−９７８−２４２、１−９７８−２４３、１−９７８−２４４、１−９７８−２４５、１−９７８−２４７、１−９７８−２４８および１−９７８−２４９のポリシーが存在し、ここに無い１−９７８−２４６が受け取られた場合、それらは集成される。集成が行われた場合、ポリシーへの次の変更が行なわれる。即ち、もはや要求されないエントリは、除去され、より新しいエントリと置き換えらる。又、次の転送先サーバが、このサーバに変更される。更に、要素集成の属性がセットされる。
この集成では、外部と共有可能なポリシーは等しい必要がある。キャリア、時刻、曜日、コストおよびＱＯＳ属性が、外部ピアと通信するのに使用されない場合、これらは集成の際に考慮されない。
一旦、内部初期化が完了したならば、すべてのローカルピアからの、すべての注流が完了したと仮定して、その時、ＴＲＩＢ内容がすべて調べられる。
Figure 0004536999
Figure 0004536999
Figure 0004536999
Figure 0004536999
Figure 0004536999
Figure 0004536999
隣接したピアから受けたポリシーはローカルＴＲＩＢだけに入力されるので、Ｅｘｔ−ＴＲＩＢおよびローカルＴＲＩＢは、最後のルート（つまり、「発信：＊」、「着信：１−９７８」、sr3.acme.com）を除いて同一である。いずれの決定処理が適用される前に、それらは他のすべてのローカルピアに伝搬される。ローカルＴＲＩＢエントリのすべてが、（同じＩＴＡＤの内の）ローカルピアのすべてに送られた場合、次のステップは、外部のポリシーを交換するプロセスを始めることである。外部ポリシーの交換は、シーケンス番号が含まれていないことを除いて、注流プロセスと同様である。また、スクリーニングプロセスを経て残ったポリシーの各々は、ローカルで使用されるすべての属性が削除され、外部ピアへ送られる。外部のＳＲがＳＲ２０００に接続した場合、次の「アップデート」メッセージは、sr.acme.com ２０００年から、アドレスexternal.carrier.com ２００３を持つ外部のＳＲまで送られる。
ＴＲＩＰアップデート：
取り下げられたルート： None
到達可能なルート： 1-781 []
次の転送先サーバ： sip:sr.acme.com
広告パス： 2024
ルートパス： 2024
ＴＲＩＰアップデート：
取り下げられたルート： None
到達可能なルート： 1-781-933 []
次の転送先サーバ： sip:sr.acme.com
広告パス： 2024
ルートパス： 2024
ＴＲＩＰアップデート：
取り下げられたルート： None
到達可能なルート： 1-978 []
次の転送先サーバ： sip:sr3.acme.com
広告パス： 2024
ルートパス： 2024
このピアと共有するルートを含んでいる外部ピアの夫々に対して、１つのＡｄｊ−ＴＲＩＢ−Ｏｕｔが存在する。ＩＡＮＡがまだＴＲＩＰに対する現在の拡張を採用していないので、発信アドレスとキャリアの属性は、「アップデート」メッセージから除外される。もし、ポリシーの着信アドレス（ＵＲＩ）のアドレスファミリーコードが「ｔｅｌ：」の形式で２５４だったとすると、到達可能なルート属性にそれを加える前に、それはＰＯＴＳあるいはルーティング番号フォーマットに変換されなければならない。インターネットアドレスを含むポリシーの着信アドレスが、「ｔｅｌ：」の形式でなければ、到達可能なルート属性を実装できない。到達可能なルート属性を実装できない場合、「アップデート」メッセージは送られない。もし、以前のＴＲＩＰ仕様に記述されたバージョンネゴシエーション中に、このピアで、それらのパラメタが処理可能であったとすれば、それらはそのまま送られる。
外部のＩＴＡＤにポリシーを送る為に、（外部のＩＴＡＤに理解されない）キャリア属性が削除される場合、この属性によって定義され許可された時間フレームが、その外部ピアに何らかの形で送られることを保証する為に、起点ＩＴＡＤのＳＲに対して追加の処理が行われる。この処理は、現在の時間がキャリア属性で定義された時間フレームに入る時に、外部のＩＴＡＤへのポリシーを広告することと、現在の時間がキャリア属性で定義された時間フレームを過ぎた場合、ＩＴＡＤからポリシーを取り下げることを含む。
上記の第１の「アップデート」メッセージに関して、ＩＴＡＤ２０５５に広告されたポリシーは、「到達可能：１−７８１」であるが、それが基づいた実際の内部ポリシーは、土曜日（一日中）だけ有効なキャリアエントリ（ＬａｓｔＧｅｎ）を含んでいる。したがって、土曜日の午前１２：００に、このポリシーはＩＴＡＤ２０５５に広告され、そして、日曜日の午前１２：００に、取り下げられる。キャリア属性のＩＡＮＡ承認は、この追加処理の必要性は除外するかもしれない。承認に際して、異なるＩＴＡＤによって定義され、同じ名前を持つキャリアを識別する何らかの方法が必要となる（例えば、キャリアを識別する為にＩＴＡＤおよびキャリア名を使用する等）。
広告パスおよびルートパス属性は、後で、ＴＲＩＰ「アップデート」メッセージの中で詳述される（それらは、ローカルポリシー管理において無意味であるので、これまでは省略された）。基本的に、ルートパス属性は、このルートを使用してメッセージを送る際に通過するＩＴＡＤを識別しており、広告パス属性は、広告に含まれるルーティング情報を通過させたＩＴＡＤを識別する。基本的に、このパス中のＩＴＡＤは、広告パス中のものの部分集合である。
これらのポリシーを受け取ってから、external.carrier.comのＴＲＩＰサーバは、ネットワークを介して、sr.acme.comのサーバへ、マッチングアドレスを伴う呼び出しを送る。さらに、外部キャリアからのポリシーは、 我々のＳＲ、sr.acme.comに送られる。ここで、ＳＲは、次の「アップデート」メッセージを受け取ると仮定されている。
ＴＲＩＰアップデート：
取り下げられたルート： None
到達可能なルート： 1
次の転送先サーバ： sip:external.carrier.com
広告パス： 2055
ルートパス： 2055
この外部の、或いは外のポリシーの処理は、次のステップからなる。
１．適切なＥｘｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎへ、ポリシー（生の形式）を加える。
２．現在のＳＲ２０００への参照又は／および巡回参照の為のスキャンを行う。
３．情報を、境界内のポリシースクリーンと比較して、要求される受信ポリシーの受理や制限を行う。
４．受理されれば、ポリシーにデフォルトパラメタ（例えば、デフォルトの発信アドレス、キャリア、時刻、曜日、コストおよびＱＯＳ）をすべて加えて、指定の通りに、受信ルートへローカルポリシーを加える。もし、ポリシーのデフォルト属性が有効であれば、キャリア、時刻、曜日、コストおよびＱＯＳのデフォルトパラメタは、単に、追加されるだけである。
５．ＳＲ２０００のＥｘｔ−ＴＲＩＢにポリシーを加えること。
６．ＳＲ２０００の現在の内部ピアのすべてにポリシーを送ること。
上記の第一のステップで、ポリシー（生の形式で）がＳＲ２０５５：７８９ ２００３のＥｘｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎに追加される。重複を検知するシーケンス番号がないので、既にＥｘｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎにポリシーが既に存在する可能性がある。第一のステップでは、Ｅｘｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎをスキャンし、重複エントリがないことを確認する。外部ピアから受け取った要素は、このポリシーにとって同一であれば、すべて重複とされる。すべての検知された重複が廃棄される。そうでなければ、以下に示された通り、ポリシーはＥｘｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎに追加される。
Figure 0004536999
広告パスおよびルートパス属性も、Ｅｘｔ−ＴＲＩＢに格納される。第２のステップは、循環的なパスを検知する為に、これらの属性を調べる。それは、リスト（それはルートがループしていることを示す可能性がある）中の現在のＩＴＡＤの存在を探すことである。ループが検知された場合、そのルートはＥｘｔ−ＴＲＩＢから取り除かれる。最短のパスを選択する為に、他のタイプのスキャンを実行することもある。特定のＩＴＡＤへのより短いパスが見つかった場合、より長いエントリの広告パスは、より短いパスへアップデートできる。このアップデートは、内部で処理されるルーティングエントリの数を小さくし、ルーティングポリシーには影響しない。
第３のステップでは、このＳＲのための入力スクリーニングコンフィギュレーションが調べられる。ＩＴＡＤ２０５５のための境界内のポリシースクリーンデータは以下のとおりである：
境界内スクリーン#1
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
許可
部分的着信アドレス： *
ポリシー属性数： 1
第１ポリシー属性
キャリア： External
サービス状態： 有効
時間： 0000-2400
曜日： U-S
コスト: 0.20
QoS: SHQ, G.711
この境界内のポリシースクリーンに対して、受け取られ、格納されたポリシーを処理する際に、好ましくは、下記タスクが実行される。
・部分的着信アドレスのマッチングを実行する。部分的な一致がない場合は、Ｅｘｔ−ＴＲＩＢにポリシーを加えない。
・境界内ポリシーでの許可／拒絶パラメタをチェックする。
・パラメタが拒絶にセットされている場合、Ｅｘｔ−ＴＲＩＢにポリシーを加えない。 ・このポリシーと共に受信される無効でないキャリアが、境界内のスクリーン属性にリストされていない場合、Ｅｘｔ−ＴＲＩＢにポリシーを加えない。
発信アドレスが存在しない場合（もし、外部ピアが、同じように拡張されたＴＲＩＰを使用していない限り、この場合が成り立つ）、ポリシー内の発信アドレスを、境界内のポリシースクリーン内の発信アドレスにセットする。又、発信アドレスが存在しない場合、＊のワイルドカードインジケータをセットする。
・もし、受信ポリシーでまだ実装されていなければ、境界内のポリシーから、有効日付／時間、非活性化日付／時間およびデフォルトの属性に値を入れる。
・もし、受信ポリシーがこれらのパラメタのうちのいくつかを備えている場合、最も限定的な（つまり、最新の活性化日付／時間、その、最も早い非活性化日付／時間、最も高いＱＯＳ、最も限定的な時刻／曜日パラメタおよび最も高いコスト）ものをパラメタに使用する。
境界内のポリシースクリーンに対して、デフォルトセッティング（キャリア属性を含んで）および最も限定的な処理を用いて、この格納されたポリシーが調べられた後、ポリシーはＥｘｔ−ＴＲＩＢに追加される。
Figure 0004536999
これらのポリシーの各々がＥｘｔ−ＴＲＩＢに加えられる時、このＳＲは、次の転送先として置き換えられ、ポリシーの各々は、「アップデート」メッセージによって、注流メカニズムを使用する内部ピアの各々へ転送される。ＳＩＰプロキシサーバが生成したルートクエリを満たすために、このＳＲの上でＴＲＩＰ ＬＳによって使用されるローカルＴＲＩＢは、外部ピアと内部ピアからの処理されたルートを含んでいる。
Figure 0004536999
複数の外部ピアがある場合、上記のように、境界外のスクリーニング基準に基づく外部ポリシーからではない夫々の外部ピアのＡｄｊ−ＴＲＩＢ−Ｏｕｔに、ポリシーが追加される。この例においては、１つの外部のＩＴＡＤだけがあるので、外部のＩＴＡＤ２０５５のポリシー（「発信：＊」、「着信：１」、external.carrier.com）は、ＩＴＡＤ２０５５のＡｄｊ−ＴＲＩＢ−Ｏｕｔに追加されない。
Figure 0004536999
現在のシステムに含まれる可能性のある２つの追加のポリシー変更として、ルートポリシーの取消し、隣接通信エラーポリシーがある。ルートポリシー取消しの変更は、そのルートがサービスから取り除かれるということ以外は、ルートを加えることと同一である。新しいルートの広告のように、集成のプロセスおよびピアのアップデートが同じように生じる。アドミニストレータはいつでもルートを取り消すことができる。
ＴＲＩＰサーバが、ルートを利用不可能と宣言する程長い間、ピアと通信することができず、隣接通信エラーポリシー変更は、ルートを除去する。この状況の結果、この隣接したルータによって管理された、次の転送先サーバを利用するか通過するすべてのルートが除去される。
下記は、ＳＩＰプロキシサーバおよびその機能の詳細な記述である。既に図６の中で示されているように、ＳＩＰプロキシサーバのコンフィギュレーションが行われているかどうか確かめる為に、チェックが実行される。ＳＲが、任意の通信セッションの管理を行うことになると、ＳＩＰプロキシサーバのコンフィギュレーションが行われ、そのＳＩＰプロキシサーバは有効とされる。ＳＩＰプロキシサーバは、業界標準として一般に認められている。
ＳＩＰプロキシサーバはＳＩＰメッセージを受け取り、それらを処理する。発明の好ましい実施形態と関係のある特定の処理は、集めたＴＲＩＢデータベースの「招待」、および「ＢＹＥ」メッセージを処理する為のメカニズムに関する。加えて、一旦、通信セッションが確立された場合に、後続のＲＴＰパケットのフローの制御を行うための方法および装置の詳しい説明が提供される。別の発明性のある特徴は、統計的方法の実装、および他のインテリジェントなルーティングとルート迂回方法である。それらは、この説明の中で列挙される。さらに、下記は、ダウンタイムを最小限にし、スケーラビリティを最大にし、メンテナンス中のルートフラッピングを防ぐために、ＳＩＰプロキシサーバのクラスタコンフィギュレーションを管理する方法について記述する。
図１２Ａおよび図１２Ｂは、ＳＲの内に含まれているＳＩＰプロキシサーバによって使用されるハイレベルの処理ステップを示すフローチャートである。発明の好ましい実施形態によれば、ＳＲは、パラメタ「ｅｎｄ＿ｏｆ＿ｓｔａｒｔｕｐ＿ｇｕａｒｄ＿ｔｉｍｅ」によってプログラム可能な一定時間の間待機する（ブロック２２０２）。好ましくは、一定時間が指定されない場合、６０秒のデフォルトがある。この遅れは、ＴＲＩＰ ＬＳが、まだ受け取られていない他の内部ピアから注流させられているすべてのルートを受け取ることを可能にする。
ブロック２２０４に示されているように、一旦、ＴＲＩＢが受け取られ処理され、ＳＲが所定の時間、待機したならば、ＳＲのＳＩＰプロキシサーバはそのＵＤＰソケットを開きリッスンを開始する。好ましくは、ＳＲが準備できる前に受け取られたリクエストは、サービスが利用不可能であることを示すレスポンスで答える。ＳＲが準備できた後、ＳＲは、ＳＩＰメッセージが到着（２４７）するのを待ち受ける為のリッスンを開始する（ブロック２２０６）。
ＳＩＰメッセージの受け取ってから、受け取られたＳＩＰメッセージのタイプに基づいて、１つの分岐が実行される。メッセージタイプは「招待」（ブロック２２０８）。「ＢＹＥ」（ブロック２２１２）、「登録」（ブロック２２１４）。「ＡＣＫ」（ブロック２２１６）、「キャンセル」（ブロック２２１８）および「オプション」（ブロック２２２２）を含んでいる。ブロック２２２３によって示されているように、「招待」メッセージ以外のメッセージは、標準のＳＩＰに従って処理される。本発明の主な目的のうちの１つは、ＳＩＰ「招待」メッセージを送ることである。「招待」分岐は、図１２Ｂに記載されている。図１２Ｂを参照すれば、次のステップは、ＳＩＰ「招待」メッセージを解析し、ルーティング（ブロック２２３２）のために使用できるコンポーネントのすべてを得ることである。特に、発信アドレスと着信アドレスが抽出される。ルートの選択に用いられる他の情報は、「招待」メッセージのＳＤＰ部分からのデータ、要求されたメディアフローのタイプ、所望の符号づけのタイプ等を含む。
そして、ブロック２２３４によって示されているように、受理可能なルートのリストを見つける為に、ローカルＴＲＩＢがスキャンされる。受理可能なルートは、次の基準を満たすものを含んでいる。即ち、部分的発信アドレスが一致したルート、部分的着信アドレスが一致したルート、時間や曜日のエントリを持つキャリアの少なくとも１つを持つルートとキャリアのいずれかを含むルート、或いはＱＯＳの最小の要求を満たすルートである。この時点で、取得可能なルートがすべて得られている。その後、可能なルートは優先度の順にソートされる。
可能なルートの優先度順のソートは、次の規則のセットに基づく。
１．発信アドレスフィールドの中の、最適または最長の一致を持つルートは、トップへソートされる。この規則によれば、逆の順にドットで区分されたドメイン名とのマッチングを行うアドレス／ＵＲＩマッチングスキームあるいは部分的な電話番号マッチングのいずれかを、最長の一致を得る為に使用される。下記は、このマッチングスキームの例を示す。
電話番号１−６１７−２４６−１２３４からの「招待」が到着し、コンフィギュレーションの行われたポリシーは次のものを含んでいれば、１−６１７−２４は最適で最長の一致と考えられる。
・tel:1
・tel:1-617
・tel: 1-617-24
・tel: 1-617-247
ドメインアドレスについては、最適または最長である一致は、（逆順で）等しいドメインに基いている。
したがって、「招待」が発信側表示、sip:patrick@acmepacket.comを含み、コンフィギュレーションの行われたポリシーは次のものを含んでいる場合、ベースドメイン「com」が等しく、さらに、次に高いアドレス「acmepacket」が等しいので、アドレスsip:patrick@acmepacket.comは、最適と最長である一致と考えられる。
・sip:com
・sip:acme.com
・sip:acmepacket.com
・sip: sales.acmepacket.com
発信アドレスから、次の場合、acme.comは、この発信アドレスをソートする為に使用される。
・1-781-933-6166@acme.com
もし、「招待」メッセージの発信アドレスが、部分的に一致する起点電話番号と、部分的に一致するドメインアドレスの組み合わせを有するならば、好ましくは、ドメインアドレスのマッチングが、ソートのために使用される。
２．同じ発信アドレスを持ったルートの各セット内で、着信アドレスフィールドが最適または最長の一致を持つルートがソートされる。もし、「招待」メッセージの着信アドレスが、部分的に一致する起点電話番号と部分的に一致するドメインアドレスの組み合わせを有している場合、ドメインアドレスのマッチングが、ソートのために使用される。
３．発信アドレスと着信アドレスの同一のフィールド値を持つルート内では、ルートは、最も高いコストから最も低いコストに、コストによってソートされる。
４．同一の発信アドレスと着信アドレスおよびコストを持つルートの各セット内では、次の転送先サーバとしてこのＳＲを持つルートがソートされる。これらはこのＳＲのゲートウェイのうちの１つで終了する、ローカルルートである。ローカルルートを常に最初に選ぶことによって、リクエストをローカルに送らずに、２つのＳＲが、セッションリクエストを投げ合うという、潜在的なピンポンシナリオが回避される。
５．既に「招待」リクエストの処理に関係したＳＲに関連付けられたルートは除去される。これは、ローカルの制約を超えたので既に「招待」を転送したＳＲに、その「招待」が戻されるのを防ぐ。そうでなければ、第２のピンポンシナリオが、生じることがある。即ち、最適の選択のＳＲが過重負担となり、そうとは知らない別のＳＲへ「招待」を転送し、その結果、それを送り返したりする。
そして、優先の順にソートされた可能なルートのリストがある。このリスト中の各ルートは有効なルート（ブロック２２３６）である。しかし、いくらかは、他のものより、質あるいはコストの異なるレベルを持つものもある。例えば、キャリアＭＣＩを使用し、sr4.itad.comで処理され、１−７８１−９３３−６１６６（発信アドレス）から開始され、１−６１７−５５５−１２１２（着信アドレス）終了するセッションのルート捜索から、次のような可能なルートのリストが考えられる。
FROM: 1-781 TO: 1 NEXT HOP: SR4.ITAD. MCI/U-S/0000-2400/COM$0.02/SHQ-G711
FROM: 1-78 TO: 1-617 NEXT HOP: SR2.ITAD. MCI/U-S/0000-2400/COM$0.01/SHQ-G711
FROM: 1-78 TO: 1-617 NEXT HOP: SR4.ITAD. MCI/U-S/0000-2400/COM$0.02/SHQ-G711
FROM: 1-78 TO: 1-617 NEXT HOP: SR3.ITAD. MCI/U-S/0000-2400/COM$0.02/SHQ-G729
FROM: 1-78 TO: 1 NEXT HOP: SR4.ITAD. MCI/U-S/0000-2400/COM$0.02/SHQ-G711
FROM: 1 TO: 1-6 NEXT HOP: SR4.ITAD. MCI/U-S/0000-2400/COM$0.02/SHQ-G711
FROM: 1 TO: 1 NEXT HOP: SR4.ITAD. MCI/U-S/0000-2400/COM$0.02/SHQ-G711
上記のリストによれば、終点で部分的に一致すると共に、発信アドレス（つまり起点番号）に最適に一致したルートは、トップへソートされている。上記のテーブル中の第２と第３のエントリは同じ発信アドレスと着信アドレスを持つが、異なる次の転送先サーバを持つことに注意されたい。ローカルの次の転送先サーバはリストのトップへソートされる。さらに、もし、このセッション「招待」リクエストが、以前にsr3.itad.comにあったならば、テーブル中の第３のエントリが廃棄されていたと考えられる。
上記ソートプロセスの後に利用可能なルートがない場合、セッション「招待」は、利用可能なルートがないという通信内容を伴って発信側に返される。図１２Ｂは、ブロック２２４２および２２４４としてこのシナリオを示している。利用可能なルートがスキャンされた後、１つ以上のルートが残されている場合、プロセスはステップ２２３８に進められる。
ブロック２２３８によって示されているように、最適のルートから始めて（ソートされたオーダーで）、各ルートは一度に１回づつ調べられる。各ルートは、そのルートがローカルかどうかを決める為に分析される（ブロック２２４２）。それは、このＳＲが、直接ＳＩＰエージェントを管理していることを意味する。次の転送先サーバが、その中にＳＩＰエージェントグループを持っていれば、ルートはローカルであり、ブロック２２４６で示されているように制御が移る。そうでなければ、ルートはリモートであり、ブロック２２４４によって示されているように制御が移る。
例えば、ハントストラテジーが使用されており、そこに、ＳＩＰエージェントグループの中に複数のＳＩＰエージェントがあれば、グループ中の最初のＳＩＰエージェントは、グループ中の第２のＳＩＰエージェントを探す前に、その制約を完全に適用すべきである。制約４１６（図３Ｂ）は、物理的制限に必ずしも結び付けられない勧告的制限であるが、ネットワーク立案ベースの、コンフィギュレーションに結び付けられている。例えば、一方通行の境界外の呼び出しを受け入れ可能な設定を持つ２４のポートを備えたゲートウェイは、２４という値を持つ勧告的制限を有しており、２方向の呼び出しを受け入れ可能な設定を持つ同じゲートウェイは、１２という値を持つ勧告的制限を有している。この制約は、このＳＩＰエージェントのサポート可能なセッションの整数値である。
特定のＳＩＰエージェントのセッションの数を決定する為に、ＳＲは、どれだけのセッションが特定のＳＩＰエージェントに対して設定されるかに関する統計値を保持しなければならない。したがって、データテーブルが、各ＳＲの内に保持される必要がある。
Figure 0004536999
表２９に示すテーブル６は、特定のＳＩＰエージェントのキャパシティーに関する統計値を示す。特定のＳＩＰエージェントをスキップする為に、勧告的制限が使用されることに注意されたい。したがって、制約のいずれかを超えた場合、その制約を超えなくなるまで、そのＳＩＰエージェントは考慮されない。
起こりうる制約は、これまでにも特定しているが、テーブル６の統計値の組み合わせも含まれている。もし、制約が形成されておらず、ＳＩＰエージェントグループ中の最初のＳＩＰエージェントが、利用可能なリソースがないという通信を返す場合、そのＳＩＰエージェントグループは一定期間の間、無効になる。この期間はプログラム可能で、上記テーブルの中で再開時間として示されている。ルートが選択されるかどうか決める為に統計値（上記のテーブル中の）を調査する段階は、図１２Ｂの中のブロック２２４８として示されている。
図１３Ａおよび図１３Ｂは、発明の好ましい実施形態による、ルートを転送するＳＩＰエージェントのグループ内の特定のＳＩＰエージェントを決める為のアルゴリズムを示すフローチャートである。ブロック２３０２によって示されているように、現在の日付および時間が得られる。現在の時間は２つの別個の用途のために使用される。現在の時間の第１の用途は、特定のＳＩＰエージェントの包含か排除に関する情報用のセッションルータデータテーブル中の再開時間の欄と、現在の時間を比較することである。現在の時間の第２の用途は、そのＳＩＰエージェントが選ばれた後、特定のＳＩＰエージェントのためのセッションルータデータテーブル中の最後の使用の欄に日付を入力することである。ブロック２３０４によって示されているように、次のステップは、ＳＩＰエージェントグループを、分解して、ＳＩＰエージェントの完全に解決されたリストを得ることである。各グループは追加のグループあるいはＳＩＰエージェントを含んでいる。好ましくは、ＳＩＰエージェントのこのリストは、ＳＩＰエージェントグループのエージェントリスト内で、ＳＩＰエージェントが出現する順番で、保持される。いくつかのグループの中で、ＳＩＰエージェントの参照がある場合、それは一度だけリストされる。
例：
Group 1: Hunt
1. Gateway 1
2. Gateway 2
3. Gateway 3
Group 2: Proportional Distribution
1. Gateway 1
2. Gateway 2
Group 3: Least Busy
1. Group 1
2. Group 2
上記の通りリストされた理論的なグループでは、グループ１がハントストラテジーを使用し、３つのゲートウェイを備えており、グループ２は比例分配ストラテジー（最も古いものの利用）を使用し、２つのゲートウェイを備えており、グループ３は最暇ストラテジーを使用し、２つのグループを含んでいる。完全にグループ３を解決する場合、下記は、そのＳＩＰエージェントグループの分解を示す。
Group 3: Least Busy
1. Gateway 1
2. Gateway 2
3. Gateway 3
上記の例において、ゲートウェイ１およびゲートウェイ２は繰り返されない。どれほど多くのグループのネスティングが生じても、当初のＳＩＰエージェントグループストラテジーだけが使用されることに注意されたい これにより、ブロック２３０４で実行されたプロセスの終わりに、ＳＩＰエージェントグループの完全なリストがある（夫々のグループが、それを含むＳＩＰエージェントグループの中で参照される順番でリストされる）。その後、ブロック２３０６によって示されているように、ＳＩＰエージェントのリストが使用される。順番付けされたリスト中の各ＳＩＰエージェントのために、コンフィギュレーションの行われた制約の確認がなされる（ブロック２３０８）。この確認は、次の可能な制約を評価することを含んでいる。即ち、再開時間値が、現在の時間の後あるいは等しいことと、ＳＩＰエージェントのバーストレートは、確立された限界を超えるか等しいことと、ＳＩＰエージェントの保持されたセッションリクエストレートは限界を超えるか等しいことと、セッションカウントの合計は、確立された限界を超えるか等しいことである。各ＳＩＰエージェントのために適用される他のタイプの制約も存在することに注意されたい。例えば、観察される最大ジッタ、観察される最大待ち時間、およびパケット往復時間を、各セッションセットアップで確認されるべき制約としてセットしてもよい。
可能な制約のプール中のいずれかの制約を超えた場合、現在のＳＩＰエージェントは、ＳＩＰエージェントのリストから除去される（ブロック２３１２）。ＳＩＰエージェントが削除された後、リスト中でこれ以上のＳＩＰエージェントがなくなるまで、ブロック２３０６の機能は、次のＳＩＰエージェントを調べる為に繰り返される。制約を超えない場合、ＳＩＰエージェントはリストに残る。また、プロセスは次のＳＩＰエージェント（ブロック２３１４）を見続ける。すべてのＳＩＰエージェントについて、制約の評価が行われた時、その結果は、確立している制約のうちのどれも超えていないＳＩＰエージェントのリストとなる。その後、ブロック２３１６によって示されているように、チェックを行って、制約チェックをパスした少なくとも１つのＳＩＰエージェントがあるかどうか決める。ＳＩＰエージェントがみな制約テストに失敗したならば、制御がブロック２３１８へ移る。そこでは、ルートが利用可能ではないことを示す。ブロック２３１８は、図１２Ｂの中のブロック２２５２に関係する。このシナリオの次の処理は、ルートの除去と、次の可能なルートの使用である（ブロック２２５２、図１２Ｂ）。１つのＳＩＰエージェントがリストに残れば、制御がストラテジーのタイプに基づいて適所に移動される（ブロック２３２２）。ハントストラテジーを使用する場合、ブロック２３２４の中で示されているように、第１のＳＩＰエージェントが選ばれる。ラウンドロビンストラテジーを使用する場合、使用頻度が最低か最も古い「最後の使用時間」を持ったＳＩＰエージェントが選ばれる（ブロック２３２６）。比例する分配ストラテジーについては、各ＳＩＰエージェントは、最大の同時のセッションの為のコンフィギュレーションの行われた制約を備えている。同時セッションは、最大の累積的なセッションを得る為に蓄積される（ブロック２３２８）。
例：
Gateway 1:10-session limit; Cumulative Sessions: 10
Gateway 2: 20-session limit; Cumulative Sessions: 30
Gateway 3: 15-session limit; Cumulative Sessions: 45
上記の例によれば、リスト中のＳＩＰエージェントが、すべて累積リストに加えられるまで、上記プロセスは継続する。二度以上現われるＳＩＰエージェントは、現われるだけカウントされる。最大の累積的なセッション数は、好ましくは、リスト中の最後のＳＩＰエージェントに属する累積的なセッションの数である。１と最大の累積セッション数の間のランダムな数が選ばれる。上記例において、これは、同程度の可能性のある、１から４５の中の１つのランダムな数である。１から１０については、ゲートウェイ１が選ばれ、１１から３０については、ゲートウェイ２が選ばれ、３１から４５については、ゲートウェイ３が選ばれる。
上記プロセスは、コンフィギュレーションの行われたセッションの数に基づいて、比例分配を行う。これは、各ＳＩＰエージェントのポートの数に比例する、セッションリクエストの分配を可能とする。ブロック２３３２は、最暇ストラテジーを示し、そこでは、許可されたセッションの合計に対するアクティブなセッションの比率が最低であるＳＩＰエージェントを、リスト中のＳＩＰエージェントのすべてから調べられる。好ましくは、この比率は、境界内と境界外のセッションを加え、その結果を許可されたセッションの合計で割ることで、計算される。
ブロック２３３４は、最低持続レートストラテジーを示す。このストラテジーでは、確立されているセッションに対して、最低持続レートのＳＩＰエージェントを、リスト中のＳＩＰエージェントのすべてから調べられる。ＳＩＰエージェントは、ストラテジーに基づいて使用する為に選ばれているので、ブロック２３３６によって示されているように、ＳＩＰエージェントの中の統計値を更新して、試みのために選ばれているＳＩＰエージェントに反映させる。より詳しくは、例えば、統計値は以下のとおりである。
・再開するべき時間：変更はない。
・最後の使用：現在の時間へのセット
・境界外のセッションの番号：インクリメントされた。
・最後５分間内での現在の持続レート：スライディングウィンドウに加える。
・最後の３０秒間内でのバースト ・レート：スライディングウィンドウに加える。
・リソース利用不可能と検知された最後の日時：変更はない。
・利用可能なリソースが検知しなかった時、セッションズの合計変更はない。
ブロック２３３８によって示されているように、統計値を更新した後、制御は、図１２Ｂの処理へ戻され、そこで利用可能なルートが選択される。特に、ブロック２３３８は、図１２Ｂのブロック２２５４に関連し、そこで利用可能なルートが返される。その結果、ローカルのＳＩＰエージェントへのルートが生成される（ブロック２２５４（図１２Ｂ））。ＳＩＰプロキシサーバは、返されたＳＩＰエージェントに関連したＳＩＰプロキシサーバへ、「招待」メッセージを転送する。直線パス上のＳＩＰプロキシへのパス上の複数のＳＩＰエージェント経由で、着信側ＳＩＰエージェントへ、ＩＮＶＩＴＥメッセージが送信され得る。
「ＢＹＥ」メッセージが以前に設立されたセッションのために受け取られる場合、アクティブなセッションのカウンターがデクリメントされる。ルート記録機能によって、「招待」メッセージによって得られた同じ直線パスによって、「ＢＹＥ」メッセージが返されることが保証される。
要約すれば、上記の開示により、順番に、複数のルートを選択し処理する機能が教示される。そこでは、様々な配布ストラテジーを使用して、一組の（さもなければ同等の）ＳＩＰエージェントから選択が行われる。このプロセスは、その後のＲＴＰフローのパスの管理に引き続く。
（メディアフロールーティング）
次に、多重ドメインネットワークを通るパスの選択を説明する。あるしきい値（それは、様々なＩＰネットワーク間の高品質境界を作る為に使用される）によって、リアルタイムパケットフローをガイドすることが可能である。このメカニズムなしでは、パケットが、ネットワークが許すどの方向へでも向かってしまう。パケットがとる実際のルートを制御する為のいくつかの技術がある。ここで使用される最も有望なメカニズムは、多重プロトコルラベルスイッチング（ＭＰＬＳ）である。
ＭＰＬＳが遭遇した問題のうちの１つは、ネットワーク進入ポイントで、通常、前方の同値クラス（ＦＥＣ）に結び付けられるということである。業界で知られているように、前方の同値クラス（ＦＥＣ）とは、その輸送のための同じ条件を共有するパケットのグループを表現するものである。そのようなグループ中のパケットはすべて、終点に向かう途中、同じ処理を受ける。従来のＩＰフォワーディングに対立するものとして、ＭＰＬＳでは、パケットがネットワークに入る際に、特定のＦＥＣへの特定のパケットの割り当ては１度だけ行われる。
現在のシステムにサポートされた通信装置の多くは、他の目的のために使用される。例えば、ウェブを「サーフィンする」一方で、リアルタイムセッション指向のコミュニケーションを行うために、コンピュータが使用される。残念ながら、ＭＰＬＳタグを、どのようなケースを適用すべきかが明らかではない場合がある。したがって、パケットにタグを付けるアプリケーション特有の性質は、現在のシステムの多くの利点のうちの１つといえる。さらに、このシステムは、非ＭＰＬＳベースのネットワークのためにも解決策を示す。
ＲＴＰフローが、どのように管理可能かを理解する為には、ＳＩＰシグナリングによるセッションリクエストベースに基づくネットワークアドレストランスレーションを実行する機能も理解すべきである。図１４は、ＳＲの中のメディアルーティングを通じて、ＲＴＰフローがどのように管理されるかを示すブロックダイヤグラムである。メディアルーティングでは、ＳＩＰシグナリングによるセッションリクエストベースの、ネットワークアドレストランスレーション（ＮＡＴ）およびポートアドレストランスレーション（ＰＡＴ）と同等の機能が提供される。各ＳＲを通過する「ｅｎｄ−ｔｏ−ｅｎｄ」のコミュニケーションがある。使用するＳＲおよびゲートウェイの選択は、上記の通りに実行される。
個別の高品質ネットワークを介してセッションのメディアフローのルーティングを行う為に、ＳＲは２つの別個のネットワークに接続されている。１つのネットワークはＳＩＰプロキシサーバと通信し、別のネットワークインターフェイスが高品質トランスポートネットワークに接続されている。ＳＲの内では、メディアフローのために使用される１組のＴＣＰ／ＩＰポートが形成される。好ましくは、各ネットワーク毎に１組のポートがある。これらのポートは、ＳＩＰプロキシサーバによって開始されたセッションのＲＴＰメディアフローの送受信のために割り付けられている。
図１４は、それぞれのＳＲ２４０６、２４０８を介して、高品質トランスポートネットワーク経由で流れる、第１のエンドポイント２４０２と第２のエンドポイント２４０４（つまり、ＳＩＰ電話）の間のメディアフローを示す。好ましくは、ＳＩＰプロキシサーバが、各ＳＲ２４０６、２４０８の中に存在する。ラベルＡ、Ｂ、Ｃ、Ｄ、ＥおよびＦは、ＲＴＰパケットの送受信に使われるＲＴＰポートを示す。これらのポートはＩＰアドレスとポートの番号によって定義されるＴＣＰ／ＩＰポートである。エンドポイントが「招待」メッセージを送る場合、「招待」は起点エンドポイント２４０２のＲＴＰポートを含むＳＤＰ本体を含んでいる。終点エンドポイントからの「招待」に対するレスポンスは、ＳＤＰ本体（それは終点ＲＴＰポートＦを指定する）を含む。
もしエンドポイントが直接通信すれば、第１のエンドポイント２４０２と第２のエンドポイント２４０４の間に１つのＲＴＰフローがある。パケットは、好ましくは、正常なＩＰルーティングによって（例えば公開のインターネットを介して）、エンドポイント間に流れる。メディアルーティングが含まれる場合、３つのＲＴＰフローがある。即ち、１）ＡとＢの間、２）ＣとＤの間、３）そしてＥとＦの間である。第１のエンドポイント２４０２でセッションが開始したと仮定すると、ＳＩＰ「招待」は、ＡとしてＲＴＰポートを指定する。第１のＳＲ２４０６のＳＩＰプロキシサーバが「招待」を処理する場合、それはメディアフローのために、ＲＴＰポートＢおよびＣを、第１のＳＲ２４０６に割り付ける。第１のＳＲ２４０６のＳＩＰプロキシサーバから、第２のＳＲ２４０８のＳＩＰプロキシサーバへ転送される「招待」中のＲＴＰポートは、Ｃにセットされる。第２のＳＲ２４０８のＳＩＰプロキシサーバが「招待」リクエストを処理する場合、ＲＴＰポートＤおよびＥは、第２のＳＲ２４０８に割り付けられる。第２のＳＲ２４０８のＳＩＰプロキシサーバから送られ、第２のエンドポイント２４０４に到着する「招待」は、ＲＴＰポートをＥとして指定する。第２のエンドポイント２４０４は、「招待」メッセージへのレスポンスの中で、ＦのＲＴＰポートを指定する。そして、第２のＳＲ２４０８のＳＩＰプロキシサーバは、第１のＳＲ２４０６のＳＩＰプロキシサーバに、レスポンスを返し、ＲＴＰポートをＤに変更する。その後、第１のＳＲ２４０６のＳＩＰプロキシサーバは、第１のエンドポイント２４０２、レスポンスを渡し、ＲＴＰポートをＢに変更する。第１のエンドポイント２４０２から見れば、フローはＡとＢの間にある。しかしながら、第２のエンドポイント２４０４から見れば、フローはＥとＦの間にある。したがって、エンドポイント２４０２、２４０４は、ＳＲが介在することに気づきない。
ＳＲがＲＴＰフローをモニターし、待ち時間およびジッタを測定することに注意されたい。さらに、それらは、ＲＴＰフローがいつ終わるか検知し、その結果、ＳＩＰプロキシサーバでは、「ＢＹＥ」メッセージを送信する。
（クラスタリング）
データベースサーバの採用によって、複数のＳＲは、コンフィギュレーションとポリシーのデータを共有することができる。ＳＲは、データベースサーバの中のコンフィギュレーションとポリシーデータの特定のセットを「予約」することができる。ネットワークの冗長性、信頼度およびスケーラビリティは、同じローカルポリシーを共有するＳＲをクラスタに分けることにより、達成することができる。したがって、複数のＳＲが、一組のＳＩＰエージェント（つまりゲートウェイ）の為に動作している時、単一のＳＲの損失は、ネットワークのルーティング能力に影響しない。
図１５は、ＳＲＡ、Ｂ、Ｃのみを含むネットワークを示すブロックダイヤグラムである。ＳＲＡはゲートウェイＡＧ１およびＡＧ２に接続される。ＳＲＢはゲートウェイＢＧに接続される。そし、ＳＲＣはゲートウェイＣＧ１およびＣＧ２に接続される。図１６はルータＡ、Ｂ、Ｃのクラスタを使用した、同じネットワークをブロックダイヤグラムである。図１６では、クラスタＡがゲートウェイＡＧ１およびＡＧ２に接続され、クラスタＢはゲートウェイＢＧに接続され、クラスタＣはゲートウェイＣＧ１およびＣＧ２に接続されている。つまり、これらの例では、図１５が、Ａ、ＢおよびＣの３つのＳＲを含み、図１６は、夫々、３つのＳＲからなる３つのクラスタＡ、ＢおよびＣを含む。しかしながら、ネットワークやクラスタに存在するＳＲの数に制限がないことは理解すべきである。図１５および図１６は、単に例として設けられている。
好ましくは、クラスタ中のＳＲは、クラスタ用のポリシーが格納されるデータベースサーバ（図１６では示されていない）を共有する。クラスタ中のＳＲは、基本的に同一であるが、ＳＩＰおよびＴＲＩＰフレームワークの内の独立したＳＲとして機能する。図１６によれば、３つのＳＲはすべて、他のＴＲＩＰピアである。しかしながら、クラスタ中に４つ以上のＳＲがあれば、クラスタを通過するルート広告の為に、少なくとも２つのパスがあり冗長性を確保するように、十分なＴＲＩＰ接続性が必要となる。各クラスタ間に２つのＴＲＩＰ接続があり、ルート広告を内部ＴＲＩＰ ＬＳに注流させるように２つのパスがあることに注意されたい。
好ましくは、クラスタ中のゲートウェイおよびＳＲはゲートウェイは、それらゲートウェイが、クラスタのために単一のドメインアドレスを持つように、ＤＮＳラウンドロビンと同様の方法を使用するように、セットアップされる。ＳＩＰプロキシサーバがラウンドロビンリクエストを受け取る場合、セッションの将来のリクエストが適切なＳＲに行くように、その特定のアドレスによってゲートウェイへ応答する。
本発明の上記実施形態、特に、任意の「好ましい」実施形態は、インプリメンテーションの単に可能な例であり、単に発明の原理についての明瞭な理解のために記載されている。多くの変形例および修正例が、発明の精神および原理から基本的に外れずに、発明の上記の実施形態に対してなし得る。そのような修正および変化はすべて、この開示の範囲および本発明に含まれ、かつ以下のクレームによって保護されるものである。
本発明は図面に参照すれば、一層よく理解することができる。図面の要素は、大きさは必ずしも重要でなく、本発明の原理を明瞭に示すことに重点が置かれている。さらに、同様の参照番号がいくつかの図面の中で対応する要素を示す為に用いられている。
図１は、発明の好ましい実施形態による複数のドメインを含む通信ネットワークを示すブロックダイヤグラムである。 図２は、ＳＩＰプロトコルを介して行われる対話を示すブロックダイヤグラムである。 図３Ａは、図１のネットワーク内にあるセッションルータ上に格納されたポリシーを示すデータマップのブロックダイヤグラムである。 図３Ｂは、図３Ａに示されたデータマップの続きを示すブロックダイヤグラムである。 図４は、図１のネットワーク内にあるセッションルータ装置の構造を示すブロックダイヤグラムである。 図５は、図１および図４に示されたセッションルータのローカルメモリ内に常駐するソフトウェアシステム、又はプロトコルを示すブロックダイヤグラムである。 図６は、図１および図４のセッションルータの動作開始の際に、実行される動作を示すフローチャートである。 図７は、図１および図４のセッションルータによって使用されるポリシースクリーンを示すブロックダイヤグラムである。 図８は、図１および図４のセッションルータによって実行されるＴＲＩＰ決定プロセスによって定義されたロジックを示すブロックダイヤグラムである。 図９Ａは、図１および図４のセッションルータから送信されるか、あるいはそのルータに受け取られるＴＲＩＰ「アップデート」メッセージの主なコンポーネントを示すブロックダイヤグラムである。 図９Ｂは、図９Ａの続きであるブロックダイヤグラムである。 図１０は、図１および図４に示されているような、セッションルータを含むＩＴＡＤトポロジーの例を示すブロックダイヤグラムである。 図１１は、与えられたポリシーが外部に広告されるかどうか決める為に、最適のマッチングスクリーンを使用し、図１および図４のセッションルータによって実行されるプロセスを示すフローチャートである。 図１２Ａは、ＳＩＰメッセージを解析する為に、ＳＩＰプロキシによって行われる処理ステップを示すフローチャートである。 図１２Ｂは、図１１Ａの続きを示すフローチャートである。 図１３Ａは、ルートを転送するＳＩＰエージェントのグループ内の特定のＳＩＰエージェントを決める為に行われるステップを示すフローチャートである。 図１３Ｂは、図１３Ａの続きを示すフローチャートである。 図１４は、図１および図４のＳＲの中のメディアルーティングを通じて、ＲＴＰフローがどのように管理されるかを示すブロックダイヤグラムである。 図１５は、図１および図４に示されているような、セッションルータを含むネットワークを示すブロックダイヤグラムである。 図１６は、図１および図４に示されているような、ルータのクラスタを含むネットワークを示すブロックダイヤグラムである。

Claims (15)

  1. 複数のネットワークを流れるリアルタイムトランスポートプロトコルを制御するシステムにおいて、
    第１のコンピュータは第２のコンピュータに接続され、
    前記第１のコンピュータは、
    送受信機と、
    前記第１のコンピュータにおいて記憶され、前記第１のコンピュータによって実行される機能を定義するソフトウェアと、
    前記第２のコンピュータから、前記第１のコンピュータによってテレフォニールーティングインターネットプロトコル（ＴＲＩＰ）のアップデートメッセージにおいて受信したルート情報において境界内のスクリーンを実行して、前記受信したルート情報が破棄されるべきかを決定し、
    前記ルート情報が破棄されない場合、受信しスクリーニングされた前記ルート情報を、前記第１のコンピュータで定義されたローカルポリシーと比較し、
    受信しスクリーニングされたルート情報に含まれる目的地アドレスが、他のＴＲＩＰのアップデートメッセージで受信された他のルートに含まれる目的地アドレスに一致する場合、ローカルＴＲＩＢが同じ前記目的地への他のルートを含むように、ローカルＴＲＩＢに前記ルート情報を保存し、
    発信アドレス及び着信アドレスを含むＳＩＰ招待メッセージを受信し、
    前記ＳＩＰ招待メッセージの受信に対応して、前記ローカルＴＲＩＢのルートをスキャンして、前記ＳＩＰ招待メッセージで特定される前記目的地への受け入れ可能なルートであって、前記ＳＩＰ招待メッセージで特定される前記目的地と部分的に一致する着信アドレスを有するルートのセットを検索する
    ステップを前記ソフトウェアによって実行するプロセッサ
    を備えることを特徴とするシステム。
  2. 部分的に一致するルートのセットが検索されると、境界内のポリシースクリーンのデフォルトの発信アドレスを、受信しスクリーニングされたルート情報の着信アドレスに適用することを特徴とする請求項１に記載のシステム。
  3. 前記ＴＲＩＰのアップデートメッセージのルート情報は、キャリア、時刻、曜日、ジッタ及びエンコーディングスキームのキャリア属性のうちの少なくとも一つで関連づけられるキャリアフィールドを含み、前記受け入れ可能なルートのそれぞれは、前記ＳＩＰ招待メッセージで特定されるＱｏＳ基準に一致する待ち時間、ジッタ及びエンコーディングスキームの属性を備えることを特徴とする請求項１に記載のシステム。
  4. 前記受け入れ可能なルートのそれぞれは、前記ＳＩＰ招待メッセージで特定される目的地と一致する発信アドレスを有することを特徴とする請求項１に記載のシステム。
  5. 前記発信アドレスにおいて最長の一致を持つ受け入れ可能なルートを、トップへソートするステップを前記ソフトウェアによって更に実行することを特徴とする請求項１に記載のシステム。
  6. 同じ発信アドレスの値を持ったルートの各セットの中で、前記着信アドレスにおいて最長の一致を持つ受け入れ可能なルートを、トップへソートするステップを前記ソフトウェアによって更に実行することを特徴とする請求項５に記載のシステム。
  7. 同じ発信アドレス及び着信アドレスを持ったルートの各セットの中で、コストによって、受け入れ可能なルートをソートするステップを前記ソフトウェアによって更に実行することを特徴とする請求項６に記載のシステム。
  8. 複数のネットワークを流れるリアルタイムトランスポートプロトコルを制御する方法において、
    第１のエンドポイントから第２のエンドポイントへのルートに関する情報を受信するステップと、
    テレフォニールーティングインターネットプロトコル（ＴＲＩＰ）のアップデートメッセージにおいて受信したルート情報において、境界内のスクリーンを実行し、前記受信したルート情報を破棄するかを決定するステップと、
    前記ルート情報が破棄されなかった場合、受信しスクリーンされた前記ルート情報をローカルポリシーと比較するステップと、
    受信しスクリーニングされたルート情報に含まれる目的地アドレスが、他のＴＲＩＰのアップデートメッセージで受信された他のルートに含まれる目的地アドレスに一致する場合、ローカルＴＲＩＢが同じ前記目的地への他のルートを含むように、ローカルＴＲＩＢに前記ルート情報を保存するステップと、
    発信アドレス及び着信アドレスを含むＳＩＰ招待メッセージを受信するステップと、
    前記ＳＩＰ招待メッセージの受信に対応して、前記ローカルＴＲＩＢのルートをスキャンして、前記ＳＩＰ招待メッセージで特定される前記目的地への受け入れ可能なルートであって、前記ＳＩＰ招待メッセージで特定される前記目的地と部分的に一致する着信アドレスを有するルートのセットを検索するステップと、
    部分的に一致するルートのセットが検索されると、境界内のポリシースクリーンのデフォルトの発信アドレスを、受信しスクリーニングされたルート情報の着信アドレスに適用するステップと、
    前記ローカルポリシーは、起点フィールドを備え、
    前記受信したルート情報が起点属性を備えている場合、前記ローカルポリシーの前記起点フィールドと、前記受信したルート情報によって備えられた前記起点属性とを比較して、前記起点属性の少なくとも一部が前記起点フィールドに一致する場合、前記ローカルポリシーを利用するステップ
    を備えることを特徴とする方法。
  9. 前記ルートは、Ｅ．１６４形式ナンバー、エンドポイントのインターネット形式アドレス、ＳＩＰ電話アドレス及び非ＳＩＰ電話アドレスからなるグループから選択されるレンジであることを特徴とする請求項８に記載の方法。
  10. 前記起点属性及び前記起点フィールドの形式は、Ｅ．１６４形式アドレス、インターネット形式アドレス、ＳＩＰ電話アドレス及び非ＳＩＰ電話アドレスのグループから選択されることを特徴とする請求項８に記載の方法。
  11. 前記終点属性及び前記終点フィールドの形式は、Ｅ．１６４形式アドレス、インターネット形式アドレス、ＳＩＰ電話アドレス及び非ＳＩＰ電話アドレスのグループから選択されることを特徴とする請求項８に記載の方法。
  12. 前記ローカルポリシーは、適用されるルート情報からキャリアの数を識別するキャリアフィールドを備えることを特徴とする請求項８に記載の方法。
  13. 前記受信したルート情報によって備えられたキャリア属性が前記キャリアフィールドによって識別されたキャリアの少なくとも一つに一致しない場合、前記受信したルート情報を破棄するステップを更に備えることを特徴とする請求項１２に記載の方法。
  14. 前記ローカルポリシーは、利用するルートに関連づけられたサービス品質（ＱｏＳ）の適用レンジを識別するＱｏＳフィールドを備えることを特徴とする請求項８に記載の方法。
  15. 前記受信したルート情報によって備えられたＱｏＳ属性が前記ＱｏＳフィールドによって識別されたＱｏＳコストの適用レンジ内でない場合、前記受信したルート情報を破棄するステップを更に備えることを特徴とする請求項１４に記載の方法。
JP2002550693A 2000-12-11 2001-12-11 スクリーニングによって、複数のネットワークを流れるリアルタイムトランスポートプロトコルの制御を支援するシステム及び方法 Expired - Lifetime JP4536999B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US25484000P 2000-12-11 2000-12-11
US09/844,204 US7072303B2 (en) 2000-12-11 2001-04-27 System and method for assisting in controlling real-time transport protocol flow through multiple networks
PCT/US2001/047992 WO2002049316A2 (en) 2000-12-11 2001-12-11 System and method for assisting in controlling real-time transport protocol flow through multiple networks

Publications (2)

Publication Number Publication Date
JP2004538671A JP2004538671A (ja) 2004-12-24
JP4536999B2 true JP4536999B2 (ja) 2010-09-01

Family

ID=26944266

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002550693A Expired - Lifetime JP4536999B2 (ja) 2000-12-11 2001-12-11 スクリーニングによって、複数のネットワークを流れるリアルタイムトランスポートプロトコルの制御を支援するシステム及び方法

Country Status (4)

Country Link
US (3) US7072303B2 (ja)
EP (1) EP1342349A2 (ja)
JP (1) JP4536999B2 (ja)
WO (1) WO2002049316A2 (ja)

Families Citing this family (112)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2441203T3 (es) * 1999-06-08 2014-02-03 The Trustees Of Columbia University In The City Of New York Aparato y sistema de telefonía de red para telefonía por inter/intranet
US7111163B1 (en) 2000-07-10 2006-09-19 Alterwan, Inc. Wide area network using internet with quality of service
US7072303B2 (en) * 2000-12-11 2006-07-04 Acme Packet, Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks
US7002973B2 (en) * 2000-12-11 2006-02-21 Acme Packet Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks via use of a cluster of session routers
US7133923B2 (en) * 2000-12-11 2006-11-07 Acme Packet, Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks via screening
US7028092B2 (en) 2000-12-11 2006-04-11 Acme Packet, Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks via media flow routing
WO2002091692A1 (en) * 2001-04-13 2002-11-14 Girard Gregory D Ditributed edge switching system for voice-over-packet multiservice network
US8385342B2 (en) * 2001-05-31 2013-02-26 Fujitsu Limited System and method of virtual private network route target filtering
US7031311B2 (en) * 2001-07-23 2006-04-18 Acme Packet, Inc. System and method for providing rapid rerouting of real-time multi-media flows
US7362707B2 (en) * 2001-07-23 2008-04-22 Acme Packet, Inc. System and method for determining flow quality statistics for real-time transport protocol data flows
DE10147148A1 (de) * 2001-09-25 2003-04-24 Siemens Ag Netzübergangseinrichtung und Kommunikationssystem für Echtzeitkommunikationsverbindungen
US7315541B1 (en) * 2002-04-03 2008-01-01 Cisco Technology, Inc. Methods and apparatus for routing a content request
US7209435B1 (en) * 2002-04-16 2007-04-24 Foundry Networks, Inc. System and method for providing network route redundancy across Layer 2 devices
US7151781B2 (en) * 2002-07-19 2006-12-19 Acme Packet, Inc. System and method for providing session admission control
US8462668B2 (en) 2002-10-01 2013-06-11 Foundry Networks, Llc System and method for implementation of layer 2 redundancy protocols across multiple networks
US7320010B2 (en) * 2002-11-18 2008-01-15 Innopath Software, Inc. Controlling updates of electronic files
AU2002351629A1 (en) * 2002-11-27 2004-06-18 Research In Motion Limited Data transfer from a host server via a tunnel server to a wireless device, and associating a temporary ipv6 address with a temporary ipv4 address for communicating in an ipv4 wireless network with the device
DE10324470A1 (de) * 2003-05-30 2005-03-10 Deutsche Telekom Ag Verfahren und Vorrichtung zum Steuern von Datenverbindungen in einem Datennetz mit einer Vielzahl von Datennetzknoten
US7643442B1 (en) * 2003-06-30 2010-01-05 Cisco Systems, Inc. Dynamic QoS configuration based on transparent processing of session initiation messages
US7359393B1 (en) * 2003-08-11 2008-04-15 Cisco Technology, Inc. Method and apparatus for border gateway protocol convergence using update groups
US7417981B2 (en) * 2003-10-15 2008-08-26 Vonage Holdings Corp. Method and apparatus for enhanced Internet Telephony
GB0326160D0 (en) * 2003-11-08 2003-12-17 Marconi Comm Ltd Call set-up systems
US8180845B2 (en) * 2003-12-17 2012-05-15 Sap Ag Remote debugging of software
US7860115B1 (en) * 2003-12-18 2010-12-28 Cisco Technology, Inc. Withdrawing multiple advertised routes based on a single tag which may be of particular use in border gateway protocol
KR100590882B1 (ko) * 2004-01-30 2006-06-19 삼성전자주식회사 라우터의 타이머 설정 방법 및 그 장치
FR2870415B1 (fr) * 2004-05-14 2006-09-08 Alcatel Sa Routeur inter-domaines a module de determination d'agregation de routes
US7881281B1 (en) * 2004-07-02 2011-02-01 Sprint Communications Company L.P. Border control system, method, and software
US7623464B2 (en) * 2004-07-09 2009-11-24 Cisco Technology, Inc. Rapid protocol failure detection
US7626979B1 (en) * 2004-07-28 2009-12-01 Sprint Communications Company L.P. Packet voice network border control
US8055778B2 (en) * 2004-09-30 2011-11-08 Siemens Enterprise Communications, Inc. SIP user agent with simultaneous multiple registrations
US7764605B2 (en) * 2004-10-07 2010-07-27 Genband Inc. Methods and systems for measurement-based call admission control in a media gateway
US20060083242A1 (en) * 2004-10-20 2006-04-20 Nokia Corporation Address modification in application servers
US9781274B2 (en) * 2004-10-26 2017-10-03 Cisco Technology, Inc. Providing a proxy server feature at an endpoint
JP4592392B2 (ja) * 2004-11-10 2010-12-01 株式会社エヌ・ティ・ティ・ドコモ 制御装置、移動端末及び移動通信方法
DE102004055494B4 (de) * 2004-11-17 2007-11-08 Siemens Ag Verfahren zur Weiterleitung eines Rufes in einem der direkt kommunizierenden Kommunikationsnetzwerk und Kommunikationskomponente für ein direkt kommunizierendes Kommunikationsnetzwerk
US8194640B2 (en) * 2004-12-31 2012-06-05 Genband Us Llc Voice over IP (VoIP) network infrastructure components and method
US7903546B2 (en) * 2005-01-14 2011-03-08 Cisco Technology, Inc. Detecting unavailable network connections
US20060165053A1 (en) * 2005-01-21 2006-07-27 Nec Laboratories America, Inc. Content based data packet routing using labels
WO2006081454A2 (en) * 2005-01-26 2006-08-03 Internet Broadcasting Corporation Layered multicast and fair bandwidth allocation and packet prioritization
US7599312B2 (en) * 2005-03-11 2009-10-06 Cisco Technology, Inc. Withdrawing multiple advertised routes based on a query defined in a withdraw message which may be of particular use in border gateway protocol
US20060251054A1 (en) * 2005-05-04 2006-11-09 Peters Robert Y Jr Method for providing terminating services treatment for calls terminating in an IP network
US20070291734A1 (en) * 2005-05-27 2007-12-20 Medhavi Bhatia Methods and Apparatus for Multistage Routing of Packets Using Call Templates
US7502320B2 (en) * 2005-07-06 2009-03-10 Cisco Technology, Inc. Method and apparatus for network-based admission control using path-coupled quality of service signaling
US7519024B2 (en) * 2005-08-17 2009-04-14 Sprint Communications Company Lp Resource selection in a communication network
US7734605B2 (en) * 2005-08-22 2010-06-08 Sun Microsystems, Inc. Dynamic quota policy for queuing mechanism
KR100921554B1 (ko) * 2005-08-30 2009-10-14 주식회사 케이티 음성통화중에 다양한 콘텐츠를 공유 및 제어할 수 있는콘텐츠공유서비스를 제공하는 시스템 및 그 방법
US8085757B2 (en) * 2005-11-07 2011-12-27 At&T Intellectual Property I, L.P. Caller-controlled routing to non-SIP/non-TEL URI destinations for an IMS-based ENUM query
US7849445B2 (en) * 2005-12-20 2010-12-07 Sap Ag Remote user interface for external connections
US20070168997A1 (en) * 2005-12-20 2007-07-19 Duong-Han Tran Debugging of remote application software on a local computer
US20070143795A1 (en) * 2005-12-20 2007-06-21 Duong-Han Tran Application trace for distributed systems environment
US9060047B2 (en) 2005-12-21 2015-06-16 Genband Us Llc Media stream management
US7865612B2 (en) 2006-01-31 2011-01-04 Genband Us Llc Method and apparatus for partitioning resources within a session-over-internet-protocol (SoIP) session controller
US7860990B2 (en) 2006-01-31 2010-12-28 Genband Us Llc Session data records and related alarming within a session over internet protocol (SOIP) network
US7861003B2 (en) * 2006-01-31 2010-12-28 Genband Us Llc Adaptive feedback for session over internet protocol
KR100785307B1 (ko) * 2006-02-01 2007-12-12 삼성전자주식회사 아이피 사설교환기를 통한 데이터 중계 전송 시스템 및 그방법
US20070186011A1 (en) * 2006-02-03 2007-08-09 Rockwell Automation Technologies, Inc. Industrial protocol and gateway
US20070186010A1 (en) * 2006-02-03 2007-08-09 Rockwell Automation Technologies, Inc. Extending industrial control system communications capabilities
US8259706B2 (en) * 2006-02-28 2012-09-04 Genband Us Llc Multistage prioritization of packets within a session over internet protocol (SOIP) network
US8204043B2 (en) * 2006-02-28 2012-06-19 Genband Us Llc Quality of service prioritization of internet protocol packets using session-aware components
US8509218B2 (en) * 2006-02-28 2013-08-13 Genband Us Llc Prioritization within a session over internet protocol (SOIP) network
EP2014030A1 (fr) * 2006-04-21 2009-01-14 France Télécom Procede de propagation d'information de connectivite ip entre domaines de telephonie ip distinct, serveur de localisation et programme d'ordinateur correspondants
EP2052505A1 (fr) * 2006-04-21 2009-04-29 France Telecom Procede de prise en compte de la qualite de service entre domaines de telephonie ip distincts, serveur de localisation et programme d'ordinateur correspondants
EP2014031A1 (fr) * 2006-04-21 2009-01-14 France Télécom Procede de selection d'une route de telephonie au sein d'un domaine de telephonie ip, dispositif et programme d'ordinateur correspondants
US8582555B2 (en) * 2006-05-12 2013-11-12 Oracle International Corporation SIP routing customization
US8571012B2 (en) * 2006-05-12 2013-10-29 Oracle International Corporation Customized sip routing to cross firewalls
US7466694B2 (en) 2006-06-10 2008-12-16 Cisco Technology, Inc. Routing protocol with packet network attributes for improved route selection
US20080080543A1 (en) * 2006-09-28 2008-04-03 Rockwell Automation Technologies, Inc. Network switch with controller i/o capability
US8571198B2 (en) 2006-10-10 2013-10-29 Cisco Technology, Inc. Handling redirect calls
US8144631B2 (en) 2006-12-13 2012-03-27 Cisco Technology, Inc. Interconnecting IP video endpoints with reduced H.320 call setup time
US9008081B2 (en) * 2006-12-14 2015-04-14 Rpx Clearinghouse Llc Serving gateway proxies for non-SIP speakers in a next generation network
US7649881B2 (en) * 2006-12-14 2010-01-19 Nortel Networks Limited Pinning the route of IP bearer flows in a next generation network
US7774481B2 (en) * 2006-12-29 2010-08-10 Genband Us Llc Methods and apparatus for implementing a pluggable policy module within a session over internet protocol network
US8631069B2 (en) * 2007-03-01 2014-01-14 Oracle International Corporation Web and multi-media conference
US8144709B2 (en) * 2007-04-06 2012-03-27 International Business Machines Corporation Method, system and computer processing an IP packet, routing a structured data carrier, preventing broadcast storms, load-balancing and converting a full broadcast IP packet
US8089967B2 (en) * 2007-04-06 2012-01-03 International Business Machines Corporation Modification of a switching table of an internet protocol switch
US8705549B2 (en) * 2007-04-06 2014-04-22 International Business Machines Corporation Structure and implementation of universal virtual private networks
US8135013B2 (en) * 2007-04-06 2012-03-13 International Business Machines Corporation Internet protocol switch and use of the switch for switching a frame
US20080263389A1 (en) * 2007-04-20 2008-10-23 At&T Knowledge Ventures, L.P. System for monitoring enum performance
US20080291901A1 (en) * 2007-05-08 2008-11-27 Nathan Allan Stratton Network architecture for call processing
US20080304497A1 (en) * 2007-06-05 2008-12-11 Lucent Technologies Inc. Methods of route control in communications network
US7912062B2 (en) * 2007-09-28 2011-03-22 Genband Us Llc Methods and apparatus for managing addresses related to virtual partitions of a session exchange device
US8239422B2 (en) * 2007-10-18 2012-08-07 At&T Intellectual Property I, Lp Methods and apparatus to provision network resource records
US8811585B1 (en) * 2007-10-23 2014-08-19 Sprint Communications Company L.P. Communication routing plans that are based on communication device contact lists
US8165116B2 (en) * 2007-12-12 2012-04-24 At&T Intellectual Property I, L.P. Method and system to provide contact services in a communication network
US8090870B2 (en) * 2008-04-28 2012-01-03 Disney Enterprises, Inc. Method and system for adaptive data transfer over packet networks
US7814193B2 (en) * 2008-05-06 2010-10-12 At&T Intellectual Property I, L.P. Distributing user endpoint registrations among border elements in a next generation network
WO2010032989A2 (en) * 2008-09-19 2010-03-25 Samsung Electronics Co., Ltd. Method and system for managing communication session establishment
US8051136B2 (en) * 2008-10-13 2011-11-01 International Business Machines Corporation Optimizing a presence enabled managed service
US8385215B1 (en) 2008-11-13 2013-02-26 Cisco Technoogy, Inc. System and method for providing testing in an Ethernet network environment
KR101524311B1 (ko) * 2008-11-27 2015-05-29 삼성전자주식회사 통신 시스템에서 그룹 메시징 세션 생성 방법 및 그 시스템
US8321592B2 (en) * 2008-12-12 2012-11-27 Tekelec, Inc. Methods, systems, and computer readable media for generating and using statelessly reversible representations of session initiation protocol (SIP) information by SIP cluster entities
KR101530219B1 (ko) * 2009-01-05 2015-06-22 삼성전자주식회사 음성 패킷망에서 음성 페이징 서비스를 제공하기 위한 그룹캐스팅 전송방법 및 장치
US9158649B2 (en) * 2009-08-14 2015-10-13 Microsoft Technology Licensing, Llc Methods and computer program products for generating a model of network application health
US20110171958A1 (en) * 2010-01-11 2011-07-14 Suzann Hua Mobile device usage management via home subscriber server operation and profile
US20110219443A1 (en) * 2010-03-05 2011-09-08 Alcatel-Lucent Usa, Inc. Secure connection initiation with hosts behind firewalls
US7912983B1 (en) * 2010-10-21 2011-03-22 Intelepeer, Inc. Multi-layer stack platform for cloud communications
US8719926B2 (en) * 2011-02-11 2014-05-06 Verizon Patent And Licensing Inc. Denial of service detection and prevention using dialog level filtering
US9369345B2 (en) * 2011-11-11 2016-06-14 Pismo Labs Technology Limited Method and system for allowing the use of domain names in enforcing network policy
US8832298B2 (en) 2012-03-16 2014-09-09 Qualcomm Incorporated Managing early media for communication sessions established via the session initiation protocol (SIP)
CN104508426B (zh) * 2012-06-05 2019-03-19 耐克创新有限合伙公司 用于提供路线信息和热图的活动监测系统
KR101447438B1 (ko) * 2013-02-07 2014-10-08 (주)오픈벡스 이종 망을 이용한 통화시스템
KR102054941B1 (ko) * 2013-05-02 2020-01-22 한국전자통신연구원 융합 서비스 제공을 위한 스마트 디바이스들의 동적 네트워킹 설정 장치 및 설정 방법
US20140379912A1 (en) * 2013-06-24 2014-12-25 Alcatel-Lucent Canada, Inc. Radius session limit per service type
US9674193B1 (en) 2013-07-30 2017-06-06 Juniper Networks, Inc. Aggregation and disbursement of licenses in distributed networks
US10666771B2 (en) 2013-08-05 2020-05-26 Pismo Labs Technology Limited Method and system for allowing the use of domain name based network policies stored in a second device in enforcing network policy at a first device
US9531808B2 (en) * 2013-08-22 2016-12-27 Avaya Inc. Providing data resource services within enterprise systems for resource level sharing among multiple applications, and related methods, systems, and computer-readable media
US9635580B2 (en) 2013-10-08 2017-04-25 Alef Mobitech Inc. Systems and methods for providing mobility aspects to applications in the cloud
US9037646B2 (en) * 2013-10-08 2015-05-19 Alef Mobitech Inc. System and method of delivering data that provides service differentiation and monetization in mobile data networks
US10367725B2 (en) 2013-12-21 2019-07-30 Hewlett Packard Enterprise Development Lp Network programming
US9282442B1 (en) 2014-10-29 2016-03-08 Sprint Communications Company L.P. Communication system to route telephony signals based on originating line information
US20160165062A1 (en) * 2014-12-09 2016-06-09 Vonage Network, Llc Data/circuit channel handoff for ip telephony network
US10263882B2 (en) * 2016-10-31 2019-04-16 Riverbed Technology, Inc. Dynamically influencing route re-distribution between an exterior gateway protocol and an interior gateway protocol

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5444693A (en) * 1992-04-27 1995-08-22 At&T Corp. System for restoration of communications networks
US6754181B1 (en) * 1996-11-18 2004-06-22 Mci Communications Corporation System and method for a directory service supporting a hybrid communication system architecture
US6335927B1 (en) * 1996-11-18 2002-01-01 Mci Communications Corporation System and method for providing requested quality of service in a hybrid network
AU7627798A (en) 1996-12-04 1998-06-29 Dsc Telecom L.P. Distributed telecommunications switching system and method
US6084855A (en) * 1997-02-18 2000-07-04 Nokia Telecommunications, Oy Method and apparatus for providing fair traffic scheduling among aggregated internet protocol flows
US6181698B1 (en) * 1997-07-09 2001-01-30 Yoichi Hariguchi Network routing table using content addressable memory
US6085245A (en) 1997-07-24 2000-07-04 Paradyne Corporation System and method for the implicit support of IP subnetworks
US6266335B1 (en) 1997-12-19 2001-07-24 Cyberiq Systems Cross-platform server clustering using a network flow switch
US6078586A (en) * 1998-08-03 2000-06-20 Mci Communications Corporation ATM virtual private networks
US6584093B1 (en) * 1998-08-25 2003-06-24 Cisco Technology, Inc. Method and apparatus for automatic inter-domain routing of calls
US6704287B1 (en) * 1999-02-26 2004-03-09 Nortel Networks Limited Enabling smart logging for webtone networks and services
US6775269B1 (en) * 1999-03-30 2004-08-10 Telecom Technologies, Inc. Method and system for routing telephone calls between a public switched telephone network and an internet protocol network
US6765931B1 (en) * 1999-04-13 2004-07-20 Broadcom Corporation Gateway with voice
US6882643B1 (en) * 1999-07-16 2005-04-19 Nortel Networks Limited Supporting multiple services in label switched networks
US6538991B1 (en) * 1999-08-03 2003-03-25 Lucent Technologies Inc. Constraint-based routing between ingress-egress points in a packet network
US7346022B1 (en) * 1999-09-28 2008-03-18 At&T Corporation H.323 user, service and service provider mobility framework for the multimedia intelligent networking
US6778531B1 (en) * 1999-11-04 2004-08-17 Lucent Technologies Inc. Multicast routing with service-level guarantees between ingress egress-points in a packet network
US6917612B2 (en) * 2000-09-01 2005-07-12 Telefonaktiebolaged L M Ericsson System and method for address resolution in internet protocol (IP)-based networks
US7092390B2 (en) * 2000-09-07 2006-08-15 Sbc Technology Resources, Inc. Internal substitution bi-level addressing for compatible public networks
US7111065B2 (en) * 2000-11-29 2006-09-19 Efficient Networks, Inc. Method and apparatus for managing tunneled communications in an enterprise network
US7002973B2 (en) * 2000-12-11 2006-02-21 Acme Packet Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks via use of a cluster of session routers
US7133923B2 (en) * 2000-12-11 2006-11-07 Acme Packet, Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks via screening
US7028092B2 (en) * 2000-12-11 2006-04-11 Acme Packet, Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks via media flow routing
US7072303B2 (en) * 2000-12-11 2006-07-04 Acme Packet, Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks
US8200577B2 (en) * 2001-03-20 2012-06-12 Verizon Business Global Llc Systems and methods for retrieving and modifying data records for rating and billing purposes
US20030014644A1 (en) * 2001-05-02 2003-01-16 Burns James E. Method and system for security policy management

Also Published As

Publication number Publication date
US20060098577A1 (en) 2006-05-11
WO2002049316A2 (en) 2002-06-20
US20020114282A1 (en) 2002-08-22
US8451716B2 (en) 2013-05-28
WO2002049316A3 (en) 2003-04-17
EP1342349A2 (en) 2003-09-10
US7072303B2 (en) 2006-07-04
US20100034200A1 (en) 2010-02-11
JP2004538671A (ja) 2004-12-24
US7620053B2 (en) 2009-11-17

Similar Documents

Publication Publication Date Title
JP4536999B2 (ja) スクリーニングによって、複数のネットワークを流れるリアルタイムトランスポートプロトコルの制御を支援するシステム及び方法
JP4636781B2 (ja) メディアフロールーティングを経由して、複数のネットワークを通るリアルタイムトランスポートプロトコルフローの制御を支援するシステム及び方法
JP4117188B2 (ja) スクリーニングによって、複数のネットワークを流れるリアルタイムトランスポートプロトコルの制御を支援するシステム及び方法
JP4002511B2 (ja) スクリーニングによって、複数のネットワークを流れるリアルタイムトランスポートプロトコルの制御を支援するシステム及び方法
US7330470B2 (en) Router and sip server
JP3880867B2 (ja) Ｉｐエンドポイント間のｉｐベアラパスを管理するためのｉｐパケットアクセスゲートウェイ（ｉｐｐａｇ）システムおよび方法およびコンピュータプログラム製品
US7466694B2 (en) Routing protocol with packet network attributes for improved route selection
US7016343B1 (en) PSTN call routing control features applied to a VoIP
US8290137B2 (en) System and method for using exception routing tables in an internet based telephone call routing system
US7843835B2 (en) System and method of monitoring an internet based telephone call routing system
JP2002290450A (ja) 帯域管理装置、アドレス解決支援装置、帯域管理方法およびアドレス解決支援方法
EP1686749B1 (en) System and Method for assisting in controlling real-time transport flow through multiple networks via media flow routing
US20100260171A1 (en) Method and apparatus for processing number portability in internet phone

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20040930

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070123

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20070419

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20070426

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070606

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20070911

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20071210

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20080502

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20080530

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20091102

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20091106

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100617

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130625

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

Ref document number: 4536999

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term