JP4713813B2 - 交換網およびパケット網間の通信を改良するためのシステムおよび方法 - Google Patents

Description

【０００１】
関連出願の参照
本出願は、２００１年７月２３日に出願した第０９／９１１，２５６号の米国特許出願「リアルタイム転送プロトコルデータフロー用フロー品質統計を決定するためのシステムおよび方法」、２００１年７月２３日に出願した第０９／９１１，３０４号の米国特許出願「リアルタイムマルチメディアフローの経路再選択を提供するシステムおよび方法」、および２００１年８月２８日に出願した第０９／９４１，２２９号の米国特許出願「リアルタイムマルチメディアフローの経路再選択用暗号化を提供するシステムおよび方法」に関して優先権を主張すると共に、これら開示の全てを参照によってここに組み込む。
【０００２】
発明の属する技術分野
本発明は広く電気通信に関し、さらに詳しくは交換網とパケット網間の通信を向上するためのシステムおよび方法に関する。
【０００３】
従来の技術
公衆交換電話網（ＰＳＴＮ）は、効率的リアルタイムマルチメディア通信セッションツールに進化しており、ユーザは、約１０億の電話のいずれからも、約１０億の相手の１人にダイヤルできる。様々な開発がなされたおかげで、自動化ネットワークとして例えば番号付け方法、分散電子交換および経路選択、ネットワーク化信号方式等が可能となった。
【０００４】
公衆交換電話網が階層に基づくのに似て、インターネットはインターネットプロトコル（ＩＰ）に基づいている。ＩＰメッセージは、１つのリンクからその次へと（すなわちデータフローの送信元からそのデータフローの送信先へ）伝送または転送される。各ＩＰパケットはＩＰアドレスを含み、これはＩＰバージョン４（ＩＰｖ４）の例えば３２ビットである。また各ＩＰアドレスは、ネットワーク部に割り当てたいくつかのビットと、ホスト部に割り当てたいくつかのビットとを有する。
【０００５】
ＩＰルータは、データパケットを１つのネットワーク（またはリンク）から受け取り、それを別のネットワーク（またはリンク）へ置く。ＩＰルータ内には表を配置し、そこにデータパケット伝送用最適経路を決定するための情報または基準を保持する。この情報は、例えばネットワークリンクの状態、プログラムした距離表示等である。ネットワーク領域の両側で情報装置を使用し、一時的アドレスを割り当て、ネットワーク経由でパケットを伝送し、パケットがそのネットワークを離れたら、ネットワークの相手側において元アドレスを復元できる。これは現在、多くの仮想専用線網（ＶＰＮ）の基本であり、当業者には良く知られている。
【０００６】
網要素（例えば電話網における交換機、データ網におけるルータ）が確実にそのタスクを実行できるようにするには、それら網要素は、隣接通信リンクおよび利用可能経路の状態を知る必要がある。この情報を提供するために信号方式を使用する。電話網において使用する信号方式は、ＳＳ７信号方式（ＳＳ７）またはＳＳ７同等品である。ＳＳ７網は、音声網とは別であり、電話呼を接続し信号網を保守する業務のデータメッセージ交換に使用する。さらにＳＳ７デジタル信号規格は、公衆交換電話網からＩＰ網へのインタフェースを提供するために利用される。当業者に知られている通り、ＳＳ７が使用するメッセージ構造は、１つのネットワーク実体から他へのメッセージ搬送を、当該メッセージに関係する実際の音声およびデータとは独立に行う。このメッセージ構造は、パケットと呼ぶエンベロープを使用してメッセージを搬送する。
【０００７】
現在のほとんどの電気通信端点は、公衆交換電話網準拠システムを介してサービスを受けているため、ゲートウエイを使用してパケットデータ網と公衆交換電話網間のマルチメディアパケットフローを実現する。なおマルチメディアは、音声、データ、および／または個別メディアから成る。ゲートウエイは、データ網およびデータ網間の端部に設置し、マルチメディア（および信号）を変換して通信を確保する。
【０００８】
特定タイプゲートウエイの一例は、メディアゲートウエイである。メディアゲートウエイは、あるタイプのネットワークが提供するマルチメディアを、他のタイプのネットワークが必要とするフォーマットに変換する。例えばメディアゲートウエイは、交換回線網からのベアラチャネルを終端すると共に、パケット網（例えばＩＰ網におけるリアルタイムプロトコル（ＲＴＰ）ストリーム）からのメディアストリームを終端できる。メディアゲートウエイは、音声、映像、Ｔ．１２０を単独でまたは組合せで処理でき、全二重メディア変換が可能である。またメディアゲートウエイは、音声／映像メッセージを再生でき、他の対話音声応答（ＩＶＲ）機能を持つことができ、メディア会議を行うことができる。
【０００９】
ゲートウエイ間で呼を経路選択する方法は、いくつか当業者に知られている。これら方法の２つは、フルメッシュ経路選択と階層経路選択である。フルメッシュ経路選択は、標準的な方法であり、ほとんどのソフトスイッチング設計が記載している。セッションイニシエーションプロトコル（ＳＩＰ）は、インターソフトスイッチ信号方式であり、随所から随所への信号モデルを支援する。このモデルにおいてソフトスイッチは、他のソフトスイッチへの仮想接続を有し、呼を完成させる。
【００１０】
ソフトスイッチは、呼エージェントまたはメディアゲートウエイコントローラと呼ばれ、ネットワーク内に存在するゲートウエイを管理する。ソフトスイッチは、メディアゲートウエイ制御プロトコルを使用し、ゲートウエイと通信できる。特にメディアゲートウエイ制御プロトコルは、パケット電話方式ネットワークにおいて、ソフトスイッチとゲートウエイ間で働く。ソフトスイッチは多くの機能を有し、メディアゲートウエイのメディアチャネル用接続制御に関する呼状態の部分を制御する。
【００１１】
ゲートウエイは、ソフトスイッチがメディアゲートウエイ制御プロトコルを使用して送るコマンドを実行することを求められる。一般にこれらコマンドは、音声信号とパケット網間の変換を含む。残念ながら、多くのソフトスイッチから成るネットワークを運営する場合、そのネットワークの所有者は、ポリシー管理の様々な点を保守しながら、フルメッシュを作成しなければならない。このようなポリシー管理問題は、例えば各ソフトスイッチに他の各ソフトスイッチのＩＰアドレスを知らしめたり、接続先の電話番号または公衆交換電話網を知らしめたりすることを含む。複数の業者のソフトスイッチを運営する場合、異なるインタフェースを用いねばならないため、さらに複雑な管理問題が生ずる。
【００１２】
展開するソフトスイッチの数が大きくなると、異なる経路を共有する可能性が出てくる。フルメッシュ経路選択構成では、呼の経路選択が困難になる。なぜなら、いくつかの出口ソフトスイッチが満杯あるいは機能しないことがあるからである。例えば、あるキャリアが３０の国内長距離を扱うソフトスイッチを有し、そのネットワークが約５０％で稼働していれば、各発信ソフトスイッチは、平均１５のソフトスイッチを個別に試した後、やっと１つの障害のない経路を見つけられる。この探索努力は、純粋ランダム分散を実行すれば大きく減らせる。しかしながら、コストや品質の面から他の経路が好まれることもあるため、問題は難しい。さらにソフトスイッチを過剰に動作させると、例えば過剰な状態共有を行うと、情報（データおよび／または音声）の流れが減る。
【００１３】
発明の概要
前記に鑑み、本発明は広く交換網とパケット網間の通信を向上させるためのシステムおよび方法に関する。
【００１４】
広く本通信システムの構造は、信号ゲートウエイを使用して、信号を第１プロトコルから第２プロトコルへ変換すると共に、前記第２プロトコルから前記第１プロトコルへ変換する。少なくとも１つのメディアゲートウエイを使用して、マルチメディアを第１フォーマットから第２フォーマットへ変換すると共に、前記第２フォーマットから前記第１フォーマットへ変換する。セッションルータを使用し、送信先への少なくとも１つのマルチメディア送信経路を選択する。ここで送信先は、交換網が指定し、パケット網内に位置する。さらに本通信システムは、メディアルータを使用し、前記メディアゲートウエイによる変換後の前記マルチメディアを前記送信先へ導く。
【００１５】
さらに本発明は、交換網からユーザエージェントへの呼を確立するための１つまたはそれ以上の方法を提供する。ここでユーザエージェントは、パケット網内に位置する。前記方法の１つを簡略にまとめれば、次のようなステップとなる。初期アドレスメッセージを交換網から信号ゲートウエイへ送信する。前記信号ゲートウエイにおいて、前記初期アドレスメッセージをセッションインターネットプロトコルインバイトメッセージへ変換する。前記インターネットプロトコルインバイトメッセージをセッションルータへ送信する。このセッションルータは、前記インターネットプロトコルインバイトメッセージを分析し、前記ユーザエージェントへの最適経路を決定する。前記セッションルータからの要求に基づき、メディアルータ内において、前記ユーザエージェントから前記交換網へのマルチメディア送信用メディアルータアドレスおよびポートを開く。前記メディアルータは、前記マルチメディアを前記ユーザエージェントへ誘導できる。
【００１６】
本発明の他のシステムおよび方法は、以下の図面および詳細説明を検討することにより、当業者に明らかとなろう。これら本発明のさらなるシステム、方法、特徴、利点は、本明細書に含まれることを意図しており、特許請求の範囲によって保護されるべきものである。
【００１７】
発明を実施するための最良の形態
本発明は、以下の図面を参照することにより理解が深まる。図面各部の縮尺は、必ずしも正確ではなく、誇張によって本発明の原理を明示することもある。さらに図中、同一参照番号は対応部分を表す。
【００１８】
図面を参照すると、全図を通して同一参照番号は対応する部分を示し、図１は従来の通信網１０２を示すブロック図である。図１に示すように、従来の通信網１０２は、公衆交換電話網１１２を備える。この公衆交換電話網は、時分割多重（ＴＤＭ）網１２１内に存在し、ユーザエージェント１２６と通信する。このユーザエージェントは、詳細を後述する通り、ＩＰ網１２２内に存在する。なおＩＰ網１２２は、それに代えていかなるパケットデータ網でも構わない。公衆交換電話網１１２は、通信網１０２の信号データおよび音声を細分化し、様々なトラフィック部品を独立に設定する機能を保証できる。
【００１９】
従来回線においてなされた呼をＩＰパケットに作り直すことを可能にするため、あるいはその逆を可能にするため、従来の通信網１０２は第１および第２メディアゲートウエイ１１４および１１６を利用する。これらメディアゲートウエイの数は、当該ゲートウエイを利用する通信網の要求に応じ、増減できる。
【００２０】
第１メディアゲートウエイ１１４および第２メディアゲートウエイ１１６は、送信チャネルを経由して公衆交換電話網１１２に接続する。一般に公衆交換電話網１１２を各メディアゲートウエイ１１４，１１６へ接続する各チャネルは、回線識別コード（ＣＩＣ）を有する。この回線識別コードは、信号点間で使用し、網内の特定回線を一意に識別する。すなわち回線識別コードは、呼を通信網１０２内の特定のリアルタイムプロトコルポートへ搬送するために発信交換機（公衆交換電話網）が予約したトランク回線を示す。
【００２１】
メディアゲートウエイ１１４，１１６は、あるタイプのネットワークが提供するマルチメディアを他タイプのネットワークが使用するフォーマットへ変換する。特にメディアゲートウエイ１１４，１１６は、マルチメディアマッピングおよび／またはコード変換機能を異種ネットワーク間で実現する。これら異種ネットワークの１つは、パケット網、フレーム網、またはセル網と考えられる。例えば従来の図示通信網１０２において、メディアゲートウエイ１１４，１１６は、時分割多重網１２１の公衆交換電話網１１２が使用する時分割多重（ＴＤＭ）フォーマットのメディアを、ＩＰ網１２２のリアルタイムプロトコルフォーマットへ変換する。従来例において、一般にメディアゲートウエイ１１４，１１６は、受信したマルチメディアの送信先を決定する機能も果たす。
【００２２】
さらに公衆交換電話網１１２は、公衆交換電話網とＩＰ網１２２間の信号方式も提供するので、信号ゲートウエイ（ＳＧＷ）１１８を通信網１０２に配置する。この信号ゲートウエイは、少なくとも１つのチャネルを経由して公衆交換電話網１１２に接続する。既知の通り、公衆交換電話網１１２は、ＳＳ７信号方式を公衆交換電話網１１２と信号ゲートウエイ１１８間の信号メッセージの通信に利用する。信号ゲートウエイ１１８は、信号エージェントとして働き、ＩＰ網１２２の端部において、交換回線網（ＳＣＮ）固有信号を受信し送信する。信号ゲートウエイ１１８は、ＳＳ７信号方式を中継、変換、終端する。一般に信号ゲートウエイ１１８は、ＳＳ７信号方式をＳＩＰ信号方式へ変換する。ＳＩＰ信号方式は、パケット準拠ネットワークにおいて普及している。
【００２３】
ＳＳ７信号方式が利用するメッセージ構造において、メッセージは、関連する実際の音声およびデータとは独立に、１つのネットワーク実体から他へと移動する。このメッセージ構造は、パケットと呼ばれるエンベロープを利用してメッセージを搬送する。一方ＳＩＰ信号方式は、ＩＰ網１２２における電話呼を終端するための信号プロトコルであり、特にインターネット用に設計されている。ＳＩＰ信号方式は、インターネットプロトコルの扱いやすさを利用すると共に、ウインドウズアプリケーションを開発するのと同じくらい簡単に、電話通信アプリケーションを開発できるよう、構造的に設計されている。ＳＩＰ信号方式は、インターネットにおけるハイパーテキスト転送プロトコル（ＨＴＴＰ）要求に比較的似ている。
【００２４】
信号ゲートウエイ１１８は、ソフトスイッチ１２４に接続する。前記した通り、ソフトスイッチは、呼エージェントまたはメディアゲートウエイコントローラとも呼ばれ、通信網１０２に存在するメディアゲートウエイ１１４，１１６を管理する。ソフトスイッチ１２４は、メディアゲートウエイ１１４，１１６におけるメディアチャネル接続制御に関係する呼状態の部分を制御する。さらにソフトスイッチ１２４は、ネットワークレベルビュー（例えばトランク利用、ＩＰ網帯域幅および利用）用の遠隔地資源を監視し、呼信号情報に基づくメディアゲートウエイのメディアコード変換パラメータを作成する。もちろんソフトスイッチ１２４は、ここに記述した以外に当業者に公知の他の機能も実行できる。
【００２５】
ソフトスイッチ１２４は、メディアゲートウエイ制御プロトコル（ＭＧＣＰ）を使用し、メディアゲートウエイ１１４，１１６と通信できる。メディアゲートウエイ１１４，１１６は、ソフトスイッチ１２４がメディアゲートウエイ制御プロトコルを使用して送るコマンドを実行することを求められる。一般にこれらコマンドは、多くの機能の中で音声信号およびパケット網の変換を求める。非限定的な例として、メディアゲートウエイ制御プロトコルは、ソフトスイッチ１２４に次のようなコマンドを提供するために使われる。通知要求、接続生成、接続変更、接続削除、端点または接続監査、メディアゲートウエイ１１４，１１６の構成の提供である。さらにメディアゲートウエイ制御プロトコルは、メディアゲートウエイ１１４，１１６に次のコマンドを提供するためにも使われる。接続再開、接続削除、接続通知である。
【００２６】
ソフトスイッチ１２４とメディアゲートウエイ１１４，１１６とは、ユーザエージェント１２６に接続することにより、公衆交換電話網１１２とユーザエージェント１２６間に通信パスを完成する。残念ながらソフトスイッチ１２４やメディアゲートウエイ制御プロトコルを過剰に動作させると、マルチメディアの流れが減速する。本発明の通信システムは、以下に詳述する通り、この問題に取り組み解決策を提供する。図２は、本発明の好適実施例に基づく改良通信網１３２を示すブロック図である。
【００２７】
改良通信網
図２に示すように、改良通信網１３２は、公衆交換電話網１３４を備える。この公衆交換電話網は、時分割多重網１３３内に存在し、この時分割多重網は、以下で詳述するように、ＩＰ網１３６と通信する。公衆交換電話網１３４は、通信網１３２上の信号データおよび音声を細分化することにより、様々なトラフィック部品の独立設定を保証する。
【００２８】
従来回線においてなされた呼をＩＰパケットに作り直すことを可能にするため、あるいはその逆を可能にするため、改良通信網１３２は第１および第２メディアゲートウエイ１４２および１４４を利用する。これらメディアゲートウエイの数は、当該ゲートウエイを利用する通信網の要求に応じ、増減できる。
【００２９】
第１メディアゲートウエイ１４２および第２メディアゲートウエイ１４４は、送信チャネルを経由して公衆交換電話網１３４に接続する。一般に公衆交換電話網１３４を各メディアゲートウエイ１４２，１４４へ接続する各チャネルは、回線識別コード（ＣＩＣ）を有する。この回線識別コードは、信号点間で使用し、網内の特定回線またはベアラチャネルを一意に識別する。すなわち回線識別コードは、呼を改良通信網１３２内の特定のリアルタイムプロトコルポートへ搬送するために発信交換機（公衆交換電話網）が予約したトランク回線またはベアラチャネルを識別する。
【００３０】
メディアゲートウエイ１４２，１４４は、１タイプのネットワークが提供するマルチメディアを他タイプのネットワークが使用するフォーマットへ変換する。特にメディアゲートウエイ１４２，１４４は、マルチメディアマッピングおよび／またはコード変換機能を異種ネットワーク間で実行する。これら異種ネットワークの１つは、パケット網、フレーム網、またはセル網と考えられる。例えば本発明の改良通信網１３２の特徴において、メディアゲートウエイ１４２，１４４は、時分割多重網１３３における時分割多重（ＴＤＭ）フォーマットのメディアを、ＩＰ網１３６のリアルタイムプロトコルフォーマットへ変換する。しかしながら従来例とは異なり、メディアゲートウエイ１４２，１４４は、受信したマルチメディアの送信先を決定しないことが好ましい。それに代えてメディアゲートウエイ１４２，１４４は、変換を行うことに限定される。もちろん、変換のみを行うだけではない従来のメディアゲートウエイ１４２，１４４でも良い。あるいはメディアゲートウエイ１４２、１４４は、変換のみに使用しても良い。
【００３１】
さらにメディアゲートウエイ１４２、１４４内に回線識別コードアドレスをプログラムし、メディアゲートウエイ１４２、１４４で意思決定をせず、チャネルを空けて送信先へのマルチメディア連続送信を提供するようにしても良い。本発明の好適実施例に基づき、メディアゲートウエイ１４２、１４４は、単に変換のみを行うものとし、特定用途集積回線（ＡＳＩＣ）等の論理デバイス上に提供しても良い。このようなデバイスは、より簡易、安価、小型である。これは、メディアゲートウエイ１４２，１４４からメディアルータ１６４へ一定に流れるリアルタイムプロトコル用固定送信先アドレスによって可能となる。
【００３２】
公衆交換電話網１３４は、公衆交換電話網１３４とＩＰ網１３６間の信号も提供するため、信号ゲートウエイ（ＳＧＷ）１５２を改良通信網１３２に配置する。この信号ゲートウエイは、少なくとも１つのチャネルを経由して公衆交換電話網１３４に接続する。公衆交換電話網１３４は、ＳＳ７信号方式を利用して、公衆交換電話網１３４と信号ゲートウエイ１５２間の信号メッセージの通信を行う。本発明の好適実施例に基づき、信号ゲートウエイ１５２は、ＳＳ７信号方式をＳＩＰ信号方式へ変換し、その他の機能は実行しない。もちろん、単に変換を行うだけではない従来の信号ゲートウエイ１５２を備えても良く、あるいは変換目的に使用するだけの従来の信号ゲートウエイ１５２を備えることもできる。なお信号ゲートウエイ１５２およびメディアゲートウエイ１４２、１４４は、変換だけを行うため、マルチメディアデータ送信の速度は、極めて大きくなる。これは当業者に明らかであろう。信号ゲートウエイ１５２は変換を行うだけなので、信号ゲートウエイ１５２を特定用途集積回線（ＡＳＩＣ）等の論理デバイス上に提供できる。
【００３３】
信号ゲートウエイ１５２は、メモリを備える。このメモリは、受信した回線識別コード（ＣＩＣ）をセッション記述プロトコル（ＳＤＰ）ヘッダへ変換するために使用できる。このヘッダは、送信先ユーザエージェント１９２のＩＰアドレスおよびポートから成り、パケットをメディアゲートウエイ１４２，１４４へ向かわせる。セッション記述プロトコルの詳細は、インターネット技術標準化委員会のインターネット草案「ＳＩＰ：セッションイニシエーションプロトコル」文書識別番号ｉｅｔｆ−ｓｉｐ−ｒｆｃ２５４３ｂｉｓ−０２．ｐｓにあり、その全てを参照によりここに組み込む。当業者には明らかな通り、回線識別コードは、公衆交換電話網送信用に割り当てた特定回線を識別する。例えば回線番号１は、回線識別コード０〜２０から成り、回線番号２は回線識別コード２１〜４０から成る。さらに前記メモリは、特定の回線識別コードを特定のメディアゲートウエイＩＰアドレスおよびポートに結び付ける表を格納できる。下記の表１は、メディアゲートウエイ１４２，１４４メモリに格納可能な表の例である。
【００３４】
【表１】

