JP5169362B2 - セッション情報複製方法、前記方法を実行する呼制御サーバ及び前記方法のプログラム - Google Patents
セッション情報複製方法、前記方法を実行する呼制御サーバ及び前記方法のプログラム Download PDFInfo
- Publication number
- JP5169362B2 JP5169362B2 JP2008076330A JP2008076330A JP5169362B2 JP 5169362 B2 JP5169362 B2 JP 5169362B2 JP 2008076330 A JP2008076330 A JP 2008076330A JP 2008076330 A JP2008076330 A JP 2008076330A JP 5169362 B2 JP5169362 B2 JP 5169362B2
- Authority
- JP
- Japan
- Prior art keywords
- session
- call control
- media
- information
- terminal
- 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 - Fee Related
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/1046—Call controllers; Call servers
-
- 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/1069—Session establishment or de-establishment
-
- 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]
Description
本発明は、セッション情報複製方法、セッション情報複製方法を実行する呼制御サーバ及びセッション情報複製プログラムに関する。
ＷＷＷ（World Wide Web）による情報処理システムにおいては、例えばチケット購入サービスなど、一つのサービスが複数のリクエストにまたがって処理される。この場合、各リクエストがどのサービス処理状態に属するのかを明確にするために、セッションという機能が用いられる。サーバは、予約済み及び支払い済みなどのサービス処理状態、利用者のＩＤ（IDentifier）、住所、氏名、セッションＩＤなどのサービスで必要とされる情報を、セッション情報として保持する。クライアントは、各セッションのＩＤをリクエストに付加してサーバに送信する。これにより、サーバは、サービス処理状態を復元することが可能となる。例えばユーザが一旦ブラウザでの処理を終了しその後再開する場合、終了時のセッションＩＤに基づいてサービス処理状態を把握することで、既に入力した項目を自動で復元することができる。また、復元したサービス処理状態に不整合が発生することを防ぐこともできる。
このようなセッション機能を持つＷＷＷサーバの信頼性を上げるために、複数のWWWサーバがセッション情報を共有する構成が普及している。例えば、特許文献１には、クラスタを構成するすべてのアプリケーションサーバに各アプリケーションサーバのセッション情報を持たせる構成が開示されている。いずれかのサーバに障害が発生した場合、セッション情報を共有している他のサーバが継続処理を行う。
また、近年、WWWと同じＩＰ（Internet Protocol）技術により電話機能を実現するシステムが普及している。このシステムにはＳＩＰ（Session Initiation Protocol）というプロトコルが用いられており、ＳＩＰサーバ、発信端末及び着信端末間でメッセージを送受信することで発信端末及び着信端末間のメディアセッションを成立させる。メッセージにはセッション情報が含まれており、複数のＳＩＰサーバはセッション情報を複製し共有する。
特開2006-146663号公報
ここで、セッション情報はメッセージの送受信時に更新されるため、複数のＳＩＰサーバは、メッセージを送受信する全てのタイミングでセッション情報を複製して共有する。このようにセッション情報の複製はメッセージの送受信のたびに行われるため、複製処理が頻繁に行われ、それに伴う処理の負荷が大きくなるという問題がある。
特に網内発呼と呼ばれる呼接続形態では、端末とサーバとの間で仮のセッションを一旦成立させ、その後何度かのメッセージの交換を経て、端末の間で通話に用いるメディアデータを交換して通話が開始されるという手順を経る場合があり、上述の問題が大きい。
特に網内発呼と呼ばれる呼接続形態では、端末とサーバとの間で仮のセッションを一旦成立させ、その後何度かのメッセージの交換を経て、端末の間で通話に用いるメディアデータを交換して通話が開始されるという手順を経る場合があり、上述の問題が大きい。
そこで、本発明は、セッション情報の複製に伴う処理負荷を軽減することが可能な技術を提供することを目的とする。
発信端末及び着信端末間でメディアデータを送受信するためのメディアセッションを成立させる呼制御サーバが実行するセッション情報複製方法であって、以下のステップを含む。
・前記メディアセッションを成立させるための呼制御セッションにおいて、前記発信端末及び前記着信端末とメッセージの送受信を行う送受信ステップ。
・前記呼制御セッションの実行に必要なセッション情報を生成するセッション情報生成ステップ。
・前記メッセージに含まれる、メディアデータの送受信方法を定義したメディア情報を監視する監視ステップ。
・前記メディア情報の監視結果に基づいて、前記メディアセッションの成立又は不成立を判断する複製判断ステップ。
・前記メディアセッションが成立する場合、前記セッション情報を複製し、少なくとも１の他の呼制御サーバに送信する複製処理ステップ。
・前記メディアセッションを成立させるための呼制御セッションにおいて、前記発信端末及び前記着信端末とメッセージの送受信を行う送受信ステップ。
・前記呼制御セッションの実行に必要なセッション情報を生成するセッション情報生成ステップ。
・前記メッセージに含まれる、メディアデータの送受信方法を定義したメディア情報を監視する監視ステップ。
・前記メディア情報の監視結果に基づいて、前記メディアセッションの成立又は不成立を判断する複製判断ステップ。
・前記メディアセッションが成立する場合、前記セッション情報を複製し、少なくとも１の他の呼制御サーバに送信する複製処理ステップ。
発信端末、着信端末及び呼制御サーバ間では、メディアセッションを成立させるにあたって呼制御セッションが形成される。呼制御セッションでは、呼制御サーバを介して発信端末及び着信端末間で開始要求、応答及び確認など様々なメッセージが送受信される。上記セッション情報複製方法によれば、呼制御セッションに伴うメッセージの送受信のタイミングではなく、メディアセッションが成立した場合にセッション情報の複製及び送信を行う。よって、セッション情報の複製回数及び送信回数を抑制し、呼制御サーバの処理負荷を減らすことができる。また、セッション情報が頻繁に送受信されることによるネットワーク負荷を減らすことができる。
発信端末からメディアセッションの開始要求が送信されても、着信端末のユーザが不在である場合や他のユーザと通話中である場合などには、送受信端末間のメディアセッションは不成立となる。このような場合には、他の呼制御サーバは、複製されたセッション情報を受信しても利用しない場合がある。上記セッション情報複製方法によれば、送受信端末間のメディアセッションが成立した場合にセッション情報の複製及び送信を行う。よって、相手方の不在時や通話中などにおいて、呼制御サーバの無駄な処理及びリソースの無駄な消費を抑制することができる。
また、送受信端末間のメディアセッションの成立は、メディアデータの送受信方法を記述したメディア情報を参照して検出するため、メディアセッションの成立を確実に検出することができる。
本発明によれば、セッション情報の複製に伴う処理負荷を軽減することが可能な技術を提供することができる。
＜第１実施形態例＞
（１）全体構成
本実施形態では、ブラウザ端末からＩＰ（Internet Protocol）電話に発呼可能な網内発呼サービスを例に挙げて説明する。図１は、第１実施形態例に係るネットワーク構成図である。ユーザＡ側のクライアントＡはブラウザ端末Ａ及びＩＰ電話Ａ（alice@client1.test.co.jp）で構成され、ユーザＢ側のクライアントＢはブラウザ端末Ｂ及びＩＰ電話Ｂ（bob@client2.test.co.jp）で構成される。ブラウザ端末とは、例えばＷｅｂブラウザなど、Ｗｅｂページを閲覧するためのアプリケーションソフトが実装されている端末を言う。ＩＰ電話とは、インターネット網を介して通話が可能な電話を言う。図１に示すように、ＳＩＰ（Session Initiation Protocol）サーバＡ（www.test.co.jp）、ＳＩＰサーバＢ（www.test2.co.jp）、ブラウザ端末Ａ、ＩＰ電話Ａ、ブラウザ端末Ｂ及びＩＰ電話Ｂがインターネット１を介して接続されている。ＳＩＰサーバＡは以下では呼制御セッションを最初に行う主サーバである。ＳＩＰサーバＢは、ＳＩＰサーバＡとクラスタを構成するサーバであり、以下ではＳＩＰサーバＡで呼制御セッションが不可能になった場合に、ＳＩＰサーバＡに代わって呼制御セッションを行う代替サーバとなる。
（１）全体構成
本実施形態では、ブラウザ端末からＩＰ（Internet Protocol）電話に発呼可能な網内発呼サービスを例に挙げて説明する。図１は、第１実施形態例に係るネットワーク構成図である。ユーザＡ側のクライアントＡはブラウザ端末Ａ及びＩＰ電話Ａ（alice@client1.test.co.jp）で構成され、ユーザＢ側のクライアントＢはブラウザ端末Ｂ及びＩＰ電話Ｂ（bob@client2.test.co.jp）で構成される。ブラウザ端末とは、例えばＷｅｂブラウザなど、Ｗｅｂページを閲覧するためのアプリケーションソフトが実装されている端末を言う。ＩＰ電話とは、インターネット網を介して通話が可能な電話を言う。図１に示すように、ＳＩＰ（Session Initiation Protocol）サーバＡ（www.test.co.jp）、ＳＩＰサーバＢ（www.test2.co.jp）、ブラウザ端末Ａ、ＩＰ電話Ａ、ブラウザ端末Ｂ及びＩＰ電話Ｂがインターネット１を介して接続されている。ＳＩＰサーバＡは以下では呼制御セッションを最初に行う主サーバである。ＳＩＰサーバＢは、ＳＩＰサーバＡとクラスタを構成するサーバであり、以下ではＳＩＰサーバＡで呼制御セッションが不可能になった場合に、ＳＩＰサーバＡに代わって呼制御セッションを行う代替サーバとなる。
ＳＩＰとは、発信端末と着信端末との間で音声、画像及びテキストなどのメディアデータを送受信するためのメディアセッションを成立させたり、メディアセッションを終了させるなどの呼制御セッションを行うためのプロトコルである。ＳＩＰサーバは、発信端末及び着信端末との間で前述のような呼制御セッションを行うサーバであり、呼制御セッション中に、発信端末及び着信端末の各アドレスなど各種処理に必要なセッション情報を取得する。セッション情報は複製されて複数のＳＩＰサーバ間で共有される。
本実施形態では、クライアントＡからクライアントＢへの発呼を例に挙げて説明する。クライアントＡからクライアントＢへの発呼は次のようにして行われる。ユーザＡは、まず所定のアドレスをブラウザ端末Ａの画面に入力し、網内発呼サービスを起動させる。次に、ユーザＡは、網内発呼サービスの所定の画面において、ＩＰ電話Ａの電話番号と、相手方であるユーザＢのＩＰ電話Ｂの電話番号と、を入力し発呼を行う。ＳＩＰサーバＡは、クライアントＡからの発呼に基づいて呼制御セッションを行う。
（２）呼制御セッションの概要
図２は第1実施形態例に係る呼制御セッションを含むフローの一例である。クライアントＡのブラウザ端末Ａは、ユーザＡからの要求に応じて、発呼要求であるＧＥＴメソッドのＨＴＴＰ（Hypertext Transfer Protocol）リクエストをＳＩＰサーバＡに送信する（処理（１）参照）。このためＳＩＰサーバはＨＴＴＰサーバとしての機能を併せ持つものとする。このリクエストの送信はＨＴＴＰによって行われるため、下記のＳＩＰによる呼制御セッションと区別するためにＨＴＴＰセッションというものとする。なお発呼要求をＳＩＰサーバに伝える方法はＨＴＴＰでなくてもよく、例えばＳＩＰのＩＮＦＯメソッドによって通知することもできる。
図２は第1実施形態例に係る呼制御セッションを含むフローの一例である。クライアントＡのブラウザ端末Ａは、ユーザＡからの要求に応じて、発呼要求であるＧＥＴメソッドのＨＴＴＰ（Hypertext Transfer Protocol）リクエストをＳＩＰサーバＡに送信する（処理（１）参照）。このためＳＩＰサーバはＨＴＴＰサーバとしての機能を併せ持つものとする。このリクエストの送信はＨＴＴＰによって行われるため、下記のＳＩＰによる呼制御セッションと区別するためにＨＴＴＰセッションというものとする。なお発呼要求をＳＩＰサーバに伝える方法はＨＴＴＰでなくてもよく、例えばＳＩＰのＩＮＦＯメソッドによって通知することもできる。
次に、ＳＩＰサーバＡは、ブラウザ端末ＡからＨＴＴＰリクエストを受信すると、ＩＰ電話Ａ及びＩＰ電話Ｂ間でのメディアセッションを成立させるためにＳＩＰによる呼制御セッションを行う。まず、ＳＩＰサーバＡは、発信端末であるクライアントＡのＩＰ電話ＡにＩＮＶＩＴＥ（ｉ）メッセージを送信する（処理（２）参照）。ＩＰ電話Ａはこれに対して２００ＯＫ（ｉ）メッセージを送信し、ＳＩＰサーバＡはＡＣＫメッセージをＩＰ電話Ａに送信する（処理（３）、（５）参照）。また、ＳＩＰサーバＡは、ＩＰ電話Ａから２００ＯＫ（ｉ）メッセージを受信すると、ＨＴＴＰリクエストで指定された相手先のＩＰ電話ＢにＩＮＶＩＴＥ（ｉｉ）メッセージを送信する（処理（４）参照）。ＩＰ電話Ｂはこれに対して２００ＯＫ（ｉｉ）メッセージを送信し、ＳＩＰサーバＡはＡＣＫメッセージをＩＰ電話Ｂに送信する（処理（６）、（７）参照）。ＳＩＰサーバＡは、ＩＰ電話Ｂから２００ＯＫ（ｉｉ）メッセージを受信すると、ＩＰ電話ＡにＩＮＶＩＴＥ（ｉｉｉ）メッセージを送信する（処理（８）参照）。これに対し、ＩＰ電話Ａは２００ＯＫ（ｉｉｉ）メッセージを送信し、ＳＩＰサーバＡはＡＣＫメッセージをＩＰ電話Ａに送信する（処理（９）、（１０）参照）。これらの呼制御セッションによりメディアセッションが成立する。
ＳＩＰサーバＡは、メディアセッションが成立すると呼制御セッションで取得したセッション情報を複製し、ＳＩＰサーバＡとクラスタを構成するＳＩＰサーバＢに送信する（処理（１１）参照）。これにより、複数のＳＩＰサーバにセッション情報が共有される。
ＳＩＰサーバＢは、ＳＩＰサーバＡで障害が発生したことを検出するための確認パケットを常時生成して送信し、確認パケットからの応答パケットに基づいてＳＩＰサーバＡでの障害を検出する（処理（１２）、（１３）参照）。
ＳＩＰサーバＢは、ＳＩＰサーバＡで障害が発生したことを検出するための確認パケットを常時生成して送信し、確認パケットからの応答パケットに基づいてＳＩＰサーバＡでの障害を検出する（処理（１２）、（１３）参照）。
その後、切断、転送、保留などの継続した呼制御を端末Ａ、Ｂが実行しようとした場合、ＳＩＰサーバＡからの応答がないため代替サーバであるＳＩＰサーバＢに呼制御メッセージを送信する。以降の呼制御はＳＩＰサーバＢを利用して行われるようになる。これにより切断、転送、保留などの呼制御を継続して行うことができる。
（３）セッション情報複製方法の概要
次に、本発明の第1実施形態に係るセッション情報複製方法の概要を説明する。前述の通り、セッション情報はメディアセッションが成立すると複製され、複数のＳＩＰサーバに共有される。ここで、メディアセッションの成立は次のようにして判断される。
（３）セッション情報複製方法の概要
次に、本発明の第1実施形態に係るセッション情報複製方法の概要を説明する。前述の通り、セッション情報はメディアセッションが成立すると複製され、複数のＳＩＰサーバに共有される。ここで、メディアセッションの成立は次のようにして判断される。
図２に示す呼制御セッション中で送受信されるメッセージから、メディアデータの送受信方法を定義したメディア情報を抽出して監視する。ＳＩＰサーバＡは、監視結果に基づいてメディアセッションの成立又は不成立を判断する。ここで、呼制御セッションでは、ＩＰ電話Ａ及びＩＰ電話Ｂ間でメディア情報を互いに送受信してネゴシエーションを行う。ネゴシエーションの結果、メディアデータの送受信方法が確定すると、メディアセッションが成立する。よって、ＩＰ電話Ａ及びＩＰ電話Ｂ間においてメディア情報が送受信されたことを検出することで、メディアセッションの成立を判断することができる。そこで、本発明のＳＩＰサーバＡは、ＩＰ電話Ａから受信したメディア情報をＩＰ電話Ｂに送信したことを検出し、かつＩＰ電話Ｂから受信したメディア情報をＩＰ電話Ａに送信したことを検出すると、前記メディアセッションが成立したと判断する。
（４）ＳＩＰサーバの内部構成
図３は第１実施形態に係るＳＩＰサーバＡのハードウェア構成及び機能構成を示すブロック図である。ＳＩＰサーバＡ及びＳＩＰサーバＢは同様の構成であるので、ＳＩＰサーバＡについてのみ説明する。ＳＩＰサーバＡは、ハードウェアとして各種処理を行うＣＰＵ１０と、各種処理に伴うデータを記憶するＲＡＭ２０と、各種処理を行うための制御プログラムを記憶するＲＯＭ３０と、を含む。各ハードウェアの機能構成を以下に説明する。
図３は第１実施形態に係るＳＩＰサーバＡのハードウェア構成及び機能構成を示すブロック図である。ＳＩＰサーバＡ及びＳＩＰサーバＢは同様の構成であるので、ＳＩＰサーバＡについてのみ説明する。ＳＩＰサーバＡは、ハードウェアとして各種処理を行うＣＰＵ１０と、各種処理に伴うデータを記憶するＲＡＭ２０と、各種処理を行うための制御プログラムを記憶するＲＯＭ３０と、を含む。各ハードウェアの機能構成を以下に説明する。
（４−１）制御プログラムＤＢ
ＲＯＭ３０の制御プログラムＤＢ３１は、各種処理を行うための制御プログラムを記憶している。例えば、ＳＩＰ、ＳＤＰ（Session Description Protocol）、ＲＴＰ（Real-time Transport Protocol）、ＩＰ、ＵＤＰ（User Datagram Protocol）、ＴＣＰ（Transmission Control Protocol）などのプロトコルを実行するための制御プログラムが記憶されている。
ＲＯＭ３０の制御プログラムＤＢ３１は、各種処理を行うための制御プログラムを記憶している。例えば、ＳＩＰ、ＳＤＰ（Session Description Protocol）、ＲＴＰ（Real-time Transport Protocol）、ＩＰ、ＵＤＰ（User Datagram Protocol）、ＴＣＰ（Transmission Control Protocol）などのプロトコルを実行するための制御プログラムが記憶されている。
（４−２）クラスタ構成テーブル
ＲＡＭ２０のクラスタ構成テーブル２３には、クラスタを構成するＳＩＰサーバの組み合わせを記憶している。図４はクラスタを構成の一例を示す。例えば、本実施形態では、図４に示すように、クラスタを構成するＳＩＰサーバとしてＳＩＰサーバＡ及びＳＩＰサーバＢ・・・が記憶されている。
ＲＡＭ２０のクラスタ構成テーブル２３には、クラスタを構成するＳＩＰサーバの組み合わせを記憶している。図４はクラスタを構成の一例を示す。例えば、本実施形態では、図４に示すように、クラスタを構成するＳＩＰサーバとしてＳＩＰサーバＡ及びＳＩＰサーバＢ・・・が記憶されている。
（４−３）送受信部
ＣＰＵ１０の送受信部１１は、クライアントＡ、Ｂ及びＳＩＰサーバＢ等から送信されたパケットを受信し、また、後述の呼制御部１２で作成されたパケットをクライアントＡ、Ｂ及びＳＩＰサーバＢ等に送信する。送受信部１１は、例えばＨＴＴＰセッションに伴うＨＴＴＰリクエストやＨＴＴＰレスポンス等を送受信するためのパケット、呼制御セッションに伴う各種メッセージやセッション情報を送受信するためのパケットを送受信する。
ＣＰＵ１０の送受信部１１は、クライアントＡ、Ｂ及びＳＩＰサーバＢ等から送信されたパケットを受信し、また、後述の呼制御部１２で作成されたパケットをクライアントＡ、Ｂ及びＳＩＰサーバＢ等に送信する。送受信部１１は、例えばＨＴＴＰセッションに伴うＨＴＴＰリクエストやＨＴＴＰレスポンス等を送受信するためのパケット、呼制御セッションに伴う各種メッセージやセッション情報を送受信するためのパケットを送受信する。
図５〜１１は、図２の処理において送受信される各パケットに含まれる情報の記述例である。図５（ａ）はＧＥＴメソッドのＨＴＴＰリクエストの記述例、図５（ｂ）はＳＩＰのＩＮＦＯメソッドによる発呼要求の記述例、図６はＩＮＶＩＴＥ（ｉ）メッセージの記述例、図７は２００ＯＫ（ｉ）メッセージの記述例、図８はＩＮＶＩＴＥ（ｉｉ）メッセージの記述例、図９は２００ＯＫ（ｉｉ）メッセージの記述例、図１０はＩＮＶＩＴＥ（ｉｉｉ）メッセージの記述例、図１１は２００ＯＫ（ｉｉｉ）メッセージの記述例である。
（４−４）呼制御部、セッション情報ＤＢ
ＣＰＵ１０の呼制御部１２は、送受信部１１から図５（ａ）に示すＧＥＴメソッドのＨＴＴＰリクエストを受信し解析する。ＨＴＴＰリクエストによれば、ｃａｌｌｅｒであるａｌｉｃｅからｃａｌｌｅｅであるｂｏｂへの通話のリクエストがＳＩＰサーバＡのアドレスに送信されていることが分かる。ここで、aliceとは発信側のＩＰ電話Ａ（alice@client1.test.co.jp）であり、bobとは着信側のＩＰ電話Ｂ（bob@client2.test.co.jp）である。次に、呼制御部１２は、ＨＴＴＰリクエストの受信に応じて図６に示すＩＮＶＩＴＥ（ｉ）メッセージを生成するとともに、呼ＩＤ（IDentifier）及びＳＩＰセッションＩＤを設定し、これらを含む呼設定要求及びセッション情報を生成する。
ＣＰＵ１０の呼制御部１２は、送受信部１１から図５（ａ）に示すＧＥＴメソッドのＨＴＴＰリクエストを受信し解析する。ＨＴＴＰリクエストによれば、ｃａｌｌｅｒであるａｌｉｃｅからｃａｌｌｅｅであるｂｏｂへの通話のリクエストがＳＩＰサーバＡのアドレスに送信されていることが分かる。ここで、aliceとは発信側のＩＰ電話Ａ（alice@client1.test.co.jp）であり、bobとは着信側のＩＰ電話Ｂ（bob@client2.test.co.jp）である。次に、呼制御部１２は、ＨＴＴＰリクエストの受信に応じて図６に示すＩＮＶＩＴＥ（ｉ）メッセージを生成するとともに、呼ＩＤ（IDentifier）及びＳＩＰセッションＩＤを設定し、これらを含む呼設定要求及びセッション情報を生成する。
ここで、ＳＩＰセッションとは、ＳＩＰサーバと各端末との間でＳＩＰに基づいて行われるセッションであり、ＳＩＰセッションＩＤとは、各ＳＩＰセッションを識別するための識別子である。ＳＩＰセッションＩＤにより、ＩＰ電話Ａ及びＳＩＰサーバＡ間のＳＩＰセッションと、ＩＰ電話Ｂ及びＳＩＰサーバＡ間のＳＩＰセッションとが識別可能である。また、呼ＩＤは、呼制御セッションを識別するための識別子であり、一組のＳＩＰセッションＩＤを互いに対応付ける。本実施形態では、呼制御部１２は、ＩＰ電話ＡとＳＩＰサーバＡとの間のＳＩＰセッションＩＤを1234@sip.test.co.jpと設定し、ＩＰ電話ＢとＳＩＰサーバＡとの間のＳＩＰセッションＩＤを5678@sip.test.co.jpと設定し、これらのＳＩＰセッションを含む呼制御セッションの呼ＩＤを12345678と設定している。
また、セッション情報とは、ＳＩＰサーバが、ＩＰ電話Ａ及びＩＰ電話Ｂと呼制御セッションを行うのに必要な情報である。セッション情報ＤＢ２１は呼制御部１２からセッション情報を受け取り記憶する。図１２は、図５（ａ）に示すＨＴＴＰリクエストに基づいて呼制御部１２が生成するセッション情報の一例である。セッション情報には、呼ＩＤ、発信端末が行うＳＩＰセッションのＳＩＰセッションＩＤ、各ＳＩＰセッションを行う端末名、各端末のアドレス、接続先である着信端末が行うＳＩＰセッションのＳＩＰセッションＩＤ、セッション状態、発信側か着信側かを識別するためのcaller/callee情報などを含む。
さらに、呼制御部１２は、各クライアントから呼制御セッションに伴うメッセージを受信すると、受信したメッセージに対する応答メッセージや、別のクライアントに転送するためのメッセージを生成し、送受信部１１を介して各クライアントに送信する。また、後述のクラスタ構成テーブル２３からＳＩＰサーバＡとクラスタを構成するＳＩＰサーバＢの情報を取得し、後述の複製処理部１６で生成されたセッション情報を送受信部１１を介してＳＩＰサーバＢに送信する。
（４−５）監視部、テーブル生成部及び情報テーブル
ＣＰＵ１０のテーブル生成部１４は、呼制御部１２から呼ＩＤ及びＳＩＰセッションＩＤを含む呼設定要求を受信し、情報テーブル２２をＲＡＭ２０に準備する。このとき、情報テーブル２２には、後述の図１３に示すように、呼設定要求に含まれる呼ＩＤ、端末名及びＳＩＰセッションＩＤ等が設定される。また、呼制御セッションに伴うメッセージの送受信が行われると、情報テーブル２２には、メッセージに基づいてメディアセッション成立の判断を行うためのメディア情報が格納される。
ＣＰＵ１０のテーブル生成部１４は、呼制御部１２から呼ＩＤ及びＳＩＰセッションＩＤを含む呼設定要求を受信し、情報テーブル２２をＲＡＭ２０に準備する。このとき、情報テーブル２２には、後述の図１３に示すように、呼設定要求に含まれる呼ＩＤ、端末名及びＳＩＰセッションＩＤ等が設定される。また、呼制御セッションに伴うメッセージの送受信が行われると、情報テーブル２２には、メッセージに基づいてメディアセッション成立の判断を行うためのメディア情報が格納される。
ＣＰＵ１０の監視部１３は、呼制御セッションに伴うメッセージに基づいて、メディアセッション成立の判断を行うための情報としてメディア情報を抽出する。ここで、ＩＰ電話Ａ及びＩＰ電話Ｂは、メディアセッションを行うためには、少なくともメディアデータを送信すべき送信先アドレスをそれぞれ取得する必要がある。そこで、ここでは、メディア情報のうちメディアデータの送信先アドレスを例に挙げてメディアセッションの成立を判断する方法を説明する。
監視部１３は、図６〜Ｅ１１のメッセージにおいてメディアデータの送受信方法を定義したメディア情報のうち送信先アドレスを抽出する。ここで、監視部１３はメッセージが属する呼ＩＤを取得しており、前記呼ＩＤに対応する情報テーブル２２に送信先アドレスが格納される。
以下に、まず呼制御セッションで送受信されるメッセージの構成について、図６に示すＩＮＶＩＴＥ（ｉ）メッセージを用いて説明する。
以下に、まず呼制御セッションで送受信されるメッセージの構成について、図６に示すＩＮＶＩＴＥ（ｉ）メッセージを用いて説明する。
（ｉ）メッセージの構成
図６に示すＩＮＶＩＴＥ（ｉ）メッセージは、スタートライン、ヘッダ及びボディから構成されている。スタートラインには要求の種別及び要求の送信先アドレスが記述されている。ヘッダには呼制御セッションの送信元及び送信先などが記述されており、例えばそれぞれ次の情報が記述されている。
図６に示すＩＮＶＩＴＥ（ｉ）メッセージは、スタートライン、ヘッダ及びボディから構成されている。スタートラインには要求の種別及び要求の送信先アドレスが記述されている。ヘッダには呼制御セッションの送信元及び送信先などが記述されており、例えばそれぞれ次の情報が記述されている。
Ｖｉａ：ＳＩＰのバージョン、プロトコル、メッセージに対するレスポンスの送信先。
Ｍａｘ−Ｆｏｒｗａｒｄｓ：メッセージの最大中継回数。
Ｆｒｏｍ：メッセージの送信者。
Ｔｏ：メッセージの受信者。
Ｃａｌｌ−ＩＤ：ＳＩＰセッションＩＤ。
Ｍａｘ−Ｆｏｒｗａｒｄｓ：メッセージの最大中継回数。
Ｆｒｏｍ：メッセージの送信者。
Ｔｏ：メッセージの受信者。
Ｃａｌｌ−ＩＤ：ＳＩＰセッションＩＤ。
ＣＳｅｑ：メッセージの順番。
Ｃｏｎｔａｃｔ：このメッセージ以降のメッセージの送信先。
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ボディの種類。
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：ボディのサイズ。
また、ボディはメディア情報を含む。メディア情報はＳＤＰ（Session Description Protocol）で記述されており、例えばそれぞれ次の情報が記述されている。
Ｃｏｎｔａｃｔ：このメッセージ以降のメッセージの送信先。
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ボディの種類。
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：ボディのサイズ。
また、ボディはメディア情報を含む。メディア情報はＳＤＰ（Session Description Protocol）で記述されており、例えばそれぞれ次の情報が記述されている。
ｖ：送信プロトコルのバージョン。
ｏ：メッセージの送信元アドレス。
ｓ：セッション名。
ｃ：メッセージの受信側がメディアデータを送信すべき送信先アドレス、ネットワークの種類。
ｏ：メッセージの送信元アドレス。
ｓ：セッション名。
ｃ：メッセージの受信側がメディアデータを送信すべき送信先アドレス、ネットワークの種類。
ｔ：セッションの開始時刻及び終了時刻。
ｍ：メディアデータの送信先のポート番号、メディアデータの種類、メディアデータの送信プロトコル。
ａ：メディアデータの属性。
（ｉｉ）情報テーブルの変化
次に、図２を再び用いて、各メッセージの送受信の時点で情報テーブル２２に格納される送信先アドレスについて説明する。図１３は図２中の（ａ１）〜（ａ５）の各時点での情報テーブルを示す。
ｍ：メディアデータの送信先のポート番号、メディアデータの種類、メディアデータの送信プロトコル。
ａ：メディアデータの属性。
（ｉｉ）情報テーブルの変化
次に、図２を再び用いて、各メッセージの送受信の時点で情報テーブル２２に格納される送信先アドレスについて説明する。図１３は図２中の（ａ１）〜（ａ５）の各時点での情報テーブルを示す。
ＳＩＰサーバＡの呼制御部１２はＨＴＴＰリクエストを受信すると、図６に示すＩＮＶＩＴＥ（ｉ）メッセージを生成し、送受信部１１を介してＩＰ電話Ａに送信する（処理（２）参照）。監視部１３は、呼制御部１２からＩＮＶＩＴＥ（ｉ）メッセージを受け取り、メッセージのＳＩＰセッションＩＤを抽出する。また、監視部１３は、ＳＩＰセッションＩＤが1234@sip.test.co.jpであることに基づいて、図１２に示すセッション情報からメッセージが属する呼ＩＤとして12345678を取得する。これにより、テーブル生成部１４は呼ＩＤが12345678の情報テーブル２２を呼び出す。また、監視部１３は、メッセージのヘッダ及び各メッセージの送信順等を参照してメッセージの送信元及び送信先が発信側か着信側かを判断する。さらに、監視部１３は、ＩＮＶＩＴＥ（ｉ）メッセージのメディア情報から送信先アドレスとしてＣ値を抽出する。このとき、監視部１３は、図６のＩＮＶＩＴＥ（ｉ）メッセージに基づいて、Ｃ値として0.0.0.0を抽出する。テーブル生成部１４は抽出されたＣ値を、発信側又は着信側の判断に基づいて情報テーブル２２の該当箇所に格納する。これにより、情報テーブル２２は図１３の（ａ１）に示す状態となる。図１３の（ａ１）に示す情報テーブル２２は、ＳＩＰサーバＡがＩＰ電話Ａに送信したメッセージに含まれるＣ値は0.0.0.0であることを示している。
次に、呼制御部１２は、図７に示す２００ＯＫ（ｉ）メッセージをＩＰ電話Ａから受信する（処理（３）参照）。監視部１３は、呼制御部１２から２００ＯＫ（ｉ）メッセージを受け取り、メディア情報からＣ値として10.254.214.60を抽出する。呼ＩＤが12345678の情報テーブル２２は図１３の（ａ２）に示す状態となる。図１３の（ａ２）に示す情報テーブル２２では、ＳＩＰサーバＡがＩＰ電話Ａから受信したメッセージに含まれるＣ値は10.254.214.60であることを示している。
次に、呼制御部１２が図８に示すＩＮＶＩＴＥ（ｉｉ）メッセージを生成してＩＰ電話Ｂに送信すると（処理（４）参照）、監視部１３はメディア情報からＣ値として10.254.214.60を抽出する。情報テーブル２２は図１３の（ａ３）に示す状態となる。このときの情報テーブル２２は、ＳＩＰサーバＡがＩＰ電話Ｂに送信したメッセージに含まれるＣ値は10.254.214.60であることを示している。
次に、呼制御部１２が図９に示す２００ＯＫ（ｉｉ）メッセージをＩＰ電話Ｂから受信すると（処理（６）参照）、監視部１３はメディア情報からＣ値として10.254.214.130を抽出する。情報テーブル２２は図１３の（ａ４）に示す状態となる。このときの情報テーブル２２は、ＳＩＰサーバＡがＩＰ電話Ｂから受信したメッセージに含まれるＣ値は10.254.214.130であることを示している。
さらに、呼制御部１２が図１０に示すＩＮＶＩＴＥ（ｉｉｉ）メッセージを生成してＩＰ電話Ａに送信すると（処理（８）参照）、監視部１３はメディア情報からＣ値として10.254.214.130を抽出する。情報テーブル２２は図１３の（ａ４）に示す状態となる。このときの情報テーブル２２は、ＳＩＰサーバＡがＩＰ電話Ａに送信したメッセージに含まれるＣ値は10.254.214.130であることを示している。
（４−６）複製判断部
複製判断部１５は、ＩＰ電話Ａ及びＩＰ電話Ｂ間でのメディアセッションの成立又は不成立を判断する。複製判断部１５は、メディアセッションが成立した時を、セッション情報を複製し送信するタイミングとして決定し、複製処理部１６にメディアセッション成立の通知を送信する。
複製判断部１５は、ＩＰ電話Ａ及びＩＰ電話Ｂ間でのメディアセッションの成立又は不成立を判断する。複製判断部１５は、メディアセッションが成立した時を、セッション情報を複製し送信するタイミングとして決定し、複製処理部１６にメディアセッション成立の通知を送信する。
ＩＰ電話Ａ及びＩＰ電話Ｂ間では、メディアセッションを開始する前に、呼制御セッションにおいてメディア情報を互いに送受信することでネゴシエーションを行い、メディアデータの送受信方法を確定する。メディア情報としては前述の通りメディアデータの送信先アドレスがあり、ＩＰ電話Ａ及びＩＰ電話Ｂそれぞれのメディアデータの送信先アドレスが確定することで、メディアセッションを開始することができるようになる。そこで、複製判断部１５は、ＩＰ電話Ａが送信先アドレスを含むメッセージをＳＩＰサーバＡに送信し、ＳＩＰサーバＡがその送信先アドレスを含むメッセージをＩＰ電話Ｂに送信すること又は送信したことを検出する。さらに、複製判断部１５は、ＩＰ電話Ｂが送信先アドレスを含むメッセージをＳＩＰサーバＡに送信し、ＳＩＰサーバＡがその送信先アドレスを含むメッセージをＩＰ電話Ａに送信すること又は送信したことを検出する。これにより複製判断部１５はメディアセッションが成立したと判断することができる。
前述の方法によりメディアセッションの成立を判断するには、情報テーブル２２を次のように参照する。複製判断部１５は、情報テーブル２２において、ＳＩＰサーバＡがＩＰ電話Ａから受信した送信先アドレスと、ＳＩＰサーバＡがＩＰ電話Ｂに送信した送信先アドレスと、が一致することを検出する。これにより、ＩＰ電話ＡからＩＰ電話Ｂに送信先アドレスが送信されたことが分かる。さらに、情報テーブル２２において、ＳＩＰサーバＡがＩＰ電話Ｂから受信した送信先アドレスと、ＳＩＰサーバＡがＩＰ電話Ａに送信した送信先アドレスと、が一致することを検出する。これにより、ＩＰ電話ＢからＩＰ電話Ａに送信先アドレスが送信されたことが分かる。以上からＩＰ電話Ａ及びＩＰ電話間で送信先アドレスが交換されたことが分かる。
具体的に、（ａ４）の時点での情報テーブル２２では、ＳＩＰサーバＡがＩＰ電話Ａから受信した送信先アドレスは10.254.214.60であり、ＳＩＰサーバＡがＩＰ電話Ｂに送信した送信先アドレスは10.254.214.60であり一致する。一方、ＳＩＰサーバＡがＩＰ電話Ｂから受信した送信先アドレスは10.254.214.130であり、ＳＩＰサーバＡがＩＰ電話Ａに送信した送信先アドレスは0.0.0.0であり一致しない。よって、複製判断部１５はメディアセッションは成立していないと判断する。
（ａ５）の時点での情報テーブル２２では、（ａ４）の時点に比べて、ＳＩＰサーバＡがＩＰ電話Ａに送信した送信先アドレスが10.254.214.130に更新される。よって、ＳＩＰサーバＡがＩＰ電話Ｂから受信した送信先アドレスは10.254.214.130であり、ＳＩＰサーバＡがＩＰ電話Ａに送信した送信先アドレスは10.254.214.130であり一致する。よって、複製判断部１５はメディアセッションが成立したと判断する。
なお、（ａ１）〜（ａ３）の時点での情報テーブル２２では、Ｃ値が満たされていないため比較ができない。
（４−７）複製処理部
複製処理部１６は、複製判断部１５からメディアセッションが成立したとの通知を受けると、セッション情報ＤＢ２１内のセッション情報を複製する。呼制御部１２は、複製されたセッション情報を送受信部１１を介してＳＩＰサーバＢに送信する。
（４−７）複製処理部
複製処理部１６は、複製判断部１５からメディアセッションが成立したとの通知を受けると、セッション情報ＤＢ２１内のセッション情報を複製する。呼制御部１２は、複製されたセッション情報を送受信部１１を介してＳＩＰサーバＢに送信する。
（５）処理の流れ
次に、ＳＩＰサーバでのセッション情報複製方法の処理の流れについて図１４、図１５を用いて説明する。図１４は、第１実施形態に係るＳＩＰサーバでのセッション情報複製方法の全体の流れを示すフローチャートの一例である。図１５は、第１実施形態に係るメディアセッション成立判断処理の流れを示すフローチャートの一例である。まず、セッション情報複製方法の全体の流れについて説明し、次にメディアセッション成立判断処理について説明する。
次に、ＳＩＰサーバでのセッション情報複製方法の処理の流れについて図１４、図１５を用いて説明する。図１４は、第１実施形態に係るＳＩＰサーバでのセッション情報複製方法の全体の流れを示すフローチャートの一例である。図１５は、第１実施形態に係るメディアセッション成立判断処理の流れを示すフローチャートの一例である。まず、セッション情報複製方法の全体の流れについて説明し、次にメディアセッション成立判断処理について説明する。
（５−１）セッション情報複製方法の全体の流れ
ステップＳ１：送受信部１１がパケットを送受信するとステップＳ２に進む。例えば、送受信部１１は、呼制御部１２が生成したパケットをＳＩＰサーバＡの外部へ送信したり、ＳＩＰサーバＡの外部からパケットを受信する。呼制御部１２は、送受信部１１がＳＩＰサーバＡの外部から受信したパケットを受け取る。一方、送受信部１１は、パケットを送受信していない場合は、パケットを送受信するまで待機する。
ステップＳ１：送受信部１１がパケットを送受信するとステップＳ２に進む。例えば、送受信部１１は、呼制御部１２が生成したパケットをＳＩＰサーバＡの外部へ送信したり、ＳＩＰサーバＡの外部からパケットを受信する。呼制御部１２は、送受信部１１がＳＩＰサーバＡの外部から受信したパケットを受け取る。一方、送受信部１１は、パケットを送受信していない場合は、パケットを送受信するまで待機する。
ステップＳ２：呼制御部１２は、発話要求であるＧＥＴメソッドのＨＴＴＰリクエストを受信すると、呼ＩＤ及びＳＩＰセッションＩＤを設定する。また、呼制御部１２はこれらのＩＤを含む呼設定要求及びセッション情報を生成する。セッション情報ＤＢ２１はセッション情報を記憶する。
一方、呼制御部１２は、ＩＰ電話からメディアセッションの切断要求を受信すると、終了要求を生成する。
一方、呼制御部１２は、ＩＰ電話からメディアセッションの切断要求を受信すると、終了要求を生成する。
呼制御部１２は、呼制御セッションに伴うメッセージ及び呼設定要求を監視部１３及びテーブル生成部１４に送信する。監視部１３がメッセージを受信するとステップＳ５に進む。また、テーブル生成部１４が呼設定要求を受信するとステップＳ３及びＳ４に進み、呼制御部１２が終了要求を生成するとステップＳ８に進む。
ステップＳ３、Ｓ４：テーブル生成部１４は、呼制御部１２から呼設定要求を受信すると、呼ＩＤ、端末名及びＳＩＰセッションＩＤ等を設定して情報テーブル２２を準備し、その他の必要なテーブルを生成する。
ステップＳ３、Ｓ４：テーブル生成部１４は、呼制御部１２から呼設定要求を受信すると、呼ＩＤ、端末名及びＳＩＰセッションＩＤ等を設定して情報テーブル２２を準備し、その他の必要なテーブルを生成する。
ステップＳ５：監視部１３がメッセージを受信すると、メディアセッションの成立判断処理が行われる。
ステップＳ６：ステップＳ５でメディアセッションが成立したと判断されると、複製処理部１６は、セッション情報ＤＢ２１内のセッション情報を複製する。呼制御部１２は、複製されたセッション情報を送受信部１１を介してＳＩＰサーバＢに送信する。
ステップＳ６：ステップＳ５でメディアセッションが成立したと判断されると、複製処理部１６は、セッション情報ＤＢ２１内のセッション情報を複製する。呼制御部１２は、複製されたセッション情報を送受信部１１を介してＳＩＰサーバＢに送信する。
ステップＳ７：セッション情報の複製が完了すると、情報テーブル２２を初期化する。
ステップＳ８：呼制御部１２は、ＢＹＥメッセージなど終了要求をＩＰ電話Ａ及びＩＰ電話Ｂに送信し呼制御セッションを終了させる。呼制御セッションに伴うメッセージの受信、終了要求の生成及び呼設定要求の生成も行われていない場合は、ステップＳ１に戻る。
ステップＳ８：呼制御部１２は、ＢＹＥメッセージなど終了要求をＩＰ電話Ａ及びＩＰ電話Ｂに送信し呼制御セッションを終了させる。呼制御セッションに伴うメッセージの受信、終了要求の生成及び呼設定要求の生成も行われていない場合は、ステップＳ１に戻る。
（５−２）メディアセッション成立判断処理の流れ
ステップＳ５ａ、Ｓ５ｂ：監視部１３は、メッセージにメディア情報が含まれる場合は、ステップＳ５ｂに進む。メッセージにメディア情報が含まれていない場合は待機する。
ステップＳ５ｂ：監視部１３は、メッセージからＳＩＰセッションＩＤを取得し、セッション情報ＤＢ２１から対応する呼ＩＤを取得する。
ステップＳ５ａ、Ｓ５ｂ：監視部１３は、メッセージにメディア情報が含まれる場合は、ステップＳ５ｂに進む。メッセージにメディア情報が含まれていない場合は待機する。
ステップＳ５ｂ：監視部１３は、メッセージからＳＩＰセッションＩＤを取得し、セッション情報ＤＢ２１から対応する呼ＩＤを取得する。
ステップＳ５ｃ：テーブル生成部１４は、監視部１３から呼ＩＤを取得し、前記呼ＩＤに対応する情報テーブル２２を呼び出す。
ステップＳ５ｄ：監視部１３は、メッセージのヘッダ及び各メッセージの送信順等を参照してメッセージの送信元及び送信先が発信側か着信側かを把握する。
ステップＳ５ｅ：監視部１３はメッセージからメディア情報を抽出する。例えば、監視部１３はメッセージからＣ値を抽出する。また、テーブル生成部１４は、ステップＳ５ｄでの発信側又は着信側の判断に基づいて、Ｃ値を情報テーブル２２の該当箇所に格納する。
ステップＳ５ｄ：監視部１３は、メッセージのヘッダ及び各メッセージの送信順等を参照してメッセージの送信元及び送信先が発信側か着信側かを把握する。
ステップＳ５ｅ：監視部１３はメッセージからメディア情報を抽出する。例えば、監視部１３はメッセージからＣ値を抽出する。また、テーブル生成部１４は、ステップＳ５ｄでの発信側又は着信側の判断に基づいて、Ｃ値を情報テーブル２２の該当箇所に格納する。
ステップＳ５ｆ：次に、複製判断部１５は、情報テーブル２２を参照し、ＩＰ電話Ａがメディアデータを送信すべき送信先アドレスと、ＩＰ電話Ｂがメディアデータを送信すべき送信先アドレスと、がＩＰ電話Ａ及びＩＰ電話Ｂ間で送受信されたことを検出する。複製判断部１５は、前記送信先アドレスが送受信されたことを検出すると、メディアセッションが成立したと判断する。
ステップＳ５ｇ：メディアセッションが成立した場合はステップＳ５ｈに進み、成立していない場合はステップＳ５ａに戻る
ステップＳ５ｈ：複製判断部１５は、メディアセッションが成立したとの通知を複製処理部１６に送信することで、セッション情報の複製指示を行う。
なお、ステップＳ５ｂ〜Ｓ５ｅに含まれる呼ＩＤを取得して情報テーブル２２を呼び出す処理、発信側及び着信側を把握する処理、メディア情報を抽出する処理は、順不同である。
ステップＳ５ｈ：複製判断部１５は、メディアセッションが成立したとの通知を複製処理部１６に送信することで、セッション情報の複製指示を行う。
なお、ステップＳ５ｂ〜Ｓ５ｅに含まれる呼ＩＤを取得して情報テーブル２２を呼び出す処理、発信側及び着信側を把握する処理、メディア情報を抽出する処理は、順不同である。
上記セッション情報複製方法によれば、呼制御セッションに伴うメッセージの送受信のタイミングではなく、メディアセッションが成立した場合にセッション情報の複製及び送信を行う。よって、セッション情報の複製回数及び送信回数を抑制し、ＳＩＰサーバの処理負荷を減らすことができる。また、セッション情報が頻繁に送受信されることによるネットワーク負荷を減らすことができる。
発信端末からメディアセッションの開始要求が送信されても、着信端末のユーザが不在である場合や他のユーザと通話中である場合などには、メディアセッションは不成立となる。このような場合には、代替サーバであるＳＩＰサーバは、複製されたセッション情報を受信しても利用しない場合がある。上記セッション情報複製方法によれば、メディアセッションが成立した場合にセッション情報の複製及び送信を行う。よって、相手方の不在時や通話中などにおいて、ＳＩＰサーバの無駄な処理及びリソースの無駄な消費を抑制することができる。
また、メディアセッションの成立は、メディアデータの送受信方法を記述したメディア情報を参照して検出するため、メディアセッションの成立を確実に検出することができる。
（６）変形例
（６−１）変形例１
変形例１では、セッション情報の複製に加えて、ＨＴＴＰセッションの情報を生成し複製する。図１６は変形例１に係る呼制御セッションを含むフローの一例である。上記実施形態の図２に示す処理（１）に対して処理（１−１）〜（１−３）が行われる。また、ＳＩＰサーバＡに障害が発生した場合、ＳＩＰサーバＢは、ブラウザ端末ＡからＳＩＰサーバＢへのＨＴＴＰリクエストに基づいて、ＳＩＰサーバＡから呼制御セッションを引き継ぐ。変形例１の図１６のその他のフローは上記実施形態と同様である。図１７は処理（１−１）及び（１−３）で送受信される各パケットに含まれる情報の記述例である。
（６）変形例
（６−１）変形例１
変形例１では、セッション情報の複製に加えて、ＨＴＴＰセッションの情報を生成し複製する。図１６は変形例１に係る呼制御セッションを含むフローの一例である。上記実施形態の図２に示す処理（１）に対して処理（１−１）〜（１−３）が行われる。また、ＳＩＰサーバＡに障害が発生した場合、ＳＩＰサーバＢは、ブラウザ端末ＡからＳＩＰサーバＢへのＨＴＴＰリクエストに基づいて、ＳＩＰサーバＡから呼制御セッションを引き継ぐ。変形例１の図１６のその他のフローは上記実施形態と同様である。図１７は処理（１−１）及び（１−３）で送受信される各パケットに含まれる情報の記述例である。
ＳＩＰサーバＡの呼制御部１２は、ブラウザ端末ＡからＨＴＴＰリクエストを受信する（処理（１−１）参照）。
呼制御部１２は、ＨＴＴＰリクエストの受信に応じて、呼ＩＤ及びＳＩＰセッションＩＤを設定するとともに、ＨＴＴＰセッションＩＤを設定する。ＨＴＴＰセッションＩＤとは、各端末とＳＩＰサーバとの間で行われるＨＴＴＰセッションを識別するための識別子である。このＨＴＴＰセッションＩＤに基づけば、どの端末とどのＳＩＰサーバとの間のどのＨＴＴＰセッションであるかを識別可能である。また、呼制御部１２は、呼ＩＤ、ＳＩＰセッションＩＤ及びＨＴＴＰセッションＩＤを含む呼設定要求及びセッション情報を生成する。
呼制御部１２は、ＨＴＴＰリクエストの受信に応じて、呼ＩＤ及びＳＩＰセッションＩＤを設定するとともに、ＨＴＴＰセッションＩＤを設定する。ＨＴＴＰセッションＩＤとは、各端末とＳＩＰサーバとの間で行われるＨＴＴＰセッションを識別するための識別子である。このＨＴＴＰセッションＩＤに基づけば、どの端末とどのＳＩＰサーバとの間のどのＨＴＴＰセッションであるかを識別可能である。また、呼制御部１２は、呼ＩＤ、ＳＩＰセッションＩＤ及びＨＴＴＰセッションＩＤを含む呼設定要求及びセッション情報を生成する。
テーブル生成部１４は、呼制御部１２からの呼設定要求に基づいて、図示しないセッション連携テーブルをＲＡＭ２０に生成し、ＳＩＰサーバＢに送信する（処理（１−２）及び（ｃ１）参照）。セッション連携テーブルとは、異なるプロトコルのセッションを関係づけるためのテーブルである。図１８は図１６中の（ｃ１）に示すセッション連携テーブルの一例である。呼制御部１２が呼ＩＤを12345678と設定し、ＨＴＴＰセッションＩＤをH1234と設定した場合、図１８に示すセッション連携テーブルが生成される。これにより、呼制御セッションとＨＴＴＰセッションとが関係づけられる。なお、セッション連携テーブルには、現段階で呼制御セッションを行っている主サーバとしてＳＩＰサーバＡが登録され、代替サーバとしてＳＩＰサーバＢが登録されている。代替サーバとしては、クラスタ構成テーブル２３に基づいて、主サーバとクラスタを構成しており、呼制御セッションを引き継ぎ可能なＳＩＰサーバが登録される。
呼制御部１２は、ＨＴＴＰリクエストに応じてＨＴＴＰに基づく２００ＯＫメッセージを生成し、ブラウザ端末Ａに送信する。このとき、図１７に示すようにブラウザ端末ＡにＨＴＴＰセッションＩＤが通知される。また、呼制御部１２は、ＨＴＴＰリクエストに応じてＳＩＰに基づくＩＮＶＩＴＥ（ｉ）メッセージを生成し、ＩＰ電話Ａに送信する（処理（１−３）参照）。
図１６に示すようにＳＩＰサーバＡに障害が発生したとする。このとき、ユーザの入力に応じてブラウザ端末ＡがＳＩＰサーバＡにメッセージを送信した場合、ＳＩＰサーバＡで障害が発生しているためＳＩＰサーバＡからの応答は無い。そこで、ブラウザ端末Ａは、ＨＴＴＰセッションＩＤとしてH1234を含むＧＥＴメソッドのＨＴＴＰリクエストをＳＩＰサーバＢに送信する（処理（１２）参照）。ＳＩＰサーバＢは、ＨＴＴＰリクエストからＨＴＴＰセッションＩＤを取得し、またセッション連携テーブルからＨＴＴＰセッションＩＤに基づいて呼ＩＤを取得する。これにより、ＳＩＰサーバＢは、取得した呼ＩＤに基づいて該当するセッション情報を取得し、ＳＩＰサーバＡから呼制御セッションを引き継ぐことができる。例えば、ユーザがＷＷＷ画面から「切断」ボタンをクリックした場合、ＳＩＰサーバＢは、セッション情報に基づいて、ＩＰ電話Ａ及びＩＰ電話ＢにＢＹＥメッセージを送信し、呼制御セッション及びメディアセッションを終了させる（処理（１３）、（１４）参照）。
以上のように代替サーバであるＳＩＰサーバＢは、主サーバであるＳＩＰサーバＡで生成したセッション連携テーブルを保持する。よって、ＳＩＰサーバＢは、ブラウザ端末ＡからのＨＴＴＰメッセージに基づいて、メディアセッションの終了などの呼制御セッションをＳＩＰサーバＡから引き継ぐことができる。一方、ユーザはブラウザ端末Ａからメディアセッションの終了などの呼制御セッションを実行させることができる。
なお、前述の図１４のステップＳ２において、呼制御部１２は、呼ＩＤ及びＳＩＰセッションＩＤに加えてＨＴＴＰセッションＩＤを設定し、これらのＩＤを含む呼設定要求及びセッション情報を生成する。また、ステップＳ３、Ｓ４において、テーブル生成部１４は、呼制御部１２から呼設定要求を受信すると、情報テーブル２２の準備に加えて、呼ＩＤ及びＨＴＴＰセッションＩＤ等が設定されたセッション連携テーブルを生成する。
なお、セッション連携テーブルを生成及び複製するタイミングは、前述のタイミングに限定されず、呼制御セッションの開始後ならいずれの時点でも良く、例えばセッション情報を複製するタイミングと同じであっても良い。
また、処理（１−３）の２００ＯＫメッセージにより、ＨＴＴＰセッションＩＤに加えて、主サーバ及び代替サーバの情報をブラウザ端末Ａに通知しても良い。これにより、主サーバに障害が発生した場合、ブラウザ端末Ａはどの代替サーバにアクセスすれば良いかが分かる。
また、処理（１−３）の２００ＯＫメッセージにより、ＨＴＴＰセッションＩＤに加えて、主サーバ及び代替サーバの情報をブラウザ端末Ａに通知しても良い。これにより、主サーバに障害が発生した場合、ブラウザ端末Ａはどの代替サーバにアクセスすれば良いかが分かる。
（６−２）変形例２
変形例２では、サービスサーバを介してメディアセッションが行われる場合において、メディアセッションの成立を判断する方法について説明する。図１９は変形例２に係るネットワーク構成図である。上記実施形態の図１と異なる点はネットワーク１にサービスサーバ２が接続されている点であり、その他の構成は図１と同様である。図２０は変形例２に係る呼制御セッションを含むフローの一例である。呼制御セッションの様子は上記実施形態の図２と同様であり、異なる点は送受信されるメディア情報であり、また情報テーブル２２に格納される情報である。図２１は変形例２に係るＳＩＰサーバＡのハードウェア構成及び機能構成を示すブロック図である。上記実施形態の図３と異なる点はＲＡＭ２０が特定アドレステーブル２４を有する点であり、その他の構成は図３と同様である。
変形例２では、サービスサーバを介してメディアセッションが行われる場合において、メディアセッションの成立を判断する方法について説明する。図１９は変形例２に係るネットワーク構成図である。上記実施形態の図１と異なる点はネットワーク１にサービスサーバ２が接続されている点であり、その他の構成は図１と同様である。図２０は変形例２に係る呼制御セッションを含むフローの一例である。呼制御セッションの様子は上記実施形態の図２と同様であり、異なる点は送受信されるメディア情報であり、また情報テーブル２２に格納される情報である。図２１は変形例２に係るＳＩＰサーバＡのハードウェア構成及び機能構成を示すブロック図である。上記実施形態の図３と異なる点はＲＡＭ２０が特定アドレステーブル２４を有する点であり、その他の構成は図３と同様である。
サービスサーバ２は、例えば、通話の録音、通話中の各種アナウンス及びメディアデータの加工などの各種サービスを提供する。ＳＩＰサーバＡは、自身のサービス以外にサービスサーバ２によるサービスを提供する場合、ＩＰ電話Ａ及びＩＰ電話Ｂのメディアデータの送信先アドレスをサービスサーバ２に設定する。
送信先アドレスの設定方法を次に説明する。ＳＩＰサーバＡの特定アドレステーブル２４は、サービスサーバ２と複数の特定アドレスとの対応づけを記憶している。図２２は特定アドレステーブルの一例である。サービスサーバ２に対して、メディアデータの送信先アドレスであるＣ値が複数対応づけられている。ＳＩＰサーバＡの呼制御部１２は、ＩＰ電話Ａ及びＩＰ電話Ｂそれぞれに、特定アドレステーブル２４から選択した特定アドレスを割り当てる。例えば、呼制御部１２は、ＩＰ電話Ａがメディアデータを送信すべき送信先アドレスとして10.254.214.110を割り当て、ＩＰ電話Ｂがメディアデータを送信すべき送信先アドレスとして10.254.214.100を割り当てる。メディアセッションが成立した場合、ＩＰ電話Ａ及びＩＰ電話Ｂは、割り当てられた送信先アドレスを用いてメディアデータの送受信を行う。
送信先アドレスの設定方法を次に説明する。ＳＩＰサーバＡの特定アドレステーブル２４は、サービスサーバ２と複数の特定アドレスとの対応づけを記憶している。図２２は特定アドレステーブルの一例である。サービスサーバ２に対して、メディアデータの送信先アドレスであるＣ値が複数対応づけられている。ＳＩＰサーバＡの呼制御部１２は、ＩＰ電話Ａ及びＩＰ電話Ｂそれぞれに、特定アドレステーブル２４から選択した特定アドレスを割り当てる。例えば、呼制御部１２は、ＩＰ電話Ａがメディアデータを送信すべき送信先アドレスとして10.254.214.110を割り当て、ＩＰ電話Ｂがメディアデータを送信すべき送信先アドレスとして10.254.214.100を割り当てる。メディアセッションが成立した場合、ＩＰ電話Ａ及びＩＰ電話Ｂは、割り当てられた送信先アドレスを用いてメディアデータの送受信を行う。
上記の場合、ＳＩＰサーバＡは、サービスサーバ２に対応付けられた特定アドレスが、ＩＰ電話Ａ及びＩＰ電話Ｂに割り当てられたことを検出することで、メディアセッションの成立を判断する。つまり、ＳＩＰサーバＡがＩＰ電話Ａ及びＩＰ電話Ｂに送信した送信先アドレスが特定アドレステーブル２４に記憶されているアドレスであることを判断する。以下に具体的に説明する。
ＳＩＰサーバＡとＩＰ電話Ａ及びＩＰ電話Ｂとの間には、図２０に示すような呼制御セッションが行われる。図２０における処理（１）〜（９）のうち処理（４）及び処理（８）における各パケットに含まれる情報の記述が上記実施形態と異なる。図２３は変形例２におけるＩＮＶＩＴＥ（ｉｉ）メッセージの記述例、図２４は変形例２におけるＩＮＶＩＴＥ（ｉｉｉ）メッセージの記述例である。上記実施形態と同様に、監視部１３は呼制御セッションにおいて送受信されるメッセージから送信先アドレスを抽出する。テーブル生成部１４は送信先アドレスを情報テーブル２２に格納する。図２５は、図２０中の（ａ１）、（ａ２）、（ｂ１）〜（ｂ３）の各時点での情報テーブルを示す。（ａ１）及び（ａ２）の時点の情報テーブル２２は上記実施形態と同様である。
処理（４）において、呼制御部１２は、２００ＯＫ（ｉ）メッセージをＩＰ電話Ａから受信すると、図２３に示すＩＮＶＩＴＥ（ｉｉ）メッセージを生成してＩＰ電話Ｂに送信する。監視部１３はメディア情報からＣ値として10.254.214.100を抽出する。情報テーブル２２は図２０の（ｂ１）に示す状態となる。このときの情報テーブル２２は、ＳＩＰサーバＡがＩＰ電話Ｂに送信したメッセージに含まれるＣ値は10.254.214.100であることを示している。
また、処理（６）において、呼制御部１２が図９に示す２００ＯＫ（ｉｉ）メッセージをＩＰ電話Ｂから受信すると、情報テーブル２２は図１３の（ｂ２）に示す状態となる。
また、処理（８）において、呼制御部１２は、図２４に示すＩＮＶＩＴＥ（ｉｉｉ）メッセージを生成してＩＰ電話Ａに送信する。監視部１３はメディア情報からＣ値として10.254.214.110を抽出する。情報テーブル２２は図１３の（ｂ３）に示す状態となる。このときの情報テーブル２２は、ＳＩＰサーバＡがＩＰ電話Ａに送信したメッセージに含まれるＣ値は10.254.214.110であることを示している。
また、処理（８）において、呼制御部１２は、図２４に示すＩＮＶＩＴＥ（ｉｉｉ）メッセージを生成してＩＰ電話Ａに送信する。監視部１３はメディア情報からＣ値として10.254.214.110を抽出する。情報テーブル２２は図１３の（ｂ３）に示す状態となる。このときの情報テーブル２２は、ＳＩＰサーバＡがＩＰ電話Ａに送信したメッセージに含まれるＣ値は10.254.214.110であることを示している。
複製判断部１５は、ＳＩＰサーバＡがＩＰ電話Ａ及びＩＰ電話Ｂに送信した送信先アドレスが、特定アドレステーブル２４に記憶されているかを判断する。（ａ１）、（ａ２）、（ｂ１）及び（ｂ２）の時点の情報テーブル２２では、ＳＩＰサーバＡがＩＰ電話Ａに送信した送信先アドレスは0.0.0.0であり、特定アドレステーブル２４には記憶されていないアドレスである。一方、（ｂ３）の時点の情報テーブル２２では、ＳＩＰサーバＡがＩＰ電話Ａに送信した送信先アドレスは10.254.214.110であり、ＳＩＰサーバＡがＩＰ電話Ｂに送信した送信先アドレスは10.254.214.100であり、いずれも特定アドレステーブル２４に記憶されているアドレスである。よって、複製判断部１５はメディアセッションが成立したと判断する。なお、ここではサービスサーバに複数の異なるＩＰアドレスが割り当てられており、ＩＰ電話Ａ、Ｂに対して異なるＩＰアドレスが利用される例について示したが、同一のＩＰアドレスを割り当て、ポート番号のみが異なる構成であっても構わない。
サービスサーバ２を介してメディアセッションを行う場合にも上記実施形態と同様にＳＩＰサーバの処理負荷及びネットワーク負荷を減らすことができる。
（６−３）変形例３
上記実施形態では、メディア情報のうち送信先アドレスを抽出して情報テーブル２２に格納する。変形例３では、メディア情報からさらにポート番号を抽出して情報テーブル２２に格納する。
（６−３）変形例３
上記実施形態では、メディア情報のうち送信先アドレスを抽出して情報テーブル２２に格納する。変形例３では、メディア情報からさらにポート番号を抽出して情報テーブル２２に格納する。
図２６は図２中の（ａ１）〜（ａ５）の各時点での変形例３の情報テーブルを示す。
変形例３の監視部１３は、図５〜図１１を参照してＣ値及び送信先ポート番号を含むｍ値を抽出し、テーブル生成部１４は情報テーブル２２に抽出された値を格納する。複製判断部１５は、ＩＰ電話Ａ及びＩＰ電話Ｂ間で送信先アドレス及び送信先ポート番号が送受信されたかを検出する。つまり、さらに、変形例３では、複製判断部１５は、ＩＰ電話Ａが送信先アドレス及び送信先ポート番号を含むメッセージをＳＩＰサーバＡに送信し、ＳＩＰサーバＡがその送信先アドレス及び送信先ポート番号を含むメッセージをＩＰ電話Ｂに送信することを検出する。さらに、複製判断部１５は、ＩＰ電話Ｂが送信先アドレス及び送信先ポート番号を含むメッセージをＳＩＰサーバＡに送信し、ＳＩＰサーバＡがその送信先アドレス及び送信先ポート番号を含むメッセージをＩＰ電話Ａに送信することを検出する。上記（４−６）では端末とサーバとの間で仮のメディアセッションを特殊なＩＰアドレス(例えば0.0.0.0)によって成立させる場合について説明したが、これにより複製判断部１５は仮のメディアセッションを特殊なポート番号(例えば0）により成立させる場合であっても端末間のメディアセッションの成立を正確に判断することができる。
変形例３の監視部１３は、図５〜図１１を参照してＣ値及び送信先ポート番号を含むｍ値を抽出し、テーブル生成部１４は情報テーブル２２に抽出された値を格納する。複製判断部１５は、ＩＰ電話Ａ及びＩＰ電話Ｂ間で送信先アドレス及び送信先ポート番号が送受信されたかを検出する。つまり、さらに、変形例３では、複製判断部１５は、ＩＰ電話Ａが送信先アドレス及び送信先ポート番号を含むメッセージをＳＩＰサーバＡに送信し、ＳＩＰサーバＡがその送信先アドレス及び送信先ポート番号を含むメッセージをＩＰ電話Ｂに送信することを検出する。さらに、複製判断部１５は、ＩＰ電話Ｂが送信先アドレス及び送信先ポート番号を含むメッセージをＳＩＰサーバＡに送信し、ＳＩＰサーバＡがその送信先アドレス及び送信先ポート番号を含むメッセージをＩＰ電話Ａに送信することを検出する。上記（４−６）では端末とサーバとの間で仮のメディアセッションを特殊なＩＰアドレス(例えば0.0.0.0)によって成立させる場合について説明したが、これにより複製判断部１５は仮のメディアセッションを特殊なポート番号(例えば0）により成立させる場合であっても端末間のメディアセッションの成立を正確に判断することができる。
例えば、音声案内サービスに接続する場合などにおいて、接続先のＩＰアドレスは予め設定可能であるのに対し、動的に決定されるポート番号は予め設定不可能である場合に有効である。例えば、最初のＩＰ電話Ａに対するＳＩＰメッセージのC値にはIPアドレスが指定され、m値のポート番号には０が設定される。
（６−４）変形例４
上記実施形態では、図２においてＳＩＰサーバＡがＩＮＶＩＴＥ（ｉｉｉ）メッセージをＩＰ電話Ａに送信し（処理（８）参照）、情報テーブル２２が（ａ５）の状態になると、複製判断部１５はメディアセッションが成立したと判断する。しかし、変形例４では、前述のように情報テーブル２２に基づいて判断を行うとともに、さらにメディアセッション成立を判断する根拠となったメッセージに対して、２００ＯＫメッセージ及びＡＣＫメッセージの送受信が行われたかどうかを判断する。具体的に、監視部１３は、ＩＮＶＩＴＥ（ｉｉｉ）メッセージに対してＩＰ電話Ａが２００ＯＫ（ｉｉｉ）メッセージを送信したことを検出し、また２００ＯＫ（ｉｉｉ）メッセージに対してＳＩＰサーバＡがＡＣＫメッセージをＩＰ電話Ａに送信した（処理（９）、（１０）参照）ことを検出する。複製判断部１５は、検出結果を受信し、これらのメッセージの送受信が行われた後にメディアセッションが成立したと判断する。
（６−４）変形例４
上記実施形態では、図２においてＳＩＰサーバＡがＩＮＶＩＴＥ（ｉｉｉ）メッセージをＩＰ電話Ａに送信し（処理（８）参照）、情報テーブル２２が（ａ５）の状態になると、複製判断部１５はメディアセッションが成立したと判断する。しかし、変形例４では、前述のように情報テーブル２２に基づいて判断を行うとともに、さらにメディアセッション成立を判断する根拠となったメッセージに対して、２００ＯＫメッセージ及びＡＣＫメッセージの送受信が行われたかどうかを判断する。具体的に、監視部１３は、ＩＮＶＩＴＥ（ｉｉｉ）メッセージに対してＩＰ電話Ａが２００ＯＫ（ｉｉｉ）メッセージを送信したことを検出し、また２００ＯＫ（ｉｉｉ）メッセージに対してＳＩＰサーバＡがＡＣＫメッセージをＩＰ電話Ａに送信した（処理（９）、（１０）参照）ことを検出する。複製判断部１５は、検出結果を受信し、これらのメッセージの送受信が行われた後にメディアセッションが成立したと判断する。
ＳＩＰでは、ＳＩＰサーバと発信端末及び着信端末との間の呼制御セッションは、通話の要求、応答及び確認の３段階で行われる。よって、情報テーブルによりメディアセッションが成立したと判断し、かつ２００ＯＫメッセージ及びＡＣＫメッセージの送受信を検出することで、確実にメディアセッションの成立を判断することができる。
＜第２実施形態例＞
第１実施形態では、代替サーバであるＳＩＰサーバＢは、メディアセッションの成立後にセッション情報をＳＩＰサーバＡから受信する。第２実施形態では、ＳＩＰサーバＢは、メディアセッション成立前に一旦セッション情報をＳＩＰサーバＡから受信し、その後のセッション情報の受信はメディアセッションの成立後に行う。これにより、メディアセッションが成立する前にＳＩＰサーバＡで障害が発生した場合でも、ＳＩＰサーバＢはＳＩＰサーバＡによる呼制御セッションを引き継ぐことができる。
＜第２実施形態例＞
第１実施形態では、代替サーバであるＳＩＰサーバＢは、メディアセッションの成立後にセッション情報をＳＩＰサーバＡから受信する。第２実施形態では、ＳＩＰサーバＢは、メディアセッション成立前に一旦セッション情報をＳＩＰサーバＡから受信し、その後のセッション情報の受信はメディアセッションの成立後に行う。これにより、メディアセッションが成立する前にＳＩＰサーバＡで障害が発生した場合でも、ＳＩＰサーバＢはＳＩＰサーバＡによる呼制御セッションを引き継ぐことができる。
（１）構成
第２実施形態の全体構成、機能構成及びハードウェア構成は第１実施形態と同様であるので説明を省略する。
（２）処理の概要
（２−１）
図２７は第２実施形態例に係る呼制御セッションを含むフローの一例である。図２７中の処理（１）〜（４）、処理（６）〜（８）は、第１実施形態の処理（１）〜（７）と同じであり、図２７中の（ａ１）〜（ａ４）は第１実施形態の同一符号の情報テーブルと同じである。
第２実施形態の全体構成、機能構成及びハードウェア構成は第１実施形態と同様であるので説明を省略する。
（２）処理の概要
（２−１）
図２７は第２実施形態例に係る呼制御セッションを含むフローの一例である。図２７中の処理（１）〜（４）、処理（６）〜（８）は、第１実施形態の処理（１）〜（７）と同じであり、図２７中の（ａ１）〜（ａ４）は第１実施形態の同一符号の情報テーブルと同じである。
ブラウザ端末Ａは、ユーザＡからの要求に応じて、発呼要求であるＧＥＴメソッドのＨＴＴＰリクエストをＳＩＰサーバＡに送信する（処理（１）参照）。次に、ＳＩＰサーバＡ、ＩＰ電話Ａ及びＩＰ電話Ｂ間で、ＩＮＶＩＴＥ（ｉ）メッセージ、２００ＯＫ（ｉ）メッセージ及びＩＮＶＩＴＥ（ｉｉ）メッセージの送受信が行われる（処理（２）〜（４）参照）。
ＳＩＰサーバＡの複製処理部１５は、タイミングは特に限定されないが、メディアセッションの成立前に一旦セッション情報を複製し、ＳＩＰサーバＡとクラスタを構成するＳＩＰサーバＢに送信する（処理（５）参照）。さらに、ＳＩＰサーバＡのテーブル生成部１４は、接続状態テーブルを生成する。ここで、ＳＩＰサーバＡの呼制御部１２は、ＨＴＴＰリクエストの受信に基づいて接続開始通知を生成している。テーブル生成部１４は、接続開始通知を受信し、接続状態テーブルにおいて接続状態を接続準備中に設定する。接続準備中とは、呼制御セッションの最中でありメディアセッションの接続準備中であることを意味する。図２８は、図２７の（ｄ１）に示す接続状態テーブルの一例である。呼ＩＤ毎に、主サーバ、代替サーバ、ＩＰ電話Ａのアドレス、ＩＰ電話Ｂのアドレス及び接続状態が登録されている。図２８の接続状態テーブルでは、呼制御セッションは呼ＩＤが12345678であり、接続状態は接続準備中に設定されている。ＳＩＰサーバＡの呼制御部１２は、接続状態テーブルをＳＩＰサーバＢに送信する（図２７中の処理（５）及び（ｄ１）参照）。
その後、ＳＩＰサーバＡの複製判断部１５がメディアセッションが成立したと判断した場合には、ＳＩＰサーバＡの呼制御部１２は接続完了通知を生成してＳＩＰサーバＢに送信する。これにより、ＳＩＰサーバＢのテーブル生成部１４は、接続状態を接続完了に変更する。例えば、呼ＩＤが11111111の呼制御セッションではメディアセッションが成立し、接続状態が接続完了に設定されている。
ＳＩＰサーバＡの呼制御部１２は、接続状態が接続準備中に設定された接続状態テーブルを複製し、接続開始通知とともにＳＩＰサーバＢに送信する。ＳＩＰサーバＢは、ＳＩＰサーバＡから接続開始通知を受信すると、前述の接続状態テーブルを受信して保持する。
その後、呼制御セッションに伴うメッセージの送受信が行われている時にＳＩＰサーバＡで障害が発生したとする。ＳＩＰサーバＢは、ＳＩＰサーバＡで障害が発生したことを検出するための確認パケットを常時送信しており、応答パケットに基づいてＳＩＰサーバＡでの障害を検出する（処理（９）、（１０）参照）。
その後、呼制御セッションに伴うメッセージの送受信が行われている時にＳＩＰサーバＡで障害が発生したとする。ＳＩＰサーバＢは、ＳＩＰサーバＡで障害が発生したことを検出するための確認パケットを常時送信しており、応答パケットに基づいてＳＩＰサーバＡでの障害を検出する（処理（９）、（１０）参照）。
ＳＩＰサーバＢの呼制御部１２は、接続状態テーブルにおいて、代替サーバがＳＩＰサーバＢであり、主サーバがＳＩＰサーバＡであり、接続状態が接続準備中であるレコードを検索する。つまり、ＳＩＰサーバＡにより制御されている呼制御セッションのうち、メディアセッションが成立しておらず、セッションが完了していない呼制御セッションを検索する。障害の発生によりＳＩＰサーバＡでは呼制御セッションを継続することができない。よって、ＳＩＰサーバＢは、検索された呼制御セッションに関係するＩＰ電話Ａ及びＩＰ電話ＢにＢＹＥメッセージを送信し、ＳＩＰサーバＡによる呼制御セッションを終了させる（処理（１１）、（１２）参照）。
その後、ＩＰ電話Ａ及びＩＰ電話Ｂは代替サーバであるＳＩＰサーバＢを介して呼制御セッションを行い、メディアセッションを成立させる（処理（１３）〜（１５）参照）。
以上より、代替サーバは、主サーバで障害が発生した場合、主サーバによる呼制御セッションのうち、まだ接続処理が完了していない中途半端な状態にある呼制御セッションを一旦開放することにより、システムの安定性を向上させることができる。
以上より、代替サーバは、主サーバで障害が発生した場合、主サーバによる呼制御セッションのうち、まだ接続処理が完了していない中途半端な状態にある呼制御セッションを一旦開放することにより、システムの安定性を向上させることができる。
（２−２）
上記（２−１）で生成した接続状態テーブルに関してリソースの無駄をなくす例について以下に説明する。
図２９は第２実施形態例に係る呼制御セッションを含むフローの別の一例である。図２９中の処理（１）〜（８）は、上記（２−１）と同じである。ＳＩＰサーバＡがＩＰ電話ＡにＩＮＶＩＴＥ（ｉｉｉ）メッセージを送信すると（処理（９）参照）、例えばＩＰ電話Ａがコードが５００のエラーメッセージを送信したとする（処理（１０）参照）。ＳＩＰサーバＡの呼制御部１２は、エラーメッセージをＩＰ電話Ａから受信すると、ＡＣＫメッセージ及びメディアセッションが不成立であることを示す接続失敗通知を生成する。呼制御部１２は、ＩＰ電話ＡにＡＣＫメッセージを送信するとともに（処理（１１）参照）、ＳＩＰサーバＢに接続失敗通知を送信する（処理（１２）参照）。
上記（２−１）で生成した接続状態テーブルに関してリソースの無駄をなくす例について以下に説明する。
図２９は第２実施形態例に係る呼制御セッションを含むフローの別の一例である。図２９中の処理（１）〜（８）は、上記（２−１）と同じである。ＳＩＰサーバＡがＩＰ電話ＡにＩＮＶＩＴＥ（ｉｉｉ）メッセージを送信すると（処理（９）参照）、例えばＩＰ電話Ａがコードが５００のエラーメッセージを送信したとする（処理（１０）参照）。ＳＩＰサーバＡの呼制御部１２は、エラーメッセージをＩＰ電話Ａから受信すると、ＡＣＫメッセージ及びメディアセッションが不成立であることを示す接続失敗通知を生成する。呼制御部１２は、ＩＰ電話ＡにＡＣＫメッセージを送信するとともに（処理（１１）参照）、ＳＩＰサーバＢに接続失敗通知を送信する（処理（１２）参照）。
ＳＩＰサーバＢの呼制御部１２は、接続失敗通知を受信すると、接続状態テーブルにおいて関連するレコードを削除する。ＳＩＰサーバＢの呼制御部１２は、ＳＩＰサーバＡにより制御されている呼制御セッションのうち、メディアセッションが成立していない呼制御セッションを検索し、検索されたレコードを削除する。つまり、ＳＩＰサーバＢの呼制御部１２は、接続失敗通知に応じて、代替サーバがＳＩＰサーバＢであり、主サーバがＳＩＰサーバＡであり、接続状態が接続準備中であるレコードを検索し削除する。これにより、不要なレコードを削除してリソースの無駄をなくす。なお、ＩＰ電話Ａにおいてエラーが発生したものの、ＳＩＰサーバＡは呼制御セッションを継続可能である。図３０は接続状態テーブルにおいて不要なレコードが削除される様子を示す模式図である。
（３）処理の流れ
次に、ＳＩＰサーバでのセッション情報複製方法の処理の流れについて図３１、図３２を用いて説明する。図３１及び図３２は、第２実施形態に係るＳＩＰサーバでのセッション情報複製方法の全体の流れを示すフローチャートの一例である。図３１は主サーバであるＳＩＰサーバＡでの処理の流れであり、図３２は代替サーバであるＳＩＰサーバＢでの処理の流れである。
次に、ＳＩＰサーバでのセッション情報複製方法の処理の流れについて図３１、図３２を用いて説明する。図３１及び図３２は、第２実施形態に係るＳＩＰサーバでのセッション情報複製方法の全体の流れを示すフローチャートの一例である。図３１は主サーバであるＳＩＰサーバＡでの処理の流れであり、図３２は代替サーバであるＳＩＰサーバＢでの処理の流れである。
（３−１）
まず、図３１を用いて主サーバであるＳＩＰサーバＡでの処理の流れについて説明する。
ステップＳ１１：ＳＩＰサーバＡの送受信部１１がパケットを送受信するとステップＳ２に進み、パケットを送受信していない場合は待機する。
まず、図３１を用いて主サーバであるＳＩＰサーバＡでの処理の流れについて説明する。
ステップＳ１１：ＳＩＰサーバＡの送受信部１１がパケットを送受信するとステップＳ２に進み、パケットを送受信していない場合は待機する。
ステップＳ１２：呼制御部１２は、発話要求であるＧＥＴメソッドのＨＴＴＰリクエストを受信すると、呼ＩＤ及びＳＩＰセッションＩＤを設定するとともに、これらのＩＤを含む呼設定要求、セッション情報及び接続開始通知を生成する。セッション情報ＤＢ２１はセッション情報を記憶する。
一方、呼制御部１２は、ＩＰ電話からメディアセッションの切断要求を受信すると、終了要求を生成する。
一方、呼制御部１２は、ＩＰ電話からメディアセッションの切断要求を受信すると、終了要求を生成する。
呼制御部１２は、呼制御セッションに伴うメッセージ及び呼設定要求を監視部１３及びテーブル生成部１４に送信する。
監視部１３がメッセージを受信するとステップＳ１８に進む。また、テーブル生成部１４が呼設定要求を受信するか、呼制御部１２が終了要求を生成するとステップＳ１３に進む。
監視部１３がメッセージを受信するとステップＳ１８に進む。また、テーブル生成部１４が呼設定要求を受信するか、呼制御部１２が終了要求を生成するとステップＳ１３に進む。
ステップＳ１３〜Ｓ１５：テーブル生成部１４は、呼制御部１２から呼設定要求を受信すると、情報テーブル２２を準備するととともに、呼ＩＤ、主サーバ、代替サーバ及び各ＩＰ電話のアドレス等を設定した接続状態テーブルを生成する（Ｓ１３、Ｓ１４）。さらに、テーブル生成部１４は、呼制御部１２からの接続開始通知を受けて該当する呼ＩＤの接続状態を接続準備中に設定する（Ｓ１５）。
ステップＳ１６：複製処理部１６は、メディアセッションの成立前に一旦セッション情報を複製するとともに、接続状態テーブルを複製し、これらを送信する
ステップＳ１７：送受信部１１は、呼制御部１２が生成した接続開始通知を代替サーバであるＳＩＰサーバＢに送信する。
ステップＳ１８、Ｓ１９：呼制御部１２は、受信したメッセージがエラーメッセージかどうかを判断する。エラーメッセージである場合は、呼制御部１２は、接続失敗通知を生成し代替サーバであるＳＩＰサーバＢに送信する。エラーメッセージで無い場合はステップＳ２０に進む。
ステップＳ１７：送受信部１１は、呼制御部１２が生成した接続開始通知を代替サーバであるＳＩＰサーバＢに送信する。
ステップＳ１８、Ｓ１９：呼制御部１２は、受信したメッセージがエラーメッセージかどうかを判断する。エラーメッセージである場合は、呼制御部１２は、接続失敗通知を生成し代替サーバであるＳＩＰサーバＢに送信する。エラーメッセージで無い場合はステップＳ２０に進む。
ステップＳ２０〜Ｓ２２：メディアセッションの成立判断処理を行い（Ｓ２０）、メディアセッションが成立した場合は接続完了通知を生成し、セッション情報を複製してＳＩＰサーバＢに送信する（Ｓ２１）。その後、情報テーブル２２を初期化する（Ｓ２２）。
（３−２）
次に、図３２を用いて代替サーバであるＳＩＰサーバＢでの処理の流れについて説明する。
（３−２）
次に、図３２を用いて代替サーバであるＳＩＰサーバＢでの処理の流れについて説明する。
ステップＳ２３：呼制御部１２は、受信したパケットに主サーバであるＳＩＰサーバＡからの通知が含まれるかを判断する。パケットに主サーバからの通知が含まれる場合はステップＳ２４に進み、そうでない場合はステップＳ３０に進む。
ステップＳ２４、Ｓ２５：呼制御部１２は、通知が接続開始通知である場合は、ＳＩＰサーバＡから接続状態テーブルを受信する。
ステップＳ２４、Ｓ２５：呼制御部１２は、通知が接続開始通知である場合は、ＳＩＰサーバＡから接続状態テーブルを受信する。
ステップＳ２６、Ｓ２７：呼制御部１２は、通知が接続完了通知である場合は、接続状態テーブルの該当レコードの接続状態を接続準備中から接続完了に変更する。
ステップＳ２８、Ｓ２９：呼制御部１２は、通知が接続失敗通知である場合は、接続状態テーブルの該当レコードを削除する。これによりリソースの無駄を省くことができる。
ステップＳ３０：呼制御部１２は、確認パケットに対する応答パケットを受信し、主ノードであるＳＩＰサーバＡで障害が発生しているかを判断する。主ノードで障害が発生している場合はステップＳ３１に進み、そうでない場合はステップＳ３３に進む。
ステップＳ２８、Ｓ２９：呼制御部１２は、通知が接続失敗通知である場合は、接続状態テーブルの該当レコードを削除する。これによりリソースの無駄を省くことができる。
ステップＳ３０：呼制御部１２は、確認パケットに対する応答パケットを受信し、主ノードであるＳＩＰサーバＡで障害が発生しているかを判断する。主ノードで障害が発生している場合はステップＳ３１に進み、そうでない場合はステップＳ３３に進む。
ステップＳ３１：呼制御部１２は、接続状態テーブルにおいて、ＳＩＰサーバＡにより制御されている呼制御セッションのうち、メディアセッションが成立していない呼制御セッションを検索する。
ステップＳ３２：ＳＩＰサーバＢの呼制御部１２は、検索されたレコードに関連するＩＰ電話Ａ及びＩＰ電話ＢにＢＹＥメッセージを送信し、ＳＩＰサーバＡによる呼制御セッションを終了させる。
ステップＳ３２：ＳＩＰサーバＢの呼制御部１２は、検索されたレコードに関連するＩＰ電話Ａ及びＩＰ電話ＢにＢＹＥメッセージを送信し、ＳＩＰサーバＡによる呼制御セッションを終了させる。
ステップＳ３３：呼制御部１２は、ＢＹＥメッセージなど終了要求をＩＰ電話に送信しＳＩＰサーバＢによる呼制御セッションを終了させる。それ以外の場合は、ステップＳ１に戻る。
（４）変形例
上記実施形態では、接続準備中の呼制御セッションにおいて障害が発生した時に、その呼制御セッションを開放できれば良い。よって、主サーバにより制御されている呼制御セッションのうち、接続準備中である呼制御セッションを把握できれば良い。よって、接続状態テーブルでは、少なくとも呼ＩＤ又は主サーバの識別子と、接続状態とが対応付けられていれば良い。
（４）変形例
上記実施形態では、接続準備中の呼制御セッションにおいて障害が発生した時に、その呼制御セッションを開放できれば良い。よって、主サーバにより制御されている呼制御セッションのうち、接続準備中である呼制御セッションを把握できれば良い。よって、接続状態テーブルでは、少なくとも呼ＩＤ又は主サーバの識別子と、接続状態とが対応付けられていれば良い。
また、メディアセッション成立前にセッション情報及び接続状態テーブルを生成してＳＩＰサーバＢに送信するタイミングは上記タイミングに限定されない。例えば、前記タイミングは、ＳＩＰサーバＡがＧＥＴメソッドのＨＴＴＰリクエストを受信してから、メディアセッションが成立するまでの間のどのタイミングでも良い。ただし、ＳＩＰサーバＡがＨＴＴＰリクエストを受信した時にセッション情報及び接続状態テーブルを生成してＳＩＰサーバＢに送信すると好ましい。これにより、呼制御セッションの初期に障害が発生した場合でも、代替サーバでが主サーバの呼制御セッションを引き継ぐことができる。
上記実施形態では、ＳＩＰサーバＡで接続状態テーブルを生成及び複製し、ＳＩＰサーバＢに送信する。しかし、ＳＩＰサーバＢが接続状態テーブルを生成しても良い。例えば、ＳＩＰサーバＡの複製処理部１５は、タイミングは特に限定されないが、メディアセッションの成立前に一旦セッション情報を複製しＳＩＰサーバＢに送信する。さらに、ＳＩＰサーバＡの呼制御部１２は、ＳＩＰサーバＡがメディアセッションの接続準備中である旨の通知をＳＩＰサーバＢに送信する。ＳＩＰサーバＢのテーブル生成部１４は、セッション情報及び前記通知に基づいて接続状態テーブルを生成する。
上記実施形態では、ＳＩＰサーバＢはＳＩＰサーバＡから接続完了通知を受信すると、接続状態テーブルの接続状態を接続完了に変更する。しかし、ＳＩＰサーバＢは、接続状態が接続完了に変更された接続状態テーブルをＳＩＰサーバＡから受信するようにしても良い。
セッション情報と接続状態テーブルとは一体であっても良い。例えば、セッション情報に接続状態を含めても良い。
セッション情報と接続状態テーブルとは一体であっても良い。例えば、セッション情報に接続状態を含めても良い。
また、第１実施形態と同様に、ＳＩＰサーバＢがセッション連携テーブルを保持しても良い。セッション連携テーブルをＳＩＰサーバＡからＳＩＰサーバＢに送信するタイミングは特に限定されないが、例えばメディアセッション成立前に一旦セッション情報が複製され送信されるのと同じタイミングでも良い。また、セッション情報が複製され送信されるよりも前のタイミングセッション連携テーブルを生成し送信しても良い。
＜その他の実施例＞
上記実施形態では、ブラウザ端末から発呼するサービスを例に挙げて説明したが、ＩＰ電話から直接発呼する場合にも本発明を適用可能である。この場合、まず、ＩＰ電話ＡからＩＮＶＩＴＥメッセージがＳＩＰサーバＡに送信される。ＳＩＰサーバＡはＩＰ電話ＡからのＩＮＶＩＴＥメッセージをＩＰ電話Ｂに転送する。さらに、ＩＰ電話Ａ及びＩＰ電話Ｂ間でＳＩＰサーバＡを介して２００ＯＫメッセージ及びＡＣＫメッセージの送受信が行われ、メディアセッションが成立する。
上記実施形態では、ブラウザ端末から発呼するサービスを例に挙げて説明したが、ＩＰ電話から直接発呼する場合にも本発明を適用可能である。この場合、まず、ＩＰ電話ＡからＩＮＶＩＴＥメッセージがＳＩＰサーバＡに送信される。ＳＩＰサーバＡはＩＰ電話ＡからのＩＮＶＩＴＥメッセージをＩＰ電話Ｂに転送する。さらに、ＩＰ電話Ａ及びＩＰ電話Ｂ間でＳＩＰサーバＡを介して２００ＯＫメッセージ及びＡＣＫメッセージの送受信が行われ、メディアセッションが成立する。
上記実施形態では、図３に示す各機能部により本発明の処理がなされているが、機能部全体として本発明の処理が成されれば良く、各処理の機能部の主体は図３の構成に限定されない。
上記実施形態では、ＳＩＰサーバは２台しか記載していないが、３台以上のＳＩＰサーバがネットワーク１００に接続されクラスタを構成していても良い。
上記実施形態では、ＳＩＰサーバは２台しか記載していないが、３台以上のＳＩＰサーバがネットワーク１００に接続されクラスタを構成していても良い。
また、ＧＥＴメソッドではなくＰＯＳＴメソッドによりＨＴＴＰリクエストを送信しても良い。
また、確認パケットの送信により障害を検出しているが、障害の検出方法はこれに限定されない。
また、前述したセッション情報複製方法を実行するシステム、前記セッション情報複製方法をコンピュータに実行させるコンピュータプログラム及びそのプログラムを記録したコンピュータ読み取り可能な記録媒体は、本発明の範囲に含まれる。ここで、コンピュータ読み取り可能な記録媒体としては、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ（Compact Disc−Read Only Memory）、ＭＯ（Magneto Optical disk）、ＤＶＤ（Digital Video Disc）、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ（ＤＶＤ−Random Access Memory）、ＢＤ（Blue-ray Disc）、半導体メモリを挙げることができる。前記コンピュータプログラムは、前記記録媒体に記録されたものに限られず、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク等を経由して伝送されるものであってもよい。
また、確認パケットの送信により障害を検出しているが、障害の検出方法はこれに限定されない。
また、前述したセッション情報複製方法を実行するシステム、前記セッション情報複製方法をコンピュータに実行させるコンピュータプログラム及びそのプログラムを記録したコンピュータ読み取り可能な記録媒体は、本発明の範囲に含まれる。ここで、コンピュータ読み取り可能な記録媒体としては、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ（Compact Disc−Read Only Memory）、ＭＯ（Magneto Optical disk）、ＤＶＤ（Digital Video Disc）、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ（ＤＶＤ−Random Access Memory）、ＢＤ（Blue-ray Disc）、半導体メモリを挙げることができる。前記コンピュータプログラムは、前記記録媒体に記録されたものに限られず、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク等を経由して伝送されるものであってもよい。
以上の実施形態及及びその他の実施形態に関し、更に以下の付記を開示する。
＜付記＞
（付記１）
発信端末及び着信端末間でメディアデータを送受信するためのメディアセッションを成立させる呼制御サーバが実行するセッション情報複製方法であって、
前記メディアセッションを成立させるための呼制御セッションにおいて、前記発信端末及び前記着信端末とメッセージの送受信を行う送受信ステップと、
前記呼制御セッションの実行に必要なセッション情報を生成するセッション情報生成ステップと、
前記メッセージに含まれる、メディアデータの送受信方法を定義したメディア情報を監視する監視ステップと、
前記メディア情報の監視結果に基づいて、前記メディアセッションの成立又は不成立を判断する複製判断ステップと、
前記メディアセッションが成立する場合、前記セッション情報を複製し、少なくとも１の他の呼制御サーバに送信する複製処理ステップと、
を含むセッション情報複製方法。
＜付記＞
（付記１）
発信端末及び着信端末間でメディアデータを送受信するためのメディアセッションを成立させる呼制御サーバが実行するセッション情報複製方法であって、
前記メディアセッションを成立させるための呼制御セッションにおいて、前記発信端末及び前記着信端末とメッセージの送受信を行う送受信ステップと、
前記呼制御セッションの実行に必要なセッション情報を生成するセッション情報生成ステップと、
前記メッセージに含まれる、メディアデータの送受信方法を定義したメディア情報を監視する監視ステップと、
前記メディア情報の監視結果に基づいて、前記メディアセッションの成立又は不成立を判断する複製判断ステップと、
前記メディアセッションが成立する場合、前記セッション情報を複製し、少なくとも１の他の呼制御サーバに送信する複製処理ステップと、
を含むセッション情報複製方法。
（付記２）
前記複製判断ステップでは、前記監視ステップにおいて、前記発信端末から受信したメディア情報の前記着信端末への送信を検出し、かつ、前記着信端末から受信したメディア情報の前記発信端末への送信を検出すると、前記メディアセッションが成立したと判断する、付記１に記載のセッション情報複製方法。
前記複製判断ステップでは、前記監視ステップにおいて、前記発信端末から受信したメディア情報の前記着信端末への送信を検出し、かつ、前記着信端末から受信したメディア情報の前記発信端末への送信を検出すると、前記メディアセッションが成立したと判断する、付記１に記載のセッション情報複製方法。
発信端末及び着信端末は、メディアセッションを開始する前に、呼制御セッションにおいてメディア情報を互いに送受信することでネゴシエーションを行い、メディアデータの送受信方法を確定する。よって、発信端末及び着信端末間においてメディア情報が送受信されたことを検出することで、メディアセッションの成立を判断することができる。よって、呼制御サーバは、発信端末から送信されたメディア情報を着信端末に送信したことを検出し、逆に着信端末から送信されたメディア情報を発信端末に送信したことを検出することで、メディアセッションが成立したと判断することができる。
ここで、メディア情報とはメディアデータの送受信方法を記述した情報であり、例えばメディアデータの送信先である送信先アドレス及びポート番号、送信可能なメディアデータの種類、メディアデータの符号化方式及び送信プロトコルなどが含まれる。
（付記３）
前記メディア情報は、前記メッセージの受信側が前記メディアデータを送信すべき送信先アドレスを含み、
前記複製判断ステップでは、前記監視ステップにおいて、前記発信端末から受信した送信先アドレスの前記着信端末への送信を検出し、かつ、前記着信端末から受信した送信先アドレスの前記発信端末への送信を検出すると、前記メディアセッションが成立したと判断する、付記２に記載のセッション情報複製方法。
（付記３）
前記メディア情報は、前記メッセージの受信側が前記メディアデータを送信すべき送信先アドレスを含み、
前記複製判断ステップでは、前記監視ステップにおいて、前記発信端末から受信した送信先アドレスの前記着信端末への送信を検出し、かつ、前記着信端末から受信した送信先アドレスの前記発信端末への送信を検出すると、前記メディアセッションが成立したと判断する、付記２に記載のセッション情報複製方法。
発信端末及び着信端末は、メディアセッションを行うためには、少なくともメディアデータを送信すべき送信先アドレスをそれぞれ取得する必要がある。よって、送信先アドレスが、発信端末及び着信端末間で呼制御サーバを介して送受信されたことを検出することで、メディアセッションの成立を判断することができる。
（付記４）
前記メディア情報は、前記メッセージの受信側が前記メディアデータを送信すべき送信先ポート番号をさらに含み、
前記複製判断ステップでは、さらに、前記監視ステップにおいて、前記発信端末から受信した送信先ポート番号の前記着信端末への送信を検出し、かつ、前記着信端末から受信した送信先ポート番号の前記発信端末への送信を検出すると、前記メディアセッションが成立したと判断する、付記３に記載のセッション情報複製方法。
（付記４）
前記メディア情報は、前記メッセージの受信側が前記メディアデータを送信すべき送信先ポート番号をさらに含み、
前記複製判断ステップでは、さらに、前記監視ステップにおいて、前記発信端末から受信した送信先ポート番号の前記着信端末への送信を検出し、かつ、前記着信端末から受信した送信先ポート番号の前記発信端末への送信を検出すると、前記メディアセッションが成立したと判断する、付記３に記載のセッション情報複製方法。
送信先アドレスの送受信に加えて、ポート番号が、発信端末及び着信端末間で呼制御サーバを介して送受信されたことを検出することで、仮のメディアセッションを特殊なポート番号(例えば0）により成立させる場合であっても端末間のメディアセッションの成立を正確に判断することができる （付記５）
特定のサービスを提供するサービスサーバに対して複数の特定アドレスを対応づけて格納する特定アドレス格納ステップと、
前記呼制御セッションにおいて、前記発信端末がメディアデータを送信すべき送信先アドレスとして、前記複数の特定アドレスのうち第１特定アドレスを割り当て、前記着信端末がメディアデータを送信すべき送信先アドレスとして、前記複数の特定アドレスから、前記第１特定アドレスとは異なる第２特定アドレスを割り当てる送信先アドレス割当ステップと、
をさらに含み、
前記複製判断ステップでは、前記監視ステップにおいて、前記発信端末に送信する送信先アドレスが前記第１特定アドレスであり、前記着信端末に送信する送信先アドレスが前記第２特定アドレスであることを検出すると、前記メディアセッションが成立したと判断する、付記３に記載のセッション情報複製方法。
特定のサービスを提供するサービスサーバに対して複数の特定アドレスを対応づけて格納する特定アドレス格納ステップと、
前記呼制御セッションにおいて、前記発信端末がメディアデータを送信すべき送信先アドレスとして、前記複数の特定アドレスのうち第１特定アドレスを割り当て、前記着信端末がメディアデータを送信すべき送信先アドレスとして、前記複数の特定アドレスから、前記第１特定アドレスとは異なる第２特定アドレスを割り当てる送信先アドレス割当ステップと、
をさらに含み、
前記複製判断ステップでは、前記監視ステップにおいて、前記発信端末に送信する送信先アドレスが前記第１特定アドレスであり、前記着信端末に送信する送信先アドレスが前記第２特定アドレスであることを検出すると、前記メディアセッションが成立したと判断する、付記３に記載のセッション情報複製方法。
サービスサーバは、例えば、通話の録音、通話中の各種アナウンス及びメディアデータの加工などの各種サービスを提供する。呼制御サーバは、自身のサービス以外にサービスサーバによるサービスを提供する場合、発信端末及び着信端末のメディアデータの送信先をサービスサーバに設定する。このとき、呼制御サーバは、サービスサーバに対応づけられた複数の特定アドレスの中から、発信端末及び着信端末がメディアデータを送信すべき送信先アドレスをそれぞれ割り当てる。発信端末及び着信端末が割り当てられた送信先アドレスを用いてメディアデータの送受信を行うとメディアセッションが成立する。よって、呼制御サーバが発信端末及び着信端末それぞれに第１特定アドレス及び第２特定アドレスを送信したことに基づいて、メディアセッションの成立を判断することができる。
（付記６）
前記複製判断ステップでは、さらに、前記送信先アドレスへの前記メディアデータの送信を了解するメッセージを前記発信端末及び前記着信端末から受信すると、前記メディアセッションが成立したと判断する、付記３に記載のセッション情報複製方法。
呼制御セッションを例えばＳＩＰ（Session Initiation Protocol）で行う場合、通話の要求、応答及び確認の３段階で行われる。例えば、呼制御サーバは、発信端末からメディア情報を含むＩＮＶＩＴＥメッセージを受信すると、そのメディア情報を含むＩＮＶＩＴＥメッセージを着信端末に送信する。これに対して、呼制御サーバが発信端末に２００ＯＫメッセージを送信すると、発信端末はＡＣＫメッセージを送信する。一方、着信端末がメディア情報を参照して２００ＯＫを送信すると、呼制御サーバは着信端末にＡＣＫメッセージを送信する。このように呼制御サーバと発信端末及び着信端末との呼制御セッションは３段階で行われるため、呼制御サーバは２００ＯＫメッセージ又はＡＣＫメッセージの送受信を検出することで、確実にメディアセッションの成立を判断することができる。
前記複製判断ステップでは、さらに、前記送信先アドレスへの前記メディアデータの送信を了解するメッセージを前記発信端末及び前記着信端末から受信すると、前記メディアセッションが成立したと判断する、付記３に記載のセッション情報複製方法。
呼制御セッションを例えばＳＩＰ（Session Initiation Protocol）で行う場合、通話の要求、応答及び確認の３段階で行われる。例えば、呼制御サーバは、発信端末からメディア情報を含むＩＮＶＩＴＥメッセージを受信すると、そのメディア情報を含むＩＮＶＩＴＥメッセージを着信端末に送信する。これに対して、呼制御サーバが発信端末に２００ＯＫメッセージを送信すると、発信端末はＡＣＫメッセージを送信する。一方、着信端末がメディア情報を参照して２００ＯＫを送信すると、呼制御サーバは着信端末にＡＣＫメッセージを送信する。このように呼制御サーバと発信端末及び着信端末との呼制御セッションは３段階で行われるため、呼制御サーバは２００ＯＫメッセージ又はＡＣＫメッセージの送受信を検出することで、確実にメディアセッションの成立を判断することができる。
（付記７）
前記他の呼制御サーバによる呼制御セッションの開始後から、前記呼制御セッションにより制御されるメディアセッションの成立前までのいずれかの時点において、前記他の呼制御サーバによる呼制御セッションの実行に必要なセッション情報を受信するセッション情報受信ステップをさらに含む、付記１に記載のセッション情報複製方法。
前記他の呼制御サーバによる呼制御セッションの開始後から、前記呼制御セッションにより制御されるメディアセッションの成立前までのいずれかの時点において、前記他の呼制御サーバによる呼制御セッションの実行に必要なセッション情報を受信するセッション情報受信ステップをさらに含む、付記１に記載のセッション情報複製方法。
一の呼制御サーバは、他の呼制御サーバにより制御されるメディアセッションの成立前に一旦セッション情報を受信する。よって、他の呼制御サーバにより制御されるメディアセッションの成立前に、他の呼制御サーバにおいて障害が発生した場合でも、セッション情報に基づいて他の呼制御サーバによる呼制御セッションを引き継ぐことができる。
（付記８）
前記セッション情報受信ステップでは、前記他の呼制御サーバによる呼制御セッションの開始時に、前記セッション情報を前記他の呼制御サーバから受信する、付記７に記載のセッション情報複製方法。
（付記８）
前記セッション情報受信ステップでは、前記他の呼制御サーバによる呼制御セッションの開始時に、前記セッション情報を前記他の呼制御サーバから受信する、付記７に記載のセッション情報複製方法。
呼制御セッションの開始時とは、呼制御セッションを開始するための最初のメッセージが送受信された時を言う。呼制御セッションの初期段階でセッション情報を受信することで、呼制御セッションの初期段階での障害発生にも対応することができる。
（付記９）
前記他の呼制御サーバの障害発生を検出する障害検出ステップと、
前記障害発生を検出すると、前記セッション情報に基づいて前記他の呼制御サーバによる呼制御セッションを終了させるための終了要求を送信する終了要求送信ステップと、
をさらに含む付記７に記載のセッション情報複製方法。
（付記９）
前記他の呼制御サーバの障害発生を検出する障害検出ステップと、
前記障害発生を検出すると、前記セッション情報に基づいて前記他の呼制御サーバによる呼制御セッションを終了させるための終了要求を送信する終了要求送信ステップと、
をさらに含む付記７に記載のセッション情報複製方法。
メディアセッションの成立前に他の呼制御サーバに障害が発生した場合でも、一の呼制御サーバが他の呼制御サーバによる呼制御セッションの終了を制御することができる。
（付記１０）
前記他の呼制御サーバによる呼制御セッションの状態を記憶する状態記憶ステップをさらに含む、付記７に記載のセッション情報複製方法。
（付記１０）
前記他の呼制御サーバによる呼制御セッションの状態を記憶する状態記憶ステップをさらに含む、付記７に記載のセッション情報複製方法。
これにより、引き継ぎの必要な呼制御セッションを把握することができる。一の呼制御サーバは、他の呼制御サーバで障害が発生した場合、他の呼制御サーバによる呼制御セッションのうち、まだメディアセッションが成立していない、つまり完了していない呼制御セッションを検索して引き継ぐ。
（付記１１）
前記他の呼制御サーバの呼制御セッションにより制御されるメディアセッションが不成立であるとの接続失敗通知を前記他の呼制御サーバから受信する接続失敗通知受信ステップと、
前記接続失敗通知を受信すると、前記状態記憶ステップで記憶された他の呼制御サーバによる呼制御セッションの状態を削除する削除ステップと、
をさらに含む付記１０に記載のセッション情報複製方法。
（付記１１）
前記他の呼制御サーバの呼制御セッションにより制御されるメディアセッションが不成立であるとの接続失敗通知を前記他の呼制御サーバから受信する接続失敗通知受信ステップと、
前記接続失敗通知を受信すると、前記状態記憶ステップで記憶された他の呼制御サーバによる呼制御セッションの状態を削除する削除ステップと、
をさらに含む付記１０に記載のセッション情報複製方法。
メディアセッションが不成立になった場合には、関連する呼制御セッションの記憶を削除することでリソースの無駄をなくすことができる。
（付記１２）
前記呼制御セッションは（Session Initiation Protocol）に基づいており、
前記監視ステップでは、前記呼制御セッションで送受信されるメッセージにおいて、ＳＤＰ（Session Description Protocol）により記述された前記メディア情報を監視する、付記１に記載のセッション情報複製方法。
（付記１２）
前記呼制御セッションは（Session Initiation Protocol）に基づいており、
前記監視ステップでは、前記呼制御セッションで送受信されるメッセージにおいて、ＳＤＰ（Session Description Protocol）により記述された前記メディア情報を監視する、付記１に記載のセッション情報複製方法。
ＳＩＰに基づいた呼制御セッションではメッセージが送受信される。メッセージは、要求の種別を記述したスタートライン、呼制御セッションの送信元及び送信先などを記述したヘッダ、メディア情報を含むボディから構成される。メディア情報は、メディアデータを送受信する端末のアドレス及びポート番号、メディアデータの種類、符号化方式などのメディアデータの送受信方法に関する情報であり、ＳＤＰで記述されている。このようなメディア情報を参照することで、メディアセッションの成立を判断することができる。
（付記１３）
メディアセッションの開始を他の呼制御サーバに要求するＨＴＴＰ（Hypertext Transfer Protocol）によるＨＴＴＰセッションの識別子と、前記ＨＴＴＰセッションにより開始する前記他の呼制御サーバによる呼制御セッションの識別子と、の対応付けを、前記他の呼制御サーバから受信し記憶する対応付け記憶ステップをさらに含む、付記１１に記載のセッション情報複製方法。
メディアセッションの開始を他の呼制御サーバに要求するＨＴＴＰ（Hypertext Transfer Protocol）によるＨＴＴＰセッションの識別子と、前記ＨＴＴＰセッションにより開始する前記他の呼制御サーバによる呼制御セッションの識別子と、の対応付けを、前記他の呼制御サーバから受信し記憶する対応付け記憶ステップをさらに含む、付記１１に記載のセッション情報複製方法。
例えば、発呼者のＩＰ電話、発呼者のブラウザ端末、他の呼制御サーバ及び着呼者のＩＰ電話がネットワークを介して接続されている。発呼者がブラウザ端末で発呼者の電話番号及び着呼者の電話番号を入力して発呼したとする。このような場合、発呼者のブラウザ端末及び他の呼制御サーバ間のＨＴＴＰセッションと、発呼者のＩＰ電話、着呼者のＩＰ電話及び他の呼制御サーバ間の呼制御セッションと、を対応づける。この対応付けは、前記他の呼制御サーバ及び一の呼制御サーバなど複数の呼制御サーバに共有される。前記他の呼制御サーバに障害が発生し、発呼者がブラウザ端末から一の呼制御サーバにＨＴＴＰメッセージを送信したとする。一の呼制御サーバは、ＨＴＴＰメッセージからＨＴＴＰセッションの識別子を取得し、さらに前記対応付けから呼制御セッションの識別子を取得する。これにより、一の呼制御サーバは他の呼制御サーバによる呼制御セッションを引き継ぐことができる。一方、ユーザはブラウザ端末からメディアセッションの終了などの呼制御セッションを実行させることができる。
（付記１４）
発信端末及び着信端末間でメディアデータを送受信するためのメディアセッションを成立させる呼制御サーバであって、
前記メディアセッションを成立させるための呼制御セッションにおいて、前記発信端末及び前記着信端末とメッセージの送受信を行う送受信手段と、
前記呼制御セッションの実行に必要なセッション情報を生成するセッション情報生成手段と、
前記メッセージに含まれる、メディアデータの送受信方法を定義したメディア情報を監視する監視手段と、
前記メディア情報の監視結果に基づいて、前記メディアセッションの成立又は不成立を判断する複製判断手段と、
前記メディアセッションが成立する場合、前記セッション情報を複製し、少なくとも１の他の呼制御サーバに送信する複製処理手段と、
を含む呼制御サーバ。
発信端末及び着信端末間でメディアデータを送受信するためのメディアセッションを成立させる呼制御サーバであって、
前記メディアセッションを成立させるための呼制御セッションにおいて、前記発信端末及び前記着信端末とメッセージの送受信を行う送受信手段と、
前記呼制御セッションの実行に必要なセッション情報を生成するセッション情報生成手段と、
前記メッセージに含まれる、メディアデータの送受信方法を定義したメディア情報を監視する監視手段と、
前記メディア情報の監視結果に基づいて、前記メディアセッションの成立又は不成立を判断する複製判断手段と、
前記メディアセッションが成立する場合、前記セッション情報を複製し、少なくとも１の他の呼制御サーバに送信する複製処理手段と、
を含む呼制御サーバ。
（付記１５）
発信端末及び着信端末間でメディアデータを送受信するためのメディアセッションを成立させるコンピュータが実行するセッション情報複製プログラムであって、
前記メディアセッションを成立させるための呼制御セッションにおいて、前記発信端末及び前記着信端末とメッセージの送受信を行う送受信ステップと、
前記呼制御セッションの実行に必要なセッション情報を生成するセッション情報生成ステップと、
前記メッセージに含まれる、メディアデータの送受信方法を定義したメディア情報を監視する監視ステップと、
前記メディア情報の監視結果に基づいて、前記メディアセッションの成立又は不成立を判断する複製判断ステップと、
前記メディアセッションが成立する場合、前記セッション情報を複製し、少なくとも１の他の呼制御サーバに送信する複製処理ステップと、
をコンピュータに実行させるためのセッション情報複製プログラム。
発信端末及び着信端末間でメディアデータを送受信するためのメディアセッションを成立させるコンピュータが実行するセッション情報複製プログラムであって、
前記メディアセッションを成立させるための呼制御セッションにおいて、前記発信端末及び前記着信端末とメッセージの送受信を行う送受信ステップと、
前記呼制御セッションの実行に必要なセッション情報を生成するセッション情報生成ステップと、
前記メッセージに含まれる、メディアデータの送受信方法を定義したメディア情報を監視する監視ステップと、
前記メディア情報の監視結果に基づいて、前記メディアセッションの成立又は不成立を判断する複製判断ステップと、
前記メディアセッションが成立する場合、前記セッション情報を複製し、少なくとも１の他の呼制御サーバに送信する複製処理ステップと、
をコンピュータに実行させるためのセッション情報複製プログラム。
１１：送受信部
１２：呼制御部
１３：監視部
１４：テーブル生成部
１５：複製判断部
１６：複製処理部
２１：セッション情報ＤＢ
２２：情報テーブル
２３：クラスタ構成テーブル
２４：特定アドレステーブル
１２：呼制御部
１３：監視部
１４：テーブル生成部
１５：複製判断部
１６：複製処理部
２１：セッション情報ＤＢ
２２：情報テーブル
２３：クラスタ構成テーブル
２４：特定アドレステーブル
Claims (10)
- 発信端末及び着信端末間でメディアデータを送受信するためのメディアセッションを成立させる呼制御サーバが実行するセッション情報複製方法であって、
前記メディアセッションを成立させるための呼制御セッションにおいて、前記発信端末及び前記着信端末とメッセージの送受信を行う送受信ステップと、
前記呼制御セッションの実行に必要なセッション情報を生成するセッション情報生成ステップと、
前記メッセージに含まれる、メディアデータの送受信方法を定義したメディア情報を監視する監視ステップと、
前記メディア情報の監視結果に基づいて、前記メディアセッションの成立又は不成立を判断する複製判断ステップと、
前記メディアセッションが成立する場合、前記セッション情報を複製し、少なくとも１の他の呼制御サーバに送信する複製処理ステップと、
を含むセッション情報複製方法。 - 前記複製判断ステップでは、前記監視ステップにおいて、前記発信端末から受信したメディア情報の前記着信端末への送信を検出し、かつ、前記着信端末から受信したメディア情報の前記発信端末への送信を検出すると、前記メディアセッションが成立したと判断する、請求項１に記載のセッション情報複製方法。
- 前記メディア情報は、前記メッセージの受信側が前記メディアデータを送信すべき送信先アドレスを含み、
前記複製判断ステップでは、前記監視ステップにおいて、前記発信端末から受信した送信先アドレスの前記着信端末への送信を検出し、かつ、前記着信端末から受信した送信先アドレスの前記発信端末への送信を検出すると、前記メディアセッションが成立したと判断する、請求項２に記載のセッション情報複製方法。 - 前記メディア情報は、前記メッセージの受信側が前記メディアデータを送信すべき送信先ポート番号をさらに含み、
前記複製判断ステップでは、さらに、前記監視ステップにおいて、前記発信端末から受信した送信先ポート番号の前記着信端末への送信を検出し、かつ、前記着信端末から受信した送信先ポート番号の前記発信端末への送信を検出すると、前記メディアセッションが成立したと判断する、請求項３に記載のセッション情報複製方法。 - 特定のサービスを提供するサービスサーバに対して複数の特定アドレスを対応づけて格納する特定アドレス格納ステップと、
前記呼制御セッションにおいて、前記発信端末がメディアデータを送信すべき送信先アドレスとして、前記複数の特定アドレスのうち第１特定アドレスを割り当て、前記着信端末がメディアデータを送信すべき送信先アドレスとして、前記複数の特定アドレスから、前記第１特定アドレスとは異なる第２特定アドレスを割り当てる送信先アドレス割当ステップと、
をさらに含み、
前記複製判断ステップでは、前記監視ステップにおいて、前記発信端末に送信する送信先アドレスが前記第１特定アドレスであり、前記着信端末に送信する送信先アドレスが前記第２特定アドレスであることを検出すると、前記メディアセッションが成立したと判断する、請求項３に記載のセッション情報複製方法。 - 前記他の呼制御サーバによる呼制御セッションの開始後から、前記呼制御セッションにより制御されるメディアセッションの成立前までのいずれかの時点において、前記他の呼制御サーバによる呼制御セッションの実行に必要なセッション情報を受信するセッション情報受信ステップをさらに含む、請求項１に記載のセッション情報複製方法。
- 前記セッション情報受信ステップでは、前記他の呼制御サーバによる呼制御セッションの開始時に、前記セッション情報を前記他の呼制御サーバから受信する、請求項６に記載のセッション情報複製方法。
- 前記他の呼制御サーバによる呼制御セッションの状態を記憶する状態記憶ステップをさらに含む、請求項６に記載のセッション情報複製方法。
- 発信端末及び着信端末間でメディアデータを送受信するためのメディアセッションを成立させる呼制御サーバであって、
前記メディアセッションを成立させるための呼制御セッションにおいて、前記発信端末及び前記着信端末とメッセージの送受信を行う送受信手段と、
前記呼制御セッションの実行に必要なセッション情報を生成するセッション情報生成手段と、
前記メッセージに含まれる、メディアデータの送受信方法を定義したメディア情報を監視する監視手段と、
前記メディア情報の監視結果に基づいて、前記メディアセッションの成立又は不成立を判断する複製判断手段と、
前記メディアセッションが成立する場合、前記セッション情報を複製し、少なくとも１の他の呼制御サーバに送信する複製処理手段と、
を含む呼制御サーバ。 - 発信端末及び着信端末間でメディアデータを送受信するためのメディアセッションを成立させるコンピュータが実行するセッション情報複製プログラムであって、
前記メディアセッションを成立させるための呼制御セッションにおいて、前記発信端末及び前記着信端末とメッセージの送受信を行う送受信ステップと、
前記呼制御セッションの実行に必要なセッション情報を生成するセッション情報生成ステップと、
前記メッセージに含まれる、メディアデータの送受信方法を定義したメディア情報を監視する監視ステップと、
前記メディア情報の監視結果に基づいて、前記メディアセッションの成立又は不成立を判断する複製判断ステップと、
前記メディアセッションが成立する場合、前記セッション情報を複製し、少なくとも１の他の呼制御サーバに送信する複製処理ステップと、
をコンピュータに実行させるためのセッション情報複製プログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008076330A JP5169362B2 (ja) | 2008-03-24 | 2008-03-24 | セッション情報複製方法、前記方法を実行する呼制御サーバ及び前記方法のプログラム |
| US12/405,841 US8296447B2 (en) | 2008-03-24 | 2009-03-17 | Method for copying session information, call control server for executing the same, and computer product |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008076330A JP5169362B2 (ja) | 2008-03-24 | 2008-03-24 | セッション情報複製方法、前記方法を実行する呼制御サーバ及び前記方法のプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2009230540A JP2009230540A (ja) | 2009-10-08 |
| JP5169362B2 true JP5169362B2 (ja) | 2013-03-27 |
Family
ID=41089962
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008076330A Expired - Fee Related JP5169362B2 (ja) | 2008-03-24 | 2008-03-24 | セッション情報複製方法、前記方法を実行する呼制御サーバ及び前記方法のプログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US8296447B2 (ja) |
| JP (1) | JP5169362B2 (ja) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9357025B2 (en) * | 2007-10-24 | 2016-05-31 | Social Communications Company | Virtual area based telephony communications |
| KR101702417B1 (ko) * | 2009-11-09 | 2017-02-06 | 삼성전자주식회사 | ＵＰｎＰ를 이용한 호 송수신 시스템에서 통화의 독점권을 부여하는 방법 및 장치 |
| CN102377887B (zh) * | 2010-08-12 | 2015-08-12 | 中兴通讯股份有限公司 | 一种实现网络电话呼叫建立的方法及系统 |
| CN102932319B (zh) * | 2011-08-12 | 2016-03-16 | 上海贝尔股份有限公司 | 一种用于保持通话的方法和装置 |
| US9148359B2 (en) * | 2011-12-22 | 2015-09-29 | Voipfuture Gmbh | Correlation of media plane and signaling plane of media services in a packet-switched network |
| US20130163582A1 (en) * | 2011-12-26 | 2013-06-27 | Jaya MEGHANI | Systems and methods of managing communication requests in a voip communication system |
| EP2881861B1 (en) * | 2012-08-02 | 2017-05-31 | Murakumo Corporation | Load distribution device, information processing system, method, and program |
| JP2014103614A (ja) * | 2012-11-22 | 2014-06-05 | Hitachi Ltd | 通信システム |
| US9197994B2 (en) * | 2014-01-29 | 2015-11-24 | Kaseya Limited | Identifying mobile device location and corresponding support center locations to provide support services over a network |
| US10805845B2 (en) | 2016-08-05 | 2020-10-13 | Telefonaktiebolaget Lm Ericsson (Publ) | Supporting transport protocol server relocation |
| WO2018024344A1 (en) | 2016-08-05 | 2018-02-08 | Telefonaktiebolaget Lm Ericsson (Publ) | Transport protocol server relocation |
| US10630696B1 (en) * | 2016-09-23 | 2020-04-21 | Wells Fargo Bank, N.A. | Storing call session information in a telephony system |
| US11025765B2 (en) * | 2019-09-30 | 2021-06-01 | Harman International Industries, Incorporated (STM) | Wireless audio guide |
Family Cites Families (32)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6404870B1 (en) * | 1998-09-14 | 2002-06-11 | Cisco Technology, Inc. | Method and apparatus for authorization based phone calls in packet switched networks |
| KR100689540B1 (ko) * | 2000-03-20 | 2007-03-08 | 삼성전자주식회사 | 사설 아이피 네트워크를 통한 다중 통화 장치 및 방법 |
| NO20010069L (no) * | 2001-01-05 | 2002-07-08 | Ericsson Telefon Ab L M | Flerbrukerapplikasjoner i multimedianett |
| US7272651B1 (en) * | 2001-08-28 | 2007-09-18 | Cisco Technology, Inc. | RSVP transmitter proxy |
| JP3772836B2 (ja) * | 2003-01-27 | 2006-05-10 | 村田機械株式会社 | 通信端末装置 |
| JP4105722B2 (ja) * | 2003-05-27 | 2008-06-25 | 富士通株式会社 | 通信装置 |
| JP3788447B2 (ja) * | 2003-06-30 | 2006-06-21 | 株式会社日立製作所 | セッション制御サーバ、プレゼンスサーバ、セッション制御装置、当該セッション制御装置に適用されるソフトウェア、セッション制御方法、およびネットワークシステム |
| DE602004025819D1 (de) | 2003-08-14 | 2010-04-15 | Oracle Int Corp | Transparente sitzungs-migration über server hinweg |
| US20050076099A1 (en) * | 2003-10-03 | 2005-04-07 | Nortel Networks Limited | Method and apparatus for live streaming media replication in a communication network |
| JP4261395B2 (ja) * | 2004-03-17 | 2009-04-30 | ソフトバンクモバイル株式会社 | サーバ装置 |
| SE528466C2 (sv) * | 2004-07-05 | 2006-11-21 | Ericsson Telefon Ab L M | En metod och apparat för att genomföra en kommunikationssession mellan två terminaler |
| KR101214326B1 (ko) * | 2004-07-09 | 2012-12-21 | 텔레폰악티에볼라겟엘엠에릭슨(펍) | 멀티미디어 통신 시스템에서 여러 서비스를 제공하는 방법및 장치 |
| US7805517B2 (en) * | 2004-09-15 | 2010-09-28 | Cisco Technology, Inc. | System and method for load balancing a communications network |
| JP4319971B2 (ja) * | 2004-11-22 | 2009-08-26 | 株式会社日立製作所 | セッション情報管理システム、セッション情報管理方法およびそのプログラム |
| JP4735068B2 (ja) * | 2005-06-15 | 2011-07-27 | 沖電気工業株式会社 | 通信システム、通信方法及び通信装置 |
| JP4664127B2 (ja) * | 2005-06-16 | 2011-04-06 | パナソニック株式会社 | 通信端末および通信切替方法 |
| JP2007004361A (ja) | 2005-06-22 | 2007-01-11 | Mitsubishi Electric Corp | 負荷分散装置 |
| US8099504B2 (en) * | 2005-06-24 | 2012-01-17 | Airvana Network Solutions, Inc. | Preserving sessions in a wireless network |
| US7668904B2 (en) * | 2005-07-28 | 2010-02-23 | International Business Machines Corporation | Session replication |
| US7702947B2 (en) * | 2005-11-29 | 2010-04-20 | Bea Systems, Inc. | System and method for enabling site failover in an application server environment |
| PL1969856T3 (pl) * | 2006-01-05 | 2013-01-31 | Ericsson Telefon Ab L M | Zarządzanie plikiem zasobnika medialnego |
| CN101005649A (zh) * | 2006-01-19 | 2007-07-25 | 华为技术有限公司 | 一种多方通信业务的连接建立方法及系统 |
| CN101083541B (zh) * | 2006-05-31 | 2013-05-01 | 朗迅科技公司 | Ims网关系统和方法 |
| US7711848B2 (en) * | 2006-06-15 | 2010-05-04 | Oracle International Corporation | System using session initiation protocol for seamless network switching in a media streaming session |
| US8842818B2 (en) * | 2006-06-30 | 2014-09-23 | Avaya Inc. | IP telephony architecture including information storage and retrieval system to track fluency |
| US8255457B2 (en) * | 2006-09-01 | 2012-08-28 | Microsoft Corporation | Adaptive content load balancing |
| US7661027B2 (en) * | 2006-10-10 | 2010-02-09 | Bea Systems, Inc. | SIP server architecture fault tolerance and failover |
| US8406123B2 (en) * | 2006-12-11 | 2013-03-26 | International Business Machines Corporation | Sip presence server failover |
| JP2008219454A (ja) * | 2007-03-05 | 2008-09-18 | Hitachi Ltd | 通信内容監査支援システム |
| US20080228926A1 (en) * | 2007-03-13 | 2008-09-18 | Asher Shiratzky | Methods, media, and systems for balancing session initiation protocol server load |
| US20080250097A1 (en) * | 2007-04-04 | 2008-10-09 | Adadeus S.A.S | Method and system for extending the services provided by an enterprise service bus |
| US8396054B2 (en) * | 2007-05-03 | 2013-03-12 | Utbk, Llc | Systems and methods to facilitate searches of communication references |
-
2008
- 2008-03-24 JP JP2008076330A patent/JP5169362B2/ja not_active Expired - Fee Related
-
2009
- 2009-03-17 US US12/405,841 patent/US8296447B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US8296447B2 (en) | 2012-10-23 |
| JP2009230540A (ja) | 2009-10-08 |
| US20090240803A1 (en) | 2009-09-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5169362B2 (ja) | セッション情報複製方法、前記方法を実行する呼制御サーバ及び前記方法のプログラム | |
| Rosenberg et al. | SIP: session initiation protocol | |
| JP5145339B2 (ja) | クライアントにより制御される動的コール転送 | |
| Rosenberg et al. | RFC3261: SIP: session initiation protocol | |
| US20080228926A1 (en) | Methods, media, and systems for balancing session initiation protocol server load | |
| JP2007504758A (ja) | 遠隔通信ネットワークシステムおよびセッション開始プロトコルを使用する通信サービス方法 | |
| EP2079024A1 (en) | Proxy server, communication system, communication method, and program | |
| JP2005229273A (ja) | サーババックアップ装置 | |
| JP2008104112A (ja) | 送信経路設定装置、送信経路設定方法および送信経路設定プログラム | |
| US8503429B2 (en) | Processing requests and generating responses in session initiation protocol (SIP) | |
| US20110295943A1 (en) | Data processing system and method | |
| US20170064075A1 (en) | Continuous call recording | |
| US10230801B2 (en) | Session reconstruction using proactive redirect | |
| JP4608371B2 (ja) | Ｓｉｐサービス変換装置、およびその方法 | |
| JP2008219461A (ja) | 通信履歴情報管理システム、ｓｉｐクライアント端末、履歴サーバおよび通信履歴情報管理方法 | |
| CN1988546A (zh) | 获取会话起始协议消息传输路径的方法及系统 | |
| US20040160985A1 (en) | System and method for network address translation and session management | |
| JP2006345231A (ja) | Ｓｉｐ−ａｌｇ方法 | |
| JP2007208542A (ja) | 呼制御信号転送装置、呼制御信号転送方法および呼制御信号転送プログラム | |
| JP4723676B2 (ja) | セッション状態の通知に係る通信方法、サーバ、およびプログラム | |
| US10051014B2 (en) | Data processing | |
| CN109067659B (zh) | 一种会话建立方法、路由器及会话系统 | |
| KR100894906B1 (ko) | 세션 설정 프로토콜 기반의 ｉｐ 멀티미디어 서비스를제공하는 단말장치, 호 세션 제어 기능 장치 및 이를이용한 서비스 요청 송/수신 방법 | |
| JP2006350635A (ja) | セッション管理システム、セッション管理方法、サーバ及び通信システム | |
| WO2015131466A1 (zh) | 基于会话初始协议sip的数据业务处理方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20101119 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20121204 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20121217 |
|
| LAPS | Cancellation because of no payment of annual fees |