表１に示す通り、回線識別コード０〜２０は、回線１に関係して使用する。これら回線識別コードは、メディアゲートウエイ１４２のＩＰアドレス１３２．１４７．１６８．２と、メディアゲートウエイポート３０００〜３０２０とに関連付けられている。回線識別コード２１〜４０は、回線２に関連して使用する。これら回線識別コードは、メディアゲートウエイ１４４のＩＰアドレス１３２．１４７．１６８．４と、メディアゲートウエイポート３０２１〜３０４０とに関連付けられている。信号ゲートウエイ１５２におけるＳＳ７信号方式からＳＩＰ信号方式への変換の詳細は後述する。
【００３５】
信号ゲートウエイ１５２は、セッションルータ（ＳＲ）１６２に接続する。このセッションルータは、マルチメディアデータパケットを特定送信先へ転送するための複数経路を処理し選択するために利用する。特にセッションルータ１６２は、複数の送信経路を処理し、最適送信経路を選択する。セッションルータ１６２の一例とその実施は、メランピー等が２００１年７月２３日に同時係属米国特許出願の第０９／９１１，２５６号「メディアフロー経路選択を使用して複数ネットワークのリアルタイム転送プロトコルフロー制御を支援するためのシステムおよび方法」（以降「２５６特許出願」と呼ぶ）が提供しており、この開示の全てを参照によりここに組み込む。前記２５６特許出願は、セッションルータを用い、ユーザエージェントセットまたはセッションイニシエーションプロトコル（ＳＩＰ）エージェントセットから複数経路を順次選択し処理する。これらセットは、様々な分散方式を用いたほぼ同等のものである。
【００３６】
メディアゲートウエイ１４２、１４４は、メディアルータ１６４に接続する。このメディアルータは、メディアゲートウエイ１４２、１４４による変換後、変換結果としてのリアルタイムプロトコルフローを所定送信先または終端へ誘導または案内する。リアルタイムプロトコル送信先または終端は、あらかじめセッションルータ１６２が選択および処理している。この詳細は後述する。結果としてのリアルタイムパケット（ＲＴＰ）フローのパスを管理することが好ましい。メランピー等が２００１年７月２３日に米国特許出願の第０９／９１１，３０４号「リアルタイムマルチメディアフローの高速経路選択を提供するためのシステムおよび方法」（以降「３０４特許出願」と呼ぶ）は、その全体を参照によりここに組み込む。この特許出願は、セッションルータ１６２が選択し処理した結果としてのメディアルータを使用して、リアルタイムプロトコルフローを所定端点を経由して案内することを開示する。なおメディアルータの数は、改良通信網１３２の要求に応じて異ならせればよい。
【００３７】
メディアルータをリアルタイムマルチメディアフローに導入すると、データパケットは、既知のインタフェースを強制的に通過させられる。図３は、メディアルータ１６４の詳細を示すブロック図である。図３に示す通り、メディアルータ１６４は、フロー品質管理エンジン１７２と、トラフィックマネージャ１７４と、通信インタフェース１７６と、ホストプロセッサ１７８と、ネットワークプロセッサ１８２と、入力装置１８４と、出力装置１８６とを備える。これら全ては、ローカルリンク１８８を経由してメディアルータ１６４内で通信する。前記部品の各々は、現在審査中の前記３０４特許出願が説明している。
【００３８】
特にトラフィックマネージャ１７４は、トラフィック測定を提供し、ＩＰセッションデータ速度またはトラフィックを測定する。トラフィックマネージャ１７４の市販品の一例は、米国カリフォルニアのＭＭＣネットワーク社が販売するＮＰＸ５７００トラフィックマネージャである。基本的にトラフィックマネージャ１７４は、通信インタフェース１７６を流れるデータパケット数を測定する。トラフィックマネージャ１７４は、ネットワークプロセッサ１８２と共同し、転送決定がなされると、受信パケットを各ＩＰフローおよび関連する優先待ち行列に入れる。
【００３９】
当業者には明らかな通り、トラフィックマネージャ１７４は、受信データパケットを一時的に格納するためのメモリを備える。メディアルータ１６４は、受信方向においてリアルタイムプロトコルデータフローを監視でき、パケットがそのデータフローに割り当てられた帯域幅の範囲外であれば、そのパケットを落とすか破棄対象のマークを付け、強制的に最大データ速度を維持する。またトラフィックマネージャ１７４は、セッションルータ１６２の命令により、特定量のデータを割当て帯域幅およびビットレートに基づき受け入れる。従ってセッションルータ１６２が許可したビットレートよりも高いビットレートのデータを受信すると、それを送信しない。なおセッションルータが指定する特性は、セッションルータ１６２を使用せず、メディアルータ１６４に直接プログラムしても良い。
【００４０】
フロー品質管理エンジン１７２は、メディアルータ１６４における変換サービスと、品質測定サービスと、上流および下流障害の検出および修正を提供する。フロー品質管理エンジン１７２が行う変換サービスは、送信元アドレス、送信先アドレス、送信元ポート、送信先ポート、あるいはこれらフィールドのあらゆる組合せを変換する機能である。またメディアルータ１６４は、マルチプロトコルラベルスイッチング（ＭＰＬＳ）タグをマルチメディアデータフローパケットのＩＰヘッダに対して除去および／または挿入する機能を有する。さらにメディアルータ１６４は、パケットのＩＰヘッダ内に存在するディフサーブ（ＤｉｆｆＳｅｒｖ）コードポイントを挿入または変更する機能を有する。これは、当業者に知られている通り、データパケットの優先順位を変更するために使う。
【００４１】
メディアルータ１６４においてフロー品質管理エンジン１７２が提供する品質測定サービスは、フロー毎に提供する。ここでマルチメディアデータフローは、送信元ＩＰアドレス、送信先ＩＰアドレス、送信元ポート、および／または送信先ポートによって定義する。品質測定は、ネットワークプロセッサ１８２内のフローに関する現在の統計データ、および総計、最小、最大に関する可能な統計データを保持することが好ましい。収集する統計データは、例えば待ち時間、ジッタ、所定の時間ウインドウにおけるパケット損失である。このウインドウは、セッションルータ１６２またはメディアルータ１６４を介して識別可能である。総計の統計データは、送信したパケット、破棄パケット、複写パケットを含むことができる。最小および最大の統計データは、境界統計データとも呼び、待ち時間、ジッタ、時間ウインドウあたりのパケット損失等を収集したものである。フロー品質管理エンジン１７２も、メディアルータ１６４内において、リアルタイムプロトコルデータパケット送信における上流および下流障害の検出および修正を提供する。
【００４２】
ホストプロセッサ１７８は、トラフィックマネージャ１７４と同様、上流および下流障害の検出および修正を提供する。リアルタイムプロトコルデータパケットの送信における上流および下流障害を検出および修正するため、ホストプロセッサ１７８が使用する方法は、リンク障害および外部管理イベントの使用を含む。ただしこれに限定しない。外部検索エンジン１７７は、メディアルータ１６４内に配置し、コンテントアドレス指定可能メモリを提供する。外部検索エンジン１７７は、ネットワークプロセッサ１８２による高速アクセス用「オープン／バインド」要求によってあらかじめ決定された変換または結合を格納する。オープン／バインド要求については、詳細を後述する。前記外部検索エンジンは、出力デバイスがイーサネットタイプデバイスである場合のＩＰマッピングへのメディアアクセス制御アドレスを格納するためにも使用する。外部検索エンジンは、例えばカリフォルニア州マウンテンビューのネットロジックマイクロシステムズ社が製造販売している。
【００４３】
なおセッションルータ、メディアルータ、信号ゲートウエイ、メディアゲートウエイの数は、図２に示した数と異なっても良い。いくつかのセッションルータを経由する通信の例は、メランピー等が２００１年４月２７日の米国特許出願の第０９／８４４，９９２号の「多数のセッションルータを使用して複数ネットワークのリアルタイム転送プロトコルフロー制御を支援するためのシステムおよび方法」が提供しており、その全てを参照によりここに組み込む。いくつかのメディアルータを経由する通信の例は、メランピー等が２００１年７月２３日に米国特許出願の第０９／９１１，３０４号「リアルタイムマルチメディアフローの高速経路再選択を提供するためのシステムおよび方法」が提供しており、その全てを参照によりここに組み込む。
【００４４】
図２に示すように、セッションルータ１６２およびメディアルータ１６４は、相互接続しているだけでなく、着呼側または発呼側の少なくとも１つのユーザエージェント１９２に接続または代理接続している。なおユーザエージェント１９２は、セッションイニシエーションプロトコル（ＳＩＰ）エージェントでも構わない。セッションルータ１６２と信号ゲートウエイ１５２間およびセッションルータ１６２とユーザエージェント１９２間の通信は、ＳＩＰ信号方式を使用して提供する。考慮すべき他のタイプの信号方式は、Ｈ．３２３または同等品を含む。さらにメディアルータ１６４と第１および第２メディアゲートウエイ１４２，１４４間、およびメディアルータ１６４とユーザエージェント１９２間の通信は、リアルタイムプロトコル（ＲＴＰ）データフローを使用して提供する。
【００４５】
図４〜１３Ｂは、詳細を後述するように、一連の呼処理を示すフローチャートと、各呼処理の詳細を示す少なくとも１つのブロック図である。以下の全フローチャートにおいて、１ブロックはコードモジュール、コードセグメント、またはコード部分を表し、１つ以上の実行可能命令からなり、指定の論理機能を実行する。いくつかの変更実施形態において、ブロック内に記載した機能は、記載順序を外れて発生することもある。例えば連続して示す２つのブロックは、実質的に並列実行されることもあり、逆順に実行されることもある。これらはその時の機能による。
【００４６】
また図４〜１３Ｂは、１つのセッションルータと１つのメディアルータとの使用を表す。前記した通り、改良通信網１３２は、１つ以上のセッションルータと１つ以上のメディアルータとを利用しても構わない。
【００４７】
公衆交換電話網からユーザエージェントへの呼設定
図４Ａ、４Ｂ、４Ｃは、公衆交換電話網が開始する呼の設定および実行の一連の呼処理を示すフローチャートである。この呼は、公衆交換電話網１３４とユーザエージェント１９２間に、信号ゲートウエイ１５２，セッションルータ１６２，メディアゲートウエイ１４２，１４４，およびメディアルータ１６４を経由して設定する。なおセッションルータ１６２および信号ゲートウエイ１５２は、改良通信網１３２の信号方式機能を提供し、メディアゲートウエイ１４２，１４４およびメディアルータ１６４は、マルチメディア送信を提供する。なお２つのメディアゲートウエイ１４２，１４４は、単なる例として図４に示したものであり、１つのメディアゲートウエイだけでも十分である。
【００４８】
最初に初期アドレスメッセージ（ＩＡＭ）を、公衆交換電話網１３４から信号ゲートウエイ１５２へ送信する（ブロック５０２）。初期アドレスメッセージが含む情報は、公衆交換電話網１３４とユーザエージェント１９２間に呼を確立するために必要な情報である。特に初期アドレスメッセージが含む情報は、発呼側、被呼側、接続インジケータ（ＮＣＩ）の性質、発呼側カテゴリ（ＣＰＣ）、転送呼インジケータ（ＦＣＩ）から成る。さらに初期アドレスメッセージは、回線識別コード（ＣＩＣ）を含む。このコードは、呼をユーザエージェント１９２へ搬送するために公衆交換電話網１３４が予約する特定ベアラチャネルまたは回線を識別する。なお初期アドレスメッセージは他のパラメータを提供することもできる。その例は、インターネット技術標準化委員会のゴンザロカマリロ等の２００１年５月付け文書「ＩＳＵＰからＳＩＰへのマッピング」に記載されている。
【００４９】
信号ゲートウエイ１５２は、前記初期アドレスメッセージを受信すると、その初期アドレスメッセージをＳＩＰインバイトメッセージへ変換する（ブロック５０４）。初期アドレスメッセージからＳＩＰインバイトメッセージへの変換中、初期アドレスメッセージが格納する情報内容は保持され、ＳＩＰインバイトメッセージによって表現される。非限定的な例としてインバイトメッセージは、初期アドレスメッセージ発呼者から変換するフロム（ＦＲＯＭ）ヘッダと、初期アドレスメッセージ被呼者から変換するツー（ＴＯ）ヘッダと、初期アドレスメッセージ回線識別コードから変換するセッション記述プロトコル（ＳＤＰ）ヘッダとを備える。このセッション記述プロトコルヘッダは、送信先ユーザエージェント１９２用ＩＰアドレスおよびポートを含み、リアルタイムプロトコルメディアを送信するために使う。信号ゲートウエイ１５２は、前記表１にアクセスすることにより、回線識別コードをＩＰアドレスおよびポートへ変換する。なお初期アドレスメッセージからＳＩＰインバイトメッセージへの変換は、外部通信または割り当てを必要としないため、信号ゲートウエイ１５２内においてアルゴリズムにより処理する。その結果を管理するための通信またはステートマシンは、必要ない。次に信号ゲートウエイ１５２は、前記インバイトメッセージをセッションルータ１６２へ送信する（ブロック５０６）。セッションルータ１６２は、前記インバイトメッセージを受け取ると、１００トライング（Ｔｒｙｉｎｇ）応答を信号ゲートウエイ１５２へ返信し（ブロック５０８）、セッションルータ１６２が当該呼を扱っていることを示す。
【００５０】
セッションルータ１６２は、インバイトメッセージを受信すると、それを分析し、送信先ユーザエージェント１９２への最適経路を決定しようとする（ブロック５１２）。この決定を行うための方法の例は、メランピー等が２００１年４月２７日に特許出願の「リアルタイム転送プロトコル制御を支援するためのシステムおよび方法、複数ネットワークを経由するフロー」が提供しており、これを参照によりここに組み込む。１つ以上のメディアルータを有するネットワークにおいて、最適経路の決定は、その最適経路において利用するメディアルータを選択することをさらに含む。
【００５１】
次にオープン／バインドメッセージをセッションルータ１６２からメディアルータ１６４へ送信し（ブロック５１４）、メディアルータ１６４によるリアルタイムプロトコル送信に割り当てるメディアルータアドレスおよびポートを要求する。次にメディアルータ１６４は、メディアルータ１６４内においてメディアアドレスおよびポートを開いて割り当て、それに対してユーザエージェント１９２から公衆交換電話網１３４へのリアルタイムプロトコルマルチメディアパケットを送信できるようにする（ブロック５１６）。次に応答をセッションルータ１６２へ送信し、セッションルータ１６２に対して今割り当てたメディアルータアドレスおよびポートアドレスを提供する（ブロック５１８）。このステップが完了すると、メディアルータ１６４は、ユーザエージェント１９２から受信する全てのリアルタイムプロトコルパケットを、公衆交換電話網１３４の回線識別コードに関連するメディアゲートウエイ１４２，１４４の正しいＩＰアドレスおよびポートへ直接転送できる。
【００５２】
図４Ａの続きである図４Ｂに示す通り、インバイトメッセージをセッションルータ１６２からユーザエージェント１９２へ送信する（ブロック５２２）。この時点におけるインバイトメッセージは、メディアルータアドレスおよびポートを含んでおり、これらは信号ゲートウエイ１５２からセッションルータ１６２へ送信されたＩＰアドレスおよびポートの代わりである。ユーザエージェント１９２は、メディアルータ１６４とセッションルータ１６２と信号ゲートウエイ１５２と公衆交換電話網１３４が予約したベアラチャネルとのアドレスおよびポートを知ったので、公衆交換電話網１３４へ戻るリアルタイムプロトコルマルチメディアフローを確立できる。公衆交換電話網１３４へ戻るリアルタイムプロトコルマルチメディアフローを確立するにあたり、ユーザエージェント１９２は、公衆交換電話網１３４へ監視トーンを送信し、ユーザエージェント１９２から公衆交換電話網１３４へのリアルタイムプロトコルマルチメディアパスを確立する。
【００５３】
ユーザエージェント１９２から公衆交換電話網１３４へのマルチメディアの送信は、リアルタイムプロトコルパケットをユーザエージェント１９２からメディアゲートウエイ１４２，１４４の少なくとも１つへ送信することにより行われる。メディアゲートウエイ１４２，１４４は、マルチメディアをＩＰ網１３６のリアルタイムプロトコルフォーマットから公衆交換電話網１３４の時分割多重フォーマットへ変換する。メディアゲートウエイ１４２，１４４は、変換を完了すると、受信したマルチメディアを公衆交換電話網１３４へ送信する。
【００５４】
ユーザエージェント１９２は、１８Ｘメッセージをセッションルータ１６２へ送信する（ブロック５２６）。この１８Ｘは、１８０呼出音メッセージ、１８１呼転送中メッセージ、１８２待ち行列メッセージ、あるいは１８３セッション進行中メッセージで良い。ユーザエージェント１９２がインバイトメッセージを受信した後の最適メッセージは、１８０呼出音メッセージであり、発信した公衆交換電話網１３４に対し、送信パスが確立したことを知らせる。１８Ｘメッセージの詳細は、前記文書「ＩＳＵＰからＳＩＰへのマッピング」に記載されている。
【００５５】
次にセッションルータ１６２は、１８Ｘメッセージを信号ゲートウエイ１５２へ送信する（ブロック５２８）。前記した通り、この１８Ｘメッセージは１８０呼出音メッセージである。１８Ｘメッセージを信号ゲートウエイ１５２が受信すると、アドレス完了メッセージ（ＡＣＭ）を公衆交換電話網１３４へ送信する。
【００５６】
信号ゲートウエイ１５２は、１８Ｘメッセージを受信すると、ＰＲＡＣＫメッセージをユーザエージェント１９２へ送信し（ブロック５３２）、１８Ｘメッセージの受信を確認する。当業者に知られている通り、ＰＲＡＣＫメッセージは、ＳＩＰ信号方式メッセージである。ＰＲＡＣＫメッセージは、最初にセッションルータ１６２が受信し、次にセッションルータ１６２からユーザエージェント１９２へ送られる。
【００５７】
ユーザエージェント１９２がＰＲＡＣＫメッセージを受信すると、ＰＲＡＣＫメッセージは確認される。ユーザエージェント１９２は、呼に応答して２００ＯＫメッセージをセッションルータ１６２へ送信すると共に、ユーザエージェント１９２が公衆交換電話網１３４からのマルチメディア送信受け取り用に指定したセッション記述プロトコルアドレスおよびポートを送信する。オープン／バインドメッセージをセッションルータ１６２からメディアルータ１６４へ送信し（ブロック５３６）、公衆交換電話網１３４によるリアルタイムプロトコル送信に割り当てるメディアルータアドレスおよびポートを要求する。メディアルータ１６４は、メディアルータ１６４内にメディアアドレスおよびポートを開いて割り当て、公衆交換電話網１３４からのマルチメディア送信中、これらアドレスおよびポートに対してリアルタイムプロトコルマルチメディアパケットが送信されるようにする。応答をセッションルータ１６２へ送信し、セッションルータ１６２へ今割り当てたメディアルータアドレスおよびポートアドレスを提供する（ブロック５３８）。
【００５８】
図４Ｂの続きである図４Ｃに示す通り、セッションルータ１６２は、２００ＯＫメッセージを信号ゲートウエイ１５２へ送信し、割り当てたメディアルータアドレスおよびポートを特定する（ブロック５４２）。次に信号ゲートウエイ１５２は、アンサメッセージ（ＡＮＭ）を公衆交換電話網１３４へ送信し（ブロック５４４）、公衆交換電話網１３４に対し、公衆交換電話網１３４からユーザエージェント１９２へ送信するリアルタイムプロトコルマルチメディアパケット用受信パスの確立を知らせる。
【００５９】
リアルタイムプロトコルマルチメディアパケットを公衆交換電話網１３４からユーザエージェント１９２へ送信する（ブロック５４６）。この送信は、公衆交換電話網１３４がまずマルチメディアをメディアゲートウエイ１４２，１４４へ送ることにより行われる。次にメディアゲートウエイ１４２，１４４は、マルチメディアを時分割多重フォーマットからリアルタイムプロトコルフォーマットへ変換し、そのマルチメディアに割り当てられたメディアルータアドレスおよびポートを介してメディアルータ１６４へそれを送信する。次にマルチメディアは、指定されたセッション記述プロトコルアドレスおよびポートに基づき、ユーザエージェント１９２へ送信される。
【００６０】
信号ゲートウエイ１５２は、肯定応答メッセージをユーザエージェント１９２へ送信し、マルチメディア送信用アドレスを受信したことを確認する（ブロック５４８）。当業者に知られている通り、肯定応答メッセージは、ＳＩＰ信号方式メッセージである。この肯定応答メッセージは、まずセッションルータ１６２が受信し、そこからユーザエージェント１９２へ送られる。
【００６１】
図５は、図４Ａ，４Ｂ，４Ｃのフローチャートが説明する呼処理の詳細を示すブロック図である。図５に示す通り、公衆交換電話網１３４は、初期アドレスメッセージを信号ゲートウエイ１５２へ送信する（参照矢印２０２）。その後信号ゲートウエイ１５２は、インバイトメッセージをセッションルータ１６２へ送信する（参照矢印２０４）。これに応答してセッションルータ１６２は、１００トライングメッセージを信号ゲートウエイ１５２へ返信する（参照矢印２０６）。次にオープン／バインドメッセージをセッションルータ１６２からメディアルータ１６４へ送信する（参照矢印２０８）。その後メディアルータ１６４が応答する（参照矢印２１２）。次にインバイトメッセージをセッションルータ１６２からユーザエージェント１９２へ送信する（参照矢印２１４）。次にユーザエージェント１９２は、１８Ｘメッセージをセッションルータ１６２へ送信する（参照矢印２１６）。それに応答してセッションルータ１６２は、１８Ｘメッセージを信号ゲートウエイ１５２へ送信する（参照矢印２１８）。次にアドレス完了メッセージを信号ゲートウエイ１５２から公衆交換電話網１３４へ送信する（参照矢印２２２）。その後ＰＲＡＣＫメッセージを信号ゲートウエイ１５２からセッションルータ１６２へ送信し（参照矢印２２４）、次にセッションルータ１６２からユーザエージェント１９２へ送信する（参照矢印２２６）。
【００６２】
次にユーザエージェント１９２は、２００ＯＫメッセージをセッションルータ１６２へ送信する（参照矢印２２８）。セッションルータ１６２は、オープン／バインド要求をメディアルータ１６４へ送信する（参照矢印２３２）。その後回答をセッションルータ１６２へ返信する（参照矢印２３４）。次に２００ＯＫメッセージをセッションルータ１６２から信号ゲートウエイ１５２へ送信する（参照矢印２３６）。その後信号ゲートウエイ１５２は、アンサメッセージを公衆交換電話網１３４へ送信する（参照矢印２３８）。次に肯定応答メッセージを信号ゲートウエイ１５２からセッションルータ１６２へ送信する（参照矢印２４２）。その後肯定応答メッセージをセッションルータ１６２からユーザエージェント１９２へ送信する（参照矢印２４４）。
【００６３】
呼の解除は、異なる３つの方法の少なくとも１つによって生じ、ＩＰ網１３６またはＩＳＵＰ網１３３のどちらが呼を開始したかに関わりなく生じる。呼の解除の第１の方法は、公衆交換電話網１３４のハングアップ（発呼者ハングアップ）である。呼の解除の第２の方法は、ユーザエージェント１９２のハングアップ（被発呼者ハングアップ）である。呼の解除の第３の方法は、メディアルータ１６４のハングアップである。なお呼の解除は、ここに説明した以外の方法で発生することもある。
【００６４】
呼の解除をユーザエージェントから開始する
図６は、公衆交換電話網１３４とユーザエージェント１９２間の呼の解除における一連の呼処理の例を示す。これはユーザエージェント１９２が開始する。図６に示すように、バイ（ＢＹＥ）メッセージをユーザエージェント１９２からセッションルータ１６２へ送信し（ブロック５６２）、公衆交換電話網１３４からユーザエージェント１９２への以前確立した接続の解放を要求する。これに応答してセッションルータ１６２は、解放要求をメディアルータ１６４へ送信し、メディアルータ１６４内に以前割り当てた２つのアドレスおよびポートの解放を要求する（ブロック５６４）。次にメディアルータ１６４は、応答メッセージをセッションルータ１６２へ送信し、以前割り当てた２つのメディアルータ１６４アドレスおよびポートの解放を確認する（ブロック５６６）。
【００６５】
バイメッセージをセッションルータ１６２から信号ゲートウエイ１５２へ送信する（ブロック５６８）。信号ゲートウエイ１５２は、バイメッセージの受信を確認する２００ＯＫメッセージをセッションルータ１６２へ返信する（ブロック５７２）。次に２００ＯＫメッセージをセッションルータ１６２からユーザエージェント１９２へ送信し（ブロック５７４）、ユーザエージェントに対して、メディアルータ１６４、セッションルータ１６２、信号ゲートウエイ１５２内の全ての資源が利用可能であることを確認する。次に解放メッセージを信号ゲートウエイ１５２から公衆交換電話網１３４へ送信し、マルチメディアの時分割多重フォーマット送信に使用したベアラチャネルの解放を要求する（ブロック５７６）。次に解放完了（ＲＬＣ）メッセージを信号ゲートウエイ１５２へ送信し（ブロック５７８）、ＩＳＵＰ網１３３内の資源の解放を確認する。
【００６６】
図７は、図６のフローチャートで説明した呼処理をさらに示す図である。図７に示す通り、バイメッセージをユーザエージェント１９２からセッションルータ１６２へ送信する（参照矢印２５２）。これに応答してセッションルータ１６２は、解放要求をメディアルータ１６４へ送信する（参照矢印２５４）。次にメディアルータ１６４は、応答メッセージをセッションルータ１６２へ送信する（参照矢印２５６）。
【００６７】
次にバイメッセージをセッションルータ１６２から信号ゲートウエイ１５２へ送信する（参照矢印２５８）。信号ゲートウエイ１５２は、バイメッセージの受信確認のため、２００ＯＫメッセージをセッションルータ１６２へ返信する（参照矢印２６２）。次に２００ＯＫメッセージをセッションルータ１６２からユーザエージェント１９２へ送信する（参照矢印２６４）。次に解放メッセージを信号ゲートウエイ１５２から公衆交換電話網１３４へ送信する（参照矢印２６６）。最後に解放完了メッセージ（ＲＬＣ）を公衆交換電話網１３４から信号ゲートウエイ１５２へ送信する（参照矢印２６８）。
【００６８】
呼の解除を公衆交換電話網から開始する
図８は、公衆交換電話網１３４とユーザエージェント１９２間における呼の解除を公衆交換電話網１３４から開始する一連の呼処理を示すフローチャートである。図８に示すように、呼の解除は、公衆交換電話網１３４から信号ゲートウエイ１５２へ送信する解放メッセージによって開始する（ブロック５９２）。この解放メッセージを受信すると、信号ゲートウエイ１５２は、バイ（ＢＹＥ）メッセージをセッションルータ１６２へ送信し（ブロック５９４）、公衆交換電話網１３４からユーザエージェント１９２へ以前確立した接続の解放を要求する。
【００６９】
次に解放要求をセッションルータ１６２からメディアルータ１６４へ送信し（ブロック５９６）、以前確立したリアルタイムプロトコルマルチメディアフローをメディアルータアドレスとポートとを解放することにより切断することを要求する。次にメディアルータ１６４は、応答メッセージをセッションルータ１６２へ送信し、以前割り当てた２つのメディアルータ１６４のアドレスおよびポートの解放を確認する（ブロック５９８）。次にバイメッセージをセッションルータ１６２からユーザエージェント１９２へ送信する（ブロック６０２）。これにより以前確立した公衆交換電話網１３４からユーザエージェント１９２への接続の解放を要求する。
【００７０】
次にユーザエージェント１９２は、バイメッセージの受信を確認するため、２００ＯＫメッセージをセッションルータ１６２へ返信する（ブロック６０４）。また２００ＯＫメッセージの送信は、セッションルータ１６２に、ユーザエージェント１９２内の全資源が将来において利用可能であることを知らせる。次に２００ＯＫメッセージをセッションルータ１６２から信号ゲートウエイ１５２へ送信し（ブロック６０６）、メディアルータ１６４、セッションルータ１６２、ユーザエージェント１９２内の全資源が利用可能であることを確認する。次に信号ゲートウエイ１５２、セッションルータ１６２、メディアルータ１６４、ユーザエージェント１９２内の資源解放を確認するため、解放完了（ＲＬＣ）メッセージを信号ゲートウエイ１５２から公衆交換電話網１３４へ送信する（ブロック６０８）。
【００７１】
図９は、図８の呼処理をさらに示すブロック図である。図９に示す通り、解放メッセージを公衆交換電話網１３４から信号ゲートウエイ１５２へ送信する（参照矢印２８２）。この解放メッセージを受信すると、信号ゲートウエイ１５２は、バイメッセージをセッションルータ１６２へ送信する（参照矢印２８４）。
【００７２】
解放要求をセッションルータ１６２からメディアルータ１６４へ送信する（参照矢印２８６）。次にメディアルータ１６４は、応答メッセージをセッションルータ１６２へ送信する（参照矢印２８８）。次にセッションルータ１６２は、バイメッセージをユーザエージェント１９２へ送信する（参照矢印２９２）。次にユーザエージェント１９２は、２００ＯＫメッセージをセッションルータ１６２へ送信する（参照矢印２９４）。次にセッションルータ１６２は、２００ＯＫメッセージを信号ゲートウエイ１５２へ送信する（参照矢印２９６）。次に信号ゲートウエイ１５２は、解放完了メッセージを公衆交換電話網１３４へ送信する（参照矢印２９８）。
【００７３】
呼の解除をメディアルータから開始する
図１０は、メディアルータ１６４が開始する、公衆交換電話網１３４とユーザエージェント１９２間の呼の解除に関する一連の呼処理を示すフローチャートである。図１０に示す通り、メディアルータ１６４は、呼の解除要求を開始し、それをセッションルータ１６２へ送信する（ブロック６１２）。メディアルータ１６４は、この呼の解除要求に加え、メディアルータアドレスおよびポートを解放する。前記呼の解除要求は、セッションルータ１６２へ送る。この理由は、セッションルータ１６２が改良通信網１３２内の信号を管轄するからである。従ってセッションルータ１６２は、公衆交換電話網１３４およびユーザエージェント１９２間の通信に関する信号を停止できる。
【００７４】
次にセッションルータ１６２は、応答メッセージをメディアルータ１６４へ送信し（ブロック６１４）、公衆交換電話網１３４とユーザエージェント１９２間の通信に関する信号を停止する要求を受け取ったことを確認する。次にセッションルータ１６２は、バイメッセージをユーザエージェント１９２と信号ゲートウエイ１５２へ送信し（ブロック６１６）。公衆交換電話網１３４からユーザエージェント１９２へ、およびユーザエージェント１９２から公衆交換電話網１３４へ以前確立した接続の解放を要求する。これらバイメッセージは、同時送信しても良く、あるいは１つずつ送信しても良い。バイメッセージ間の送信順序を異ならせ、ユーザエージェントへのバイメッセージを最初に送信しても良く、信号ゲートウエイ１５２へのバイメッセージを最初に送信しても良く、両方のバイメッセージを同時に送信しても良い。言い換えれば、バイメッセージのユーザエージェント１９２および信号ゲートウエイ１５２への送信は、２つの異なる処理であり互いに独立している。
【００７５】
次にユーザエージェント１９２は、バイメッセージの受信を確認するため、２００ＯＫメッセージをセッションルータ１６２へ返信する（ブロック６１８）。さらにこの２００ＯＫメッセージの送信は、セッションルータ１６２に対し、ユーザエージェント１９２内の全資源が将来において利用可能であることを知らせる。また信号ゲートウエイ１５２は、２００ＯＫメッセージをセッションルータ１６２へ送信する（ブロック６２２）。この送信は、バイメッセージの受信に応答して行い、信号ゲートウエイ１５２内の資源利用可能性を知らせる。なお２００ＯＫメッセージの送信順序は、やはり異ならせることができる。
【００７６】
次に信号ゲートウエイ１５２は、解放メッセージを公衆交換電話網１３４へ送信し（ブロック６２４）、マルチメディアの時分割多重フォーマット送信に使用したベアラチャネルの解放を要求する。次に公衆交換電話網１３４内の資源解放を確認するため、解放完了メッセージを公衆交換電話網１３４から信号ゲートウエイへ送信する（ブロック６２６）。
【００７７】
図１１は、図１０に示した呼処理をさらに示すブロック図である。図１１に示す通り、メディアルータ１６４は、呼の解除要求を開始し、その要求をセッションルータ１６２へ送信する（参照矢印３０２）。この呼の解除要求に加え、メディアルータ１６４は、メディアルータアドレスおよびポートを解放する。次にセッションルータ１６２は、応答メッセージをメディアルータ１６４へ送信し、公衆交換電話網１３４とユーザエージェント１９２間の通信に関連する信号を停止するための前記要求の受信を確認する（参照矢印３０４）。次にバイメッセージをユーザエージェント１９２と（参照矢印３０６）、信号ゲートウエイ１５２（参照矢印３０８）とへ送信する。
【００７８】
ユーザエージェント１９２は、バイメッセージの受信を確認するため、２００ＯＫメッセージをセッションルータ１６２へ返信する（参照矢印３１２）。また信号ゲートウエイ１５２は、２００ＯＫメッセージをセッションルータ１６２へ送信する（参照矢印３１４）。次に信号ゲートウエイ１５２は、解放メッセージを公衆交換電話網１３４へ送信する（参照矢印３１６）。公衆交換電話網１３４内の資源解放を確認するため、解放完了メッセージを公衆交換電話網１３４から信号ゲートウエイへ送信する（参照矢印３１８）。
【００７９】
ユーザが開始する呼設定
図１２Ａ，１２Ｂ，１２Ｃは、ユーザエージェント１９２が開始する呼設定および実行に関する一連の呼処理を示すフローチャートである。これは、ユーザエージェント１９２と公衆交換電話網１３４間において、セッションルータ１６２，信号ゲートウエイ１５２，メディアルータ１６４を介して行われる。なお信号ゲートウエイ１５２内に存在するメモリは、信号ゲートウエイ１５２の開始前に、公衆交換電話網チャネルまたは回線、アドレス、およびチャネル状態をあらかじめプログラムしておく。このメモリは、改良通信網１３２の使用中、公衆交換電話網チャネル状態を監視し、どの公衆交換電話網チャネルまたは通信パスが使用可能であるかを追跡する。使用可能状態は３つあり、「動作中、未使用」、「動作中、使用中」、「使用不能」である。前記した通り、回線識別コードは、公衆交換電話網１３４が通信に使用するチャネルまたは回線を識別する。例えばＴ１接続が２４回線を有していれば、２４個の回線識別コードがあり、これらは順次番号が付けられ、現在の状態に関連付けられる。
【００８０】
図１２Ａに示す通り、ユーザエージェント１９２は、ＳＩＰインバイトメッセージをセッションルータ１６２へ送信する（ブロック６３２）。このインバイトメッセージは、現在の呼に割り当てたユーザエージェント１９２のＩＰアドレスを識別する「フロムアドレス」と、現在の呼に割り当てたユーザエージェント１９２のポートを識別するＩＰポートと、公衆交換電話網１３４内の送信先アドレスを識別する「ツーアドレス」とを識別する。次に１００トライング（ＴＲＹＩＮＧ）メッセージをセッションルータ１６２からユーザエージェント１９２へ送信し、インバイトメッセージの受信を確認する（ブロック６３４）。
【００８１】
次にセッションルータ１６２は、ＳＩＰインバイトメッセージを信号ゲートウエイ１５２へ送信する（ブロック６３６）。このインバイトメッセージは、現在の呼に割り当てたセッションルータ１６２のＩＰアドレスを識別する「フロムアドレス」と、公衆交換電話網１３４内の送信先ＩＰアドレスを識別する「ツーアドレス」とを識別する。なおオープン／バインドメッセージのメディアルータ１６４への送信は、セッションルータ１６２がインバイトメッセージを受信した直後には行われない。この理由は、公衆交換電話網内の回線が決定されていないからである。次に信号ゲートウエイ１５２は、１００トライングメッセージをセッションルータ１６２へ送信し、インバイトメッセージの受信を確認する（ブロック６３８）。
【００８２】
ブロック６４２に示すように、次に信号ゲートウエイ１５２は、メディアゲートウエイ１４２，１４４内の公衆交換電話網回線または回線識別コードを、ユーザエージェント１９２と公衆交換電話網１３４間に使用するため割り当てる。次に信号ゲートウエイ１５２は、そのメモリから空き回線識別コードを選択し、ユーザエージェント１９２と公衆交換電話網１３４間のメディア送信に使用させる。空き回線識別コードを割り当てるには、異なる方法を用いることができる。１例として、メモリ内に空きとしてリストされている最初の回線識別コードを選択することができる。他の方法は、順次方法である。これは、各空き回線識別コードを順次選択し、各回線識別コードの選択を時間的に均等にする。もちろん他の選択方法を利用しても構わない。また選択した回線識別コードに関連するＩＰポートおよびアドレスは、前記表１を利用して決定する。
【００８３】
次に信号ゲートウエイ１５２は、オープン／バインドメッセージをメディアルータ１６４へ送信し（ブロック６４４）、ユーザエージェント１９２から公衆交換電話網１３４へのリアルタイムプロトコルマルチメディアパケット送信、および公衆交換電話網１３４の応答中に公衆交換電話網１３４からユーザエージェント１９２への送信に使用するメディアルータアドレスおよびポートを要求する。なおユーザエージェント１９２が開始したリアルタイムプロトコル送信に割り当てるＩＰアドレスとポートとは、公衆交換電話網１３４応答に割り当てるものと同一ＩＰアドレスおよびポートであっても良い。次にメディアルータ１６４は、ユーザエージェントリアルタイムプロトコル送信用にメディアルータ１６４内のＩＰアドレスおよびポートを開き割り当てる。なお単一のオープン／バインド要求のみで十分である。この理由は、信号ゲートウエイ１５２がこの時点における全アドレスを知っているからである。これは、２つの異なるオープン／バインド要求を使用する前記例とは異なる。
【００８４】
応答を信号ゲートウエイ１５２へ送信し、今割り当てたメディアルータアドレスおよびポートアドレスを信号ゲートウエイ１５２に提供する（ブロック６４６）。次に信号ゲートウエイ１５２は、受信したＳＩＰインバイトメッセージを、ユーザエージェント１９２と公衆交換電話網１３４とを識別する初期アドレスメッセージへマップし、その初期アドレスメッセージを公衆交換電話網１３４へ送信する（ブロック６４８）。先に選択した空き回線識別コードも初期アドレスメッセージにおいて公衆交換電話網１３４へ送信し、ユーザエージェント１９２と公衆交換電話網１３４間の信号に使用する回線識別コードを指定する。この時点でマルチメディアパスが、信号ゲートウエイ１５２からユーザエージェント１９２へ開かれる。
【００８５】
図１２Ａの続きである図１２Ｂに示すように、次に公衆交換電話網１３４は、回線識別コード、フロムアドレス、ポートが呼設定に十分であることを示すため、アドレス完了メッセージを信号ゲートウエイ１５２へ送る（ブロック６５２）。この時点で公衆交換電話網１３４は、確立した回線識別コード回線を経由して鳴動音をメディアゲートウエイへ送信する。
【００８６】
次に信号ゲートウエイ１５２は、１８Ｘメッセージをセッションルータ１６２へ送信する（ブロック６５４）。前記した通り、１８Ｘは１８０呼出音メッセージ、１８１呼転送中メッセージ、１８２待ち行列メッセージ、あるいは１８３セッション進行中メッセージで良い。信号ゲートウエイ１５２のアドレス完了メッセージ受信後に最適であるのは、１８０呼出音メッセージであり、これによって発信ユーザエージェント１９２に対し、送信パスが確立したことを知らせる。
【００８７】
次にセッションルータ１６２は、１８Ｘメッセージをユーザエージェント１９２へ送信し、ユーザエージェントは呼出音を受信する（ブロック６５６）。前記した通り、１８Ｘメッセージは１８０呼出音メッセージである。１８Ｘメッセージを受信すると、ユーザエージェント１９２は、ＰＲＡＣＫメッセージを公衆交換電話網１３４に返信し、１８Ｘメッセージの受信を確認する。ＰＲＡＣＫメッセージは、まずセッションルータ１６２が受信し（ブロック６５８）、次にセッションルータ１６２から信号ゲートウエイ１５２へ転送される（ブロック６６２）。
【００８８】
公衆交換電話網１３４は、呼に応答し、アンサ（ＡＮＳＷＥＲ）メッセージを信号ゲートウエイ１５２へ送信する（ブロック６７２）。信号ゲートウエイ１５２は、アンサメッセージに付随する回線識別コードを読むことにより、アンサメッセージがどの呼に応答しているかを決定できる。信号ゲートウエイ１５２は、割り当てたポートに前記アンサメッセージを受信すると、２００ＯＫメッセージをセッションルータ１６２へ送信する（ブロック６７４）。
【００８９】
図１２Ｂの続きである図１２Ｃに示す通り、次にセッションルータ１６２は、２００ＯＫメッセージを以前指定したユーザエージェントアドレスおよび決定したユーザエージェントポートへ送信し（ブロック６８２）、ユーザエージェント１９２から公衆交換電話網１３４、および公衆交換電話網１３４からユーザエージェント１９２への送信パスを完成する。従ってマルチメディアパケットの双方向送信が可能となる。次にユーザエージェント１９２は、肯定応答メッセージをセッションルータ１６２へ送信する（ブロック６８４）。その後肯定応答メッセージは、セッションルータ１６２から信号ゲートウエイ１５２へ送信する（ブロック６８６）。
【００９０】
図１３Ａは、図１２Ａのフローチャートで説明した呼処理をさらに示す。図１３Ａに示す通り、ユーザエージェント１９２は、ＳＩＰインバイトメッセージをセッションルータ１６２へ送信する（参照矢印３２２）。次にセッションルータ１６２は、１００トライングメッセージをユーザエージェント１９２へ送信し、インバイトメッセージの受信を確認する（参照矢印３２４）。次にＳＩＰインバイトメッセージをセッションルータ１６２から信号ゲートウエイ１５２へ送信する（参照矢印３２６）。次に１００トライングメッセージを信号ゲートウエイ１５２からセッションルータ１６２へ送信し、インバイトメッセージの受信を確認する（参照矢印３２８）。
【００９１】
次に信号ゲートウエイ１５２は、オープン／バインドメッセージをメディアルータ１６４へ送信する（参照矢印３３２）。次に応答を信号ゲートウエイ１５２へ送信し、今割り当てたメディアルータアドレスおよびポートアドレスを信号ゲートウエイ１５２に提供する（参照矢印３３４）。次に信号ゲートウエイ１５２は、初期アドレスメッセージを公衆交換電話網１３４へ送信する（参照矢印３３６）。次に公衆交換電話網１３４は、アドレス完了メッセージを信号ゲートウエイ１５２へ送る（参照矢印３３８）。この時公衆交換電話網１３４は、確立した回線識別コード回線を経由して呼出音をメディアゲートウエイへ送信する（参照矢印３４２）。
【００９２】
次に信号ゲートウエイ１５２は、１８Ｘメッセージをセッションルータ１６２へ送信する（参照矢印３４４）。次にセッションルータ１６２は、１８Ｘメッセージをユーザエージェント１９２へ送信する（参照矢印３４６）。次にユーザエージェント１９２は、ＰＲＡＣＫメッセージをセッションルータ１６２へ送信する（参照矢印３４８）。その後ＰＲＡＣＫメッセージは、セッションルータ１６２から信号ゲートウエイ１５２へ転送する（参照矢印３５２）。
【００９３】
図１３Ｂは、図１２Ｂおよび図１２Ｃのフローチャートで説明した呼処理をさらに示すブロック図である。図１３Ｂに示す通り、公衆交換電話網１３４は、公衆交換電話網１３４ユーザが呼に応答すると、アンサメッセージを信号ゲートウエイ１５２へ送信する（参照矢印３６２）。割り当てたポートにアンサメッセージを受信すると、信号ゲートウエイ１５２は、２００ＯＫメッセージをセッションルータ１６２へ送信する（参照矢印３６４）。次にセッションルータ１６２は、２００ＯＫメッセージを以前指定したユーザエージェントアドレスおよび決定したユーザエージェントポートへ送信する（参照矢印３７２）。次にユーザエージェント１９２は、肯定応答メッセージをセッションルータ１６２へ送信する（参照矢印３７４）。その後肯定応答メッセージは、セッションルータ１６２から信号ゲートウエイ１５２へ送信する（参照矢印３７６）。
【００９４】
本発明の通信網１３２は、ソフトウエア、ファームウエア、ハードウエア、あるいはそれらの組合せで実施できる。本発明の非限定的好適実施例において、通信網１３２の一部は、メディアルータ１６４が実行するソフトウエアにおいて実現できる。メディアルータ１６４は、コンピュータで良く、非限定的な例として、サーバ、パーソナルコンピュータ、ワークステーション、ミニコンピュータ、メインフレームコンピュータ等である。
【００９５】
改良通信網１３２のソフトウエア準拠部は、論理機能を実現するために実行可能な命令を順次記述したものであり、コンピュータ読み取り可能媒体において実施できる。この媒体を使用するまたは関連するのは、命令実行システム、装置、デバイス等であり、例えばコンピュータベースシステムプロセッサを含むシステムや、前記命令実行システム、装置、デバイス等から命令を取り出し実行するシステムである。本明細書において「コンピュータ読み取り可能媒体」は、プログラムを格納、保存、通信、伝送、搬送でき、命令実行システム、装置、デバイス等によって使用可能なあらゆる手段である。
【００９６】
例えばコンピュータ読み取り可能媒体は、電子、磁気、光学、電磁、赤外、または半導体のシステム、装置、または伝搬媒体である。コンピュータ読み取り可能媒体のさらに具体的な例は（全てを示すものではない）次を含む。１本以上のワイヤを含む電気接続（電子）、携帯コンピュータディスケット（磁気）、ランダムアクセスメモリ（ＲＡＭ）（磁気）、リードオンリーメモリ（ＲＯＭ）（磁気）、消去可能プログラマブルリードオンリーメモリ（ＥＰＲＯＭまたはフラッシュメモリ）（磁気）、光ファイバ（光学）、携帯コンパクトディスクリードオンリーメモリ（ＣＤ−ＲＯＭ）（光学）である。なおコンピュータ読み取り可能媒体は、紙等のプログラムを印刷する適切な媒体でも良い。なぜならプログラムは、例えば紙等の媒体を光学走査して電子的に捕捉し、それを必要に応じ適切な方法で編集、変換、処理し、コンピュータメモリに格納できるからである。
【００９７】
強調しなければならないことは、本発明の前記実施例、特に「好適」実施例は、単に実施可能な例に過ぎず、単に本発明の原理を明解にするために提示したに過ぎない。本発明の前記実施例には、本発明の精神および原理を実質的に逸脱することなく、多くの変更および変形が可能である。かかる変更および変形の全ては、本開示の請求の範囲および本発明に含まれ、請求の範囲によって保護されるべきものである。
【図面の簡単な説明】
【図１】図１は、従来の通信網のブロック図である。
【図２】図２は、本発明の好適実施例に基づく改良通信網を示すブロック図である。
【図３】図３は、図２の改良通信網で使用するメディアルータを示すブロック図である。
【図４Ａ】図４Aは、公衆交換電話網の発呼設定および実行における一連の呼処理を示すフローチャートである。
【図４Ｂ】図４Bは、図４Ａの続きである。
【図４Ｃ】図４Cは、図４Ｂの続きである。
【図５】図５は、図４Ａ，４Ｂ，４Ｃのフローチャートに示す呼処理をさらに示すブロック図である。
【図６】図６は、図２の公衆交換電話網とユーザエージェント間においてユーザエージェントが開始する呼の解除における一連の呼処理を示すフローチャートである。
【図７】図７は、図６のフローチャートが示す呼処理をさらに示すブロック図である。
【図８】図８は、図２の公衆交換電話網とユーザエージェント間において公衆交換電話網が開始する呼の解除における一連の呼処理を示すフローチャートである。
【図９】図９は、図８のフローチャートが示す呼処理をさらに示すブロック図である。
【図１０】図１０は、図２の公衆交換電話網とユーザエージェント間において図３のメディアルータが開始する呼の解除における一連の呼処理を示すフローチャートである。
【図１１】図１１は、図１０のフローチャートが示す呼処理をさらに示すブロック図である。
【図１２Ａ】図１２Ａは、ユーザエージェントが開始する呼設定および実行における一連の呼処理を示すフローチャートである。
【図１２Ｂ】図１２Ｂは、図１２Ａの続きである。
【図１２Ｃ】図１２Ｃは、図１２Ｂの続きである。
【図１３Ａ】図１３Ａは、図１２Ａのフローチャートが示す呼処理をさらに示すブロック図である。
【図１３Ｂ】図１３Ｂは、図１２Ｂおよび図１２Ｃのフローチャートが示す呼処理をさらに示すブロック図である。

Claims (31)

1. 呼に関する信号を第１プロトコルから第２プロトコルへ前記第２プロトコルから前記第１プロトコルへ変換する信号ゲートウエイと、
   前記呼に関するマルチメディアパケットを第１フォーマットから第２フォーマットへ前記第２フォーマットから前記第１フォーマットへ変換する少なくとも１つのメディアゲートウエイと、
   前記メディアゲートウエイによる変換後、前記呼に関するマルチメディアパケットが送信先への途中で通過するメディアルータであって、前記メディアルータは、ユーザエージェントからマルチメディアパケットを受信するように動作し、受信したマルチメディアパケットを前記メディアゲートウエイに転送する前記メディアルータと、
   前記呼に関するマルチメディアパケットのために、交換網が指定する送信先を終端とし、前記メディアルータを経由する、少なくとも１つの送信経路を選択するセッションルータと、を備える
   交換網とパケット網間の通信を向上させるシステム。
2. 前記第１フォーマットは時分割多重フォーマットであり、前記第２フォーマットはリアルタイムプロトコルフォーマットである、請求項１記載のシステム。
3. 前記メディアゲートウエイは、前記マルチメディアの送信先を決定しない、請求項１記載のシステム。
4. 前記第１プロトコルはＳＳ７信号方式であり、前記第２プロトコルはセッションインターネットプロトコルである、請求項１記載のシステム。
5. 前記第２プロトコルは、リアルタイムプロトコルである、請求項１記載のシステム。
6. 前記パケット網はインターネットプロトコル網である、請求項１記載のシステム。
7. 前記交換網は公衆交換電話網である、請求項１記載のシステム。
8. 前記第１フォーマットは時分割多重フォーマットである、請求項１記載のシステム。
9. 前記第２フォーマットはリアルタイムプロトコルフォーマットである、請求項１記載のシステム。
10. 前記交換網は、ＳＳ７信号方式を使用して前記信号ゲートウエイと通信する、請求項１記載のシステム。
11. 前記信号ゲートウエイは、受信した回線識別コードをセッション記述プロトコルヘッダへ変換するために利用するメモリを備える、請求項１記載のシステム。
12. 前記セッション記述プロトコルヘッダは、前記パケット網に存在する前記送信先により利用され、データパケットを前記メディアゲートウエイへ向かわせる、請求項１１記載のシステム。
13. 前記セッション記述プロトコルヘッダは、前記送信先用インターネットプロトコルアドレスおよびポートから成る、請求項１１記載のシステム。
14. 前記セッションルータと前記信号ゲートウエイ間の通信は、セッションインターネットプロトコル信号方式を用いて行う、請求項１記載のシステム。
15. 初期アドレスメッセージを交換網から信号ゲートウエイへ送信し、
    前記信号ゲートウエイにおいて前記初期アドレスメッセージをセッションインターネットプロトコルインバイトメッセージへ変換し、
    前記インターネットプロトコルインバイトメッセージをセッションルータへ送信し、当該セッションルータにおいて前記インターネットプロトコルインバイトメッセージを分析して呼に関するマルチメディアパケットのためにユーザエージェントへの最適経路を決定し、
    前記セッションルータからの要求に応じ、前記ユーザエージェントから前記交換網への送信用に、メディアルータ内のメディアルータアドレスおよびポートを開き、
    前記呼に関するマルチメディアパケットを前記交換網からメディアゲートウエイに送信し、前記メディアゲートウエイにおいて、前記呼に関するマルチメディアパケットを第１フォーマットから第２フォーマットへ変換する各段階を備え、
    前記セッションルータによって決定された最適経路は、前記メディアゲートウエイによる変換後、前記呼に関するマルチメディアパケットが送信先への途中で通過するメディアルータであって、前記ユーザエージェントから前記呼に関するマルチメディアパケットを受信し、受信したマルチメディアパケットをメディアゲートウエイに転送する前記メディアルータを含む、
    交換網からパケット網内のユーザエージェントへの呼を確立するための方法。
16. 前記交換網は公衆交換電話網である、請求項１５記載の方法。
17. 前記初期アドレスメッセージは、前記交換網が前記ユーザエージェントとの通信用に予約したベアラチャネルを識別する回線識別コードを有する、請求項１５記載の方法。
18. 前記初期アドレスメッセージは、発呼者と被呼者と回線識別コードとに関する情報から成り、当該情報は前記信号ゲートウエイがフロムヘッダとツーヘッダとセッション記述プロトコルヘッダとに各々変換する、請求項１５記載の方法。
19. 前記セッション記述プロトコルヘッダは、マルチメディアを送信するための前記ユーザエージェント用インターネットプロトコルアドレスおよびポートから成る、請求項１８記載の方法。
20. 前記メディアルータアドレスおよびポートから成る前記インバイトメッセージを前記セッションルータから前記ユーザエージェントへ送信すると共に、前記ユーザエージェントと通信するために前記交換網が予約するベアラチャネルを識別するための回線識別コードを送信することにより、前記ユーザエージェントに前記交換網との通信機能を提供する段階をさらに備える、請求項１５記載の方法。
21. 前記交換網が送信するマルチメディアを受け取るために前記ユーザエージェント内にユーザエージェントアドレスおよびポートを指定し、
    前記交換網が送信する前記マルチメディアを受け取るための第２アドレスおよび第２ポートを指定し、
    前記第２アドレスおよび第２ポートを前記信号ゲートウエイへ送信し、
    前記第２アドレスおよび第２ポートと前記ユーザエージェントアドレスおよびポートとを前記信号ゲートウエイへ送信する各段階をさらに備える、請求項２０記載の方法。
22. 前記マルチメディアを前記交換網からメディアゲートウエイへ送信し、
    前記マルチメディアを第１フォーマットから第２フォーマットへ変換し、
    前記マルチメディアを前記メディアルータへ前記指定した第２アドレスおよび第２ポートを介して送信し、
    前記マルチメディアを前記ユーザエージェントへ前記指定したユーザエージェントアドレスおよびポートを介して送信する各段階をさらに備える、請求項２１記載の方法。
23. パケット網内に位置するユーザエージェントと交換網間の呼に関する接続を前記ユーザエージェントから中断する方法において、
    前記接続の中断を前記交換網に要求し、当該ユーザエージェント要求をセッションルータへ送信し、前記セッションルータは前記ユーザエージェントへの少なくとも１つのマルチメディア送信経路を選択でき、前記選択されたマルチメディア送信経路は、前記ユーザエージェントからマルチメディアパケットを受信し、受信したマルチメディアパケットをメディアゲートウエイに転送するメディアルータを含み、
    前記接続の中断を要求し、当該セッションルータ要求をメディアルータへ送信し、前記メディアルータは前記ユーザエージェントへ前記呼に関するマルチメディアパケットを導くことができ、
    前記ユーザエージェントと前記交換網間の前記接続を提供するために使用した少なくとも１つの以前確立したアドレスおよびポートを解放する各段階を備える、前記方法。
24. 前記中断を前記交換網へ送信する段階をさらに備え、それに応答して前記交換網は、前記ユーザエージェントと前記交換網間の前記接続を提供するために使用したベアラチャネルを解放する、請求項２３記載の方法。
25. パケット網内に位置するユーザエージェントと交換網間の呼に関する接続を前記交換網から中断する方法において、
    前記ユーザエージェントと前記交換網間の前記接続の中断を要求し、当該交換網要求を信号ゲートウエイへ送信し、前記信号ゲートウエイは信号を第１プロトコルから第２プロトコルへおよび前記第２プロトコルから前記第１プロトコルへ変換でき、
    前記接続の中断を要求し、当該信号ゲートウエイ要求をセッションルータへ送信し、前記セッションルータは前記ユーザエージェントへの少なくとも１つのマルチメディア送信経路を選択でき、前記選択されたマルチメディア送信経路は、前記ユーザエージェントから前記呼に関するマルチメディアパケットを受信し、受信したマルチメディアパケットをメディアゲートウエイに転送するメディアルータを含み、
    前記接続の中断を要求し、前記セッションルータ要求をメディアルータへ送信し、前記メディアルータは前記ユーザエージェントへ前記呼に関するマルチメディアパケットを導くことができ、
    前記ユーザエージェントと前記交換網間の前記接続を提供するために使用した少なくとも１つの以前確立したアドレスおよびポートを解放する各段階を備える、前記方法。
26. 前記第１プロトコルはＳＳ７信号方式であり、前記第２プロトコルはセッションインターネットプロトコルである、請求項２５記載の方法。
27. パケット網内に位置するユーザエージェントと交換網間の呼に関する接続をメディアルータから中断する方法において、前記メディアルータはマルチメディアを前記ユーザエージェントへ導くことができ、
    前記ユーザエージェントと前記交換網間の前記接続の中断を要求し、当該メディアルータ要求をセッションルータへ送信し、前記セッションルータは前記ユーザエージェントへの少なくとも１つのマルチメディア送信経路を選択でき、前記選択されたマルチメディア送信経路は、前記ユーザエージェントから前記呼に関するマルチメディアパケットを受信し、受信したマルチメディアパケットをメディアゲートウエイに転送するメディアルータを含み、
    前記ユーザエージェントと前記交換網間の前記接続を提供するために使用した少なくとも１つの以前確立したアドレスおよびポートを解放し、
    前記交換網と前記ユーザエージェント間の通信に関連する信号を中断する各段階を備える、前記方法。
28. ユーザエージェントから交換網への呼を確立する方法において、前記ユーザエージェントはパケット網内に位置して前記呼を開始し、
    インバイトメッセージを前記ユーザエージェントからセッションルータへ送信し、前記セッションルータは前記呼のために前記ユーザエージェントへの少なくとも１つのマルチメディア送信経路を選択でき、前記選択されたマルチメディア送信経路は、前記ユーザエージェントからマルチメディアパケットを受信し、受信したマルチメディアパケットをメディアゲートウエイに転送するメディアルータを含み、前記インバイトメッセージはフロムアドレスと前記交換網内の送信先アドレスとを提供し、
    前記セッションルータのインターネットプロトコルアドレスと前記交換網内の前記送信先アドレスとを識別するインバイトメッセージを信号ゲートウエイへ送信し、前記信号ゲートウエイは信号を第１プロトコルから第２プロトコルへおよび前記第２プロトコルから前記第１プロトコルへ変換でき、
    前記ユーザエージェントと前記交換網間の前記マルチメディアの送信に当てられる前記メディアルータ内のアドレスおよびポートに対する要求を送信し、
    前記呼のためのユーザエージェントマルチメディアパケット送信用前記メディアルータ内アドレスおよびポートを割り当てる各段階を備える、前記方法。
29. 前記フロムアドレスは、前記ユーザエージェントのインターネットプロトコルアドレスおよびポートをさらに含む、請求項２８記載の方法。
30. 前記ユーザエージェントと前記交換網間においてマルチメディアを送信するためメディアゲートウエイ内に回線を割り当てる段階をさらに備え、前記メディアゲートウエイはマルチメディアを第１フォーマットから第２フォーマットへおよび前記第２フォーマットから前記第１フォーマットへ変換できる、請求項２８記載の方法。
31. 前記第１プロトコルはＳＳ７信号方式であり、前記第２プロトコルはセッションインターネットプロトコルである、請求項２８記載の方法。

Images