JP2010154518A

JP2010154518A - 同一ＩＰポートを使用するアｅｔｈａｎｅｔプリケーションの複数のインスタンス間で、受信したセッションを送信するための方法およびシステム

Info

Publication number: JP2010154518A
Application number: JP2009265736A
Authority: JP
Inventors: Kirill Tsym; チムキリル
Original assignee: Polycom Inc
Current assignee: Polycom Inc
Priority date: 2008-11-25
Filing date: 2009-11-20
Publication date: 2010-07-08
Anticipated expiration: 2029-11-20
Also published as: US8849972B2; EP2202946A2; US20160308921A1; US9379984B2; EP2202946A3; JP5629086B2; TWI419518B; TW201023565A; CN103533065A; DE09013668T1; CN101741832B; US20100131656A1; US20150026328A1; US9992247B2; US20180248921A1; US10609096B2; CN101741832A

Abstract

【課題】同一のIPホストで実行され、インターネットを介して同時に通信する多数のアプリケーションプログラムの分野に関し、同一のアプリケーションプログラムの多数のインスタンスが同時に同一のIPポートで聞くことを可能にする。
【解決手段】通信ビデオ会議信号および制御プロトコルを受け取るための周知のポートが、プロトコルスタックアプリケーションの多数のインスタンスにロードバランスされ、多重化される。多数のアプリケーションインスタンスにわたってマルチメディアデータストリームをバランスさせることによって、前記マルチメディアデータストリームは、単一のインターネットプロトコルホストプロセッサによって処理される。
【選択図】図１

Description

本発明は、同一のIPホストで実行され、インターネットを介して同時に通信する多数のアプリケーションプログラムの分野に関し、特に、同一のアプリケーションプログラムの多数のインスタンスが同時に同一のIPポートで聞くことを可能にするシステムおよび方法に関する。

関連出願の説明
本出願は、“Method and System for Dispatching Received Sessions Between a Plurality of Instances of an Application Using the Same IP Port(同一IPポートを使用するアプリケーションの複数のインスタンス間で、受信したセッションを送信するための方法およびシステム)”というタイトルでKirill Tsymによって2008年12月25日に出願された米国特許仮出願No.61/117619の優先権を主張するものである。この出典を記載することによって本明細書の一部とする。

ネットワークトラフィックが急成長し続け、ますます多くの開発者がネットワーク商品およびソリューションを紹介するのに伴い、予め定義された周知のネットワークポートを使用するアプリケーションプログラム(プロセス)の数が増加している。これらのアプリケーションプログラムは、例えば、1つの周知の予め定義された伝送制御プロトコル(TCP)および/またはトランスポートレイヤセキュリティ(TLS)および/またはユーザデータグラムプロトコル(UDP)ポート番号でリスン必要がある。セッション開始プロトコル(SIP)およびH.323プロトコルは、上記のような周知のTCPまたはUDPポート番号でリスンすることができる上記アプリケーションプログラム(プロセス)の例である。

様々異なる種類のネットワーク装置は、同一の特定のポート番号を使用して、アプリケーションプログラム(処理)の2つ以上のインスタンスが同時に動作することを可能にするものである場合、より高い拡張性、ロバスト性およびロードバランシングを実現できるであろう。このようなネットワーク装置の一例はMCUである。MCUは、ネットワークのノードまたは端末に存在する会議制御エンティティである。MCUは、特定の規準に従って、アクセスポートから複数の媒体、シグナリングおよび制御チャンネルを受け取り、処理し、そして、これらを接続されたチャンネルに分配する。MCUの例としては、MGC-100およびRMX2000(Polycom. Inc.)がある。MCUは、2つの論理ユニット、すなわち、媒体コントローラ(MC)および媒体プロセッサ(MP)で構成可能である。エンドポイント(端末)およびMCUの更に詳細な定義は、H.320、H.324およびH.323規格のような(しかしこれらに限られない)International telecommunication Union (“ITU”)規格に見られる。前記MCUは、複数のユーザ(クライアント)間の複数のセッションを同時に処理するよう要求される。従って、MCUは、互いに異なるセッションについて、同一のアプリケーションプログラムである例えばH.323の2つ以上のインスタンスを同時に使用することを必要とする。残念ながら、オペレーティングシステム(OS)は、ただ1つのアプリケーション/アプリケーションインスタンス(処理)のみが同一のIPホスト上の特定のポート番号でリスンできるので、ポートリスニング上の制約を有する。この明細書においては、アプリケーション、アプリケーションプログラムおよびプロセス(処理)という用語は、互換的に使用されている。

H.323は、リアルタイムオーディオ、ビデオおよびデータ情報が伝送される態様を定義する、パケットに基づくネットワークを介したマルチメディア通信のためにコンピュータ、機器およびサービスの仕様を提供するInternational telecommunication Union (ITU)規格である。H.323は、一般的にVoIP、Internet Telephony(インターネット電話)およびIPに基づくビデオ会議で使用される。ユーザは、インターネットを介して他のユーザと接続し、H.323をサポートする様々な製品を使用することができる。この規格は、Internet Engineering Task Force (IETF) Real-Time Protocol (RTP)およびReal-Time Control Protocol (RTCP)、ならびに、コールシグナリングおよびデータ、オーディオビジュアル通信のためのその他のプロトコルを含む。

IETF SIPは、アプリケーション-レイヤプロトコルであり、Internet Telephonyのためのシグナリングプロトコルである。SIPは、IPネットワークを介して展開すべきオーディオ/ビデオ会議、インタラクテイブゲームおよび通話転送のような機能のためのセッションを確立することができ、これにより、サービスプロバイダが基本的なIP電話サービスをインターネット、イーメイルおよびチャットサービスと一体化することを可能にする。ユーザ認証、リダイレクト(出力先変更)および登録サービスに加えて、SIPサーバは、呼ばれている人の地理的位置に基づく個人的移動性、ルーティング(経路指定)および通話転送等の伝統的な電話機能をサポートする。

アプリケーションプログラムが多数のポートで着信(入ってくるコール)をリスンすることを可能にする技術がある。しかし、このようなシステムは、オペレーティングシステムにトランスポート要素およびネットワーク要素を追加する(常に可能というわけではない)ことを必要とする。このようなシステムは、更に、ユーザ(クライアント)が前記アプリケーションに接続するために伝送するために必要とする文字列を予め定義することを必要とする場合がある。前記予め定義された文字列を知らないユーザ(クライアント)は前記アプリケーションプログラムを参照たり該アプリケーションプログラムに接続したりすることができない。さらに、このようなシステムは、同一アプリケーションの複数のインスタンスが同一のポートでリスンすることを可能にしない。他の技術としては、接続サービス(多数の異なるアプリケーションインスタンス)が1つのスタティックポートでリスンすることを可能にするものがある。これらの方法は、各アプリケーション/インスタンス毎にユニークなIDを予め定義し、これらのユニークなIDをクライアントに通知することを必要し、そうでないと、前記クライアントはサービスを受けられない。この明細書において、“ユーザ”および“クライアント”という用語は同じ意味で、つまり、互換的に使用されている。

従って、当該技術分野においては、多数のアプリケーションインスタンスが同一のリスニングポートを使用して同時に動作できるようにする方法およびシステムが必要とされている。このような方法およびシステムは、クライアントが予め定義されたユニークなIDまたは提供すべき特別な文字列を通知されることを必要としない。さらに、OSレベルの変更が必要でないことが望ましい。

上記の課題は、多数のアプリケーションインスタンスがロードバランシング(load-balancing: 並列的に運用されている機器間での負荷がなるべく均等になるように処理を分散して割り当てること)技術を使用して同時に同一のリスニングポートを使用することを可能にする、ここに開示された方法および装置/システムによって満たされる。前記方法および装置は、オペレーティングシステムにおける変更を必要としない。

ロードバランサーモジュール(LBM)と呼ばれる論理モジュールは、特定の共通する予め定義されたポート番号にリスンする。ポート番号1720は、例えば、H.323プロトコルに基づく通信情報を受信するための周知のポートである。典型的なH.323LBMは、すべてのH.323インスタンス(タスク)についてのH.323接続リクエストを受信するためにポート番号1720にリスンするよう構成されてよい。他の典型的なH.323LBMは、SIPプロトコル(SIP LBM)に基づく通信について周知のポート番号5060および/または5061にリスンするよう構成されてよい。H.323通信はTCPに基づき、SIP通信はTCP、TLS/TCまたはUDPに基づくことができる。ビデオ会議ネットワークの典型的なアーキテクチャにおいては、SIPクライアントは、SIPプロキシを介して、ここに開示されているような技術例を実現するMCUに接続されえる。前記SIPプロキシと前記MCUとの間のトランスポートプロトコルは、例えば、アドミニストレータによって構成可能である。場合によっては、2つ以上のトランスポートプロトコルが、前記プロキシと前記MCUとの間で使用されてよい。

H.323LBMは、H.323スタックの複数のインスタンス(タスク)に接続される。一実施の形態において、各LBMとそれに対応付けられたインスタンスとの内部接続は、例えば、Unitドメインソケットのような(しかしこれに限らない)ファイルディスクリプタ伝送メカニズムを使用して前記LBMによって設定された接続を介してなされ得る。他の実施の形態において、前記LBMと前記インスタンスとの間の接続は、例えば、共有メモリを介してなされ得る。SIPおよびH.323のような(しかしこれに限らない)異なるインスタンスと前記LBMとの内部接続は、例えば、パワーオン時に確立可能である。

典型的なLBMは、関連ポートにリスンするようリクエストすることができる。これに応じて、OSによってリスニングソケットが定義される。ポート1720のような前記関連ポートを介して新たなTCP接続のリクエストが受信されると、前記オペレーティングシステムは、該リクエストをH.323LBMに送る。このようにして前記H.323LBMのみが前記H.323接続リクエストを受信する。前記新たなTCP接続を受け付けるために、前記ODによってランダムに選択されたソケット番号が選択され、新たに受信されたTCP接続と対応付けられる。次に、前記H.323LBMは、前記コールを処理するために利用可能なH.323インスタンス(タスク)を探す。

各H.323インスタンス毎のアクティブコールカウンタは、前記H.323LBMがどの各H.323インスタンスに前記コールを伝送すべきかを判定するのを補助する。前記アクティブコールカウンタは、特定のH.323インスタンスが処理しているアクティブコールの量をカウントするカウンタであってよい。前記アクティブコールカウンタは、アクティブコールが終了させられる毎または新たなコールが前記特定のインスタンスについて受信される毎に更新される。前記H.323LBMは、例えば、最小のアクティブコールカウンタ値を有するH.323インスタンスに従って前記新たな接続リクエストを送信するよう決定してよい。ある実施の形態において、アプリケーションのいずれのインスタンス(タスク)も利用可能でない場合、前記LBMは1つのインスタンスを作成することができる。

前記H.323LBMは、Unix (登録商標) Domain Socketのような(しかしこれに限られない)ディスクリプタシェアリングメカニズムを使用して当該ソケット番号を送ることができ、該ソケット番号のヘッダはソケットが伝送されることを示し、前記選択されたインスタンスは、データを受信および送信するための同一のIPを介して、コールを処理するための新たなソケット番号を受信する。プラグインシリコンオペレーティングシステム(pSOS)が使用される他の実施の形態によると、シェアリングソケットシステムコール、すなわち、“shr_socket”がシェアリングソケットシステムとして使用可能である。さらに、2つ以上のアプリケーションによって同一のディスクリプタ(記述子)を共有するために他の方法が使用可能である。

ここに開示された発明の特徴は、添付図面および詳細な説明を参照して明白であろう。上記の発明の概要は、本発明のすべての潜在的な実施の形態はすべての特徴の概要を述べているのではなく、以下の実施の形態例の詳細な説明、図面および特許請求の範囲を読むことによって、他の特徴および利点が明白になるであろう。

さらに、本発明の概念を問う業者に説明するために特定の実施の形態が記述されているが、これらの実施の形態については様々な変更が可能である。従って、ここに示した図面および明細書は本発明の概念を限定するものではない。

本発明の実施の形態を以下の図面に基づいて説明する。

多地点接続制御装置(MCU)の一例の一部を示す簡略ブロック図。

TCPを介したH.323コール設定処理のフロー例を示すタイムチャート図。 TCPを介したH.323コール設定処理のフロー例を示すタイムチャート図。

TCPを介したH.323コール設定処理の方法例を示すタイムチャート図。 TCPを介したH.323コール設定処理の方法例を示すタイムチャート図。

UDPトランスポートプロトコルコール設定処理に基づくSIPコール処理のフロー例を示すタイムチャート図。

UDPトランスポートプロトコルコールに基づくSIPコール設定処理の方法例を示すフローチャート図。 UDPトランスポートプロトコルコールに基づくSIPコール設定処理の方法例を示すフローチャート図。

図面において、同じ参照数字は同じ要素を示し、以下に、本発明の方法、システムおよび装置の実施の形態例、特徴を説明する。便宜的に、同一グループのいくつかの要素のみについて参照数字が付されている。図面の目的は、実施の形態を例示するものであって、本発明の範囲を制限するものではない。タイミング図における様々異なるイベント間のタイミング間隔は、必ずしも原寸に比例していない。

図1は、多地点接続制御装置(MCU)100の一例の一部を示す簡略ブロック図である。前記MCU100の前記一部は、H.323またはSIP(Session Initiation Protocol: セッション初期化プロトコル)に基づいて制御およびシグナル送信を扱うMCUの関連要素からなる。例えば媒体(オーディオ、ビデオ、データ)処理部のような、共通MCUの他の部分については説明しない。その他の要素として、MCU100は、さらに、1または複数のプラグ110、1または複数のネットワークインターフェースカード115、および、オペレーティングシステム120を含んでいてよい。また、そのアプリケーションレイヤとして、MCU100は、H.323ロードバランサモジュール(LBM)130と、複数のH.323インスタンス140a-cと、SIPロードバランサモジュール(LBM)150と、複数のSIPインスタンス160a-cとを含んでいてよい。なお、当業者に理解されるように、システムの構成および必要性に応じて、各MCUは、各プロトコル毎に3つ以外の数のインスタンスを有することができる。しかしながら、理解を容易にするために、各プロトコル毎に3つのインスタンスが示されている。

MCU100は、IPネットワークで動作するネットワーク装置/アプリケーションサーバであってよい。MCU100は、本発明の教示内容を実施できる多くの異なるネットワーク装置/アプリケーションのうちの1つにすぎない。

プラグ110は、MCU100を、適当なリンクを介して、例えばイーサネット(Ethernet)(登録商標)に基づくLAN(Local Area Network)に接続する。ネットワークインターフェースカード115は、通信情報のOSI(開放型システム間相互接続)の物理レイヤおよび通信のデータリンクレイヤを処理する。オペレーティングシステム(OS)120は、様々ある機能のうち、特に、適当なプロトコル、IPプロトコル、TCP(通信制御プロトコル)、UDP(ユーザデータグラムプロトコル)等に従って通信情報のネットワークレイヤおよびトランスポートレイヤを処理する。

OS120は、ネットワークモジュール121と、TCPトランスポートモジュール122aとUDPトランスポートモジュール122bとを含んでいてよい。ネットワークモジュール121は、様々あるオブシェクトのうち、特に、IPネットワークスタックを含んでいてよい。ネットワークモジュール121は、NIC115から通信情報を受信し、OSIのネットワークレイヤを処理する。ネットワークモジュール121は、パケットのIPヘッダを解析する。前記IPヘッダは、とりわけ、指定IPアドレス、指定ポート番号、ソースIPアドレス、ソースポート番号、および、トランスポートプロトコルの種類を含んでいてよい。OS120は、上記4つのパラメータ、すなわち、指定IPアドレス、指定ポート番号、ソースIPアドレスおよびソースポート番号に従って、受信した通信情報についてのソケット番号127a-cおよび/または129をランダムに定義する。ネットワークモジュール121は、前記ヘッダに記録されているプロトコル(例えば、TCPまたはUDP)に従って、前記情報をTCPトランスポートモジュール122aまたはUDPトランスポートモジュール122bに伝送することができる。ポート1720を介して、H.323コールリクエストのTCP通信が伝送される。ポート5060を介して、SIPセッションの暗号化されていないTCP通信情報が伝送される。ポート5061を介して、SIPセッションの暗号化されたTLS通信情報が伝送される。SIPセッションで使用されるトランスポートプロトコルは、変更可能であり、アドミニストレータによって定期的に設定可能である。場合によっては、UDPのみがポート5060と共に使用される。他の場合において、TLSの暗号化されたセッションについて、TCPがポート番号5060と共に使用され、または、ポート5061と共に使用される。他の実施の形態においては、上記3つのオプションのすべてが使用されてよい。

TCPトランスポートモジュール122aは、OSIのトランスポートレイヤレベルを処理し、多くあるオブジェクトのうち、特に、TCPトランスポートスタックを備えていてよい。TCPトランスポートモジュール122aは、ポート1720、5060および5061からの通信情報を処理する。TCPトランスポートモジュール122aは、例えば、そこからデータを受け取ったリスニングポートおよび使用されるトランスポートプロトコルに従って、通信リクエストをH.323リスニングソケット126またはSIPリスニングソケット128a、128bまたは128cに伝送できる。

UDPトランスポートモジュール122bは、OSIのトランスポートレイヤレベルを処理し、多くある要素のうち、特に、UDPトランスポートスタックを備えていてよい。UDPトランスポートモジュール122bは、ポート5060からの通信情報を処理し、通信リクエストをリスニングソケット128cに伝送できる。OS120の作用については後述する。

前記MCU100のアプリケーションレイヤは、2つのロードバランサモジュールH.323 LBM130およびSIP LBM150を備えていてよい。各前記ロードバランサは、H.323インスタンス140a-cまたはSIPインスタンス160a-cと通信するためのAPI(アプリケーションプログラミングインターフェース)138または158を含む。APIコマンドの例としては、追加、削除、消去などがある。各前記LBMは、開始時に、OS120に対してリスニングソケットを要求することができる。H.323 LBM130は、ポート1720を介した通信のために、リスニングソケット126に関連付けられてよい。SIP LBM150は、3つのリスニングソケット128a-c、すなわち、ポート5061を介して受信した暗号化されたTLS/TCP通信情報についてはリスニングソケット128a、ポート5060を介して受信した暗号化されていないTCP通信情報についてはリスニングソケット128b、および、ポート5060を介して受信した暗号化されていないUDP通信情報についてはリスニングソケット128cに関連付けられてよい。SIPプロキシと前記MCU100との間のトランスポートプロトコルは、アドミニストレータによって設定されてよい。前記SIPプロキシと前記MCU100との間の接続に2つ以上のトランスポートプロトコルが使用可能な場合もある。

その他の例においては、3つのLBM、すなわち、H.323のためのLBM、暗号化されていないSIPのためのLBM、および、TLSプロトコルに基づく暗号化されたSIPのためのLBMが使用可能である。更なる代案として、1つのLBMが、3種類の通信情報(すなわち、ポート5060を介して受信されたTCP通信情報、ポート5060を介して受信された暗号化されていないUDPおよびTCP通信情報、ならびに、ポート5061を介して受信されたTLS/TCPに基づく暗号化された通信情報)を処理することができる。

各SIPコールは、コールID(CID)と対応付けられる。コールID(CID)は、特定のSIPクライアントとの特定のSIPコールを示す。故に、SIP LBM150は、受信した通信情報を部分的に解析してCIDを求め、該CIDをクライアントとの通信情報を処理する適当なSIPインスタンス160a-cに送るパーサー152を含んでいてよい。また、SIP LBM150は、ポート5061を介してTCPトランスポートモジュール122aから受信されたTLS通信情報を解読して前記通信情報の解析およびCIDの特定を可能にするディクリプタおよびTLSスタック154を含んでいてよい。

複数のソケット127a-cおよび／または129aa-ccは、異なるH.323インスタンス140a-cまたはSIPインスタンス160a-cとH.323クライアントまたはSIPクライアントとの通信を可能にするよう作成され、終了させられる。上述の如く、OS120は、上記4つのパラメータ、すなわち、指定IPアドレス、指定ポート番号、ソースIPアドレスおよびソースポート番号に従って、受信した情報についてのソケット番号127a-cおよび/または129 aa-ccをランダムに定義する。SIPインスタンスのめたに使用されるソケット番号129aa-ccは、リスニングソケット128a-cおよびインスタンス160a-cを示す。1番目の文字はリスニングソケット128a-cを示し、2番目の文字はインスタンス160a-cを示す。従って、例えば、ソケット129bcは、リスニングソケット128bおよびSIPインスタンス160cを示す。従って、SIPインスタンス160a-cによって使用されるソケットの数は、(トランスポートプロトコルおよびポートの関数としての)リスニングソケットの数とSIPインスタンスの数との積であるような構成がある。図1に示した例において、ソケットの数は9個である。

更に、他の実施の形態において、トランスポートプロトコルの他の組合せが前記MCU100とSIPプロクシとの間で使用可能である。ある実施の形態では、例えば、TLS/TCPのみを使用することができる。このような実施の形態においては、MCU100は、例えば、1つのトランスポートプロトコルモジュールと、TCPトランスポートモジュール122aと、1つのリスニングソケット128aと、3つのインスタンスのソケット129aa、129abおよび129acを備えていてよい。

前記MCU100のアプリケーションレイヤにおいて、2つのソケットテーブルがソケット番号で更新される。H.323ソケットテーブルはH.323通信情報と対応付けられ、SIPコールID(CID)テーブル153はSIP通信情報と対応付けられる。H.323ソケットテーブル135はH.323 LBM130によって管理される。SIPコールID(CID)テーブル153はSIP LBM150によって管理される。前記H.323ソケットテーブル135における各エントリ(記録データ)は、エントリID、ソケット番号127a-c、および、H.323セッションを処理するために割り当てられたH.323インスタンス140a-c等の(しかし、これらに限定されない)前記H.323セッションに関連した情報を含む。前記SIPID(CID)テーブル153における各エントリは、該SIPセッションのCID、該セッションを処理するために割り当てられたSIPインスタンス160a-c、および、そこから該コールが受け取られたリスニングソケット128a-c等の(しかし、これらに限定されない)前記SIPセッションに関連した情報を含む。これらのテーブルは、適当なLBMによって管理され、コールを適当なインスタンスに送るために、関連したLBMによって使用される。

各LBM、H.323 LBM130およびSIP LBM150は、複数のアクティブコールカウンタを含んでいてよい。H.323 LBM130は、各H.323インスタンス140a-c毎にアクティブコールカウンタを含んでいてよい。前記アクティブコールカウンタは、特定のH.323インスタンス140a-cについての各新たな着信毎に1だけインクリメントされ、特定のH.323インスタンス140a-cで終了する各アクティブコール毎に1だけデクリメントされる。SIP LBM150は各SIPインスタンス毎にアクティブコールカウンタを含んでいてよく、該アクティブコールカウンタは、SIPインスタンス160a-cについてのH.323アクティブコールカウンタと同様に動作する。各前記アクティブコールカウンタの値に従って、前記インスタンスにおける通信負荷が平衡させられることができる。

典型的なH.323インスタンス140a-cは、関連インスタンスと対応付けられた複数の会議出席者とのH.323シグナリングおよび制御通信を処理するためのH.323スタックを備えていてよい。さらに、各H.323インスタンス140a-cは、H.323 LBM130と通信するためのAPIモジュール142を含んでいてよい。典型的なSIPインスタンス160a-cは、SIPスタックおよびAPIモジュール162を含んでいてよい。前記SIPスタックは、当該インスタンスと対応付けられた複数の出席者とのSIPシグナリングおよび制御通信を処理する。前記APIモジュール162は、SIP LBM150と通信することができる。TLS/TCPに基づいて通信情報が暗号化されるSIPインスタンス160a-cの一実施の形態においては、該SIPインスタンス160a-cは、TLSエンクリプタモジュールを含んでいてよい。該TLSエンクリプタは、該当する出席者に向けて送信する前のSIP信号および制御データを暗号化するために使用され得る。

図2aおよび図2bは、TCPを介したH.323コール処理の典型的なフローにおける関連イベントを示すタイムチャートである。説明上の便宜および明確さのために、いくつかのイベントを含む1つのコールのみが示されている。しかしながら、当業者に理解されるように、複数のイベントを含む複数のコールも同様に処理可能である。T0からT0cまでの開始時において、H.323 LBM130(図1)は、Unixドメインソケット(UDS)を介して、H.323インスタンス140a-cの各々との接続を確立する。新たな接続は、各インスタンスにおいてAPIモジュール138とAPIモジュール142(図1)との間で伝送されるAPIコマンドを伝える。他の実施の形態は、例えば、pSOSにおけるシェアソケットメカニズムのような(しかしこれに限らない)アプリケーション間で他の通信法を使用してもよい。

T1において、H.323 LBM130は、OS120(図1)に対して、ポート1720を介して受信されたリクエストをTCP接続でリスンするようリクエストする。これに応じて、T2において、前記OS120(図1)は、ポート1720におけるリスニングソケットとして機能するよう、ソケット番号126(図1)をH.323 LBM130に送る。その後、ポート1720において、新たなTCP接続を確立するようリクエストしているクライアントからのTCP SYNを受信するT10。そして、前記OS120は、T11においてTCP SYN ACK(Acknowledge)を送ることによって応答する。前記TCP SYN ACKが受信されたならば、前記クライアントは、T12において、H.323通信セッションを確立する指示リクエストとしてTCP ACKを送る。

次に、T13では、OS120は、リスニングソケット126を介して、前記クライアントとのH.323接続を設定するためのリクエストをH.323 LBM130に送る。これに応じて、H.323 LBM130は、T14において、H.323接続受諾を送る。OS120は、T15において、例えば、新たなソケット127aと共にaccepted(受諾)を返し、これにより、セッションが処理される。前記新たなソケット127aを受け取ると、前記LBMは、どのH.323インスタンス140a-cが前記コールを処理するのかを決定することができる。このインスタンス選択は、各インスタンスに対応付けられた前記アクティブコールカウンタの値に基づいて行われ得る。該インスタンスの選択がなされた後、前記H.323ソケットテーブルが、例えば、前記新たなソケット127aおよび前記選択されたインスタンス140aの識別情報で更新される。

T16において、H.323 LBM130は、ソケット127aを介して受け取られる、前記新たなセッションに“ADD(付加)”せよというAPIコマンドを前記選択されたH.323インスタンス140aに送る。このADDコマンドはUnix Domain Socketを介して伝送され、ここでのヘッダは、ソケットが伝送され、ペイロードとしてソケット番号127aが伝送されることを示す。これに応じて、ランダムに選択可能な第2のソケット番号127a'が、前記選択されたインスタンス140a(図1)に送られる。各番号127a,127a'は、同じファイルディスクリプタ(ファイル記述子)にアクセスするために、互いに異なるアプリケーション(H.323 LBM130および選択されたインスタンス140a)によってそれぞれ使用されることができる。その結果、前記選択されたインスタンスが前記セッションを実行することができるセッション127a'に新たなソケット番号が割り当てられる。従って、前記セッションについて1対のソケットが作成される(127a; 127a')。127aは前記H.323 LBMによって使用され、127a'は前記選択されたインスタンスによって使用される。クライアントとの前記H.323セッションの残部は、ソケット番号127a'を使用して前記選択されたH.323インスタンス140aによって行われる。同様に、ソケット127b, 127b'がH.323インスタンス140bによって処理されるセッションに割り当てられ、ソケット127c, 127c'がH.323インスタンス140cによって処理されるセッションに割り当てられることができる。

T18において、前記H.323クライアントは、H.323セッションを確立するために、H.323コール設定情報を含んでいてよいH.323データを送る。該H.323データは、T19において、ソケット127a,127a'の両方で伝送される。しかしながら、例えば、前記選択されたH.323インスタンス、例えば140a、のみが、前記H.323データを読み取り、リクエストに応答する。

前記H.323セッションのタイムテーブルの続きである同じ図2bでは、T20において、例えば、前記選択されたインスタンス、例えば140a、が、ソケット番号127a'を使用してH.323データを送る。T21において、前記OS120は、前記H.323データを前記クライアントに向けて送る。T22において、前記クライアントはデータ(H.323パケット)を送る。前記OS120は、T23において、ソケット127a'を介してH.323データのパケットを前記選択されたインスタンス(140a)に送る。前記セッションは、該セッションの終わりまで、ソケット127a'を介して続行可能である。

前記セッションの終わりT30において、前記クライアントは、H.323セッションエンド指示を送る。該セッションエンド指示は、T32において、ソケット127a'を介して前記OS120(図1)から前記選択されたインスタンス140aに送られることができる。T34において、ソケット127a'を閉じるrelease call(コールリリース)指示がソケット127a'を介して送られる。T38において、T0で開設された接続を介して、UDSを使用して、APIコマンドDELETEが送信され、受信されると、H.323 LBM130は、ソケット127aを閉じよというコマンドをOS120に送る。その後、前記OS120は、T40において、TCP FINコマンドを使用して、TCP接続を閉じよというコマンドを前記クライアントに送る。なお、同様な処理は、他のソケットを使用する他のインスタンスを伴う他のH.323セッションについても同時に実行され得る。

図3aおよび図3bは、TCP接続でH.323コール設定を処理するための方法300の一例を示す図である。該方法300は、H.323 LBM130(図1)の一実施の形態によって実行され得る。該方法300は、MCU100(図1)のパワーオン時に開始される(ステップ302)ことができ、前記MCUがアクテイブ状態であるかぎり実行されることができる。開始されると(ステップ304)、H.323 LBM130は、関連モジュールに導入され、または、H.323 LBM130の動作に関与するモジュールを開始させることができる。該モジュールの例としては、H.323ソケットテーブル135、1組のH.323インスタンス140a-c(図1)、各H.323インスタンス140a-c毎に1つの設けられる1組のアクティブコールカウンタ、等である。

開始処理(ステップ302および304)の後、H.323 LBM130と各H.323インスタンス140a-cとの間で内部接続が確立される(ステップ305)。この内部接続は、例えばUnix Domain Socketのような(しかしこれに限られない)ファイルディスクリプタ伝送および/またはファイルディスクリプタシェアリングメカニズムに基づくものであってよい。

この時点で、H.323 LBM130は、OS120(図1)に対してTCPポート1720でリスンするようリクエストすることができる(ステップ306)。リスニングソケット番号が受信されない場合、エラーメッセージが前記OS120に送られて(ステップ316)、前記方法300が終了されてよい(ステップ318)。

リスニングソケット番号が受信されると(ステップ310)と、前記方法300は、H.323通信セッションを処理するためにステップ320とステップ342(図3b)との間のループを開始する。ステップ320および322において、前記方法300は、イベント受信を待つ。イベントは、前記OS120(図1)または前記H.323インスタンス140a-c(図1)のうちの1つから受信され得る。ステップ322で受信したイベントが、インスタンス140a-cのうちの1つから、ステップ305で設定された接続のうちの1つを介して受信されたDELETE APIコマンドである場合、前記H.323ソケットテーブルから関連するエントリが読み出されて解析される。前記関連するエントリは、前記DELETEコマンドと対応付けられていてよいエントリID番号に基づいて読み出される。前記エントリのコンテンツに従って、関連セッションを処理するためのLBMに割り当てられたソケットを閉じるためのリクエストが発せられる(ステップ323)。関連インスタンスに割り当てられたアクティブコールカウンタが1だけデクリメントされ、前記H.323ソケットテーブル135における前記関連するエントリがリリースされる。前記ソケット閉じるためのリクエストに応じて、前記OS120は、前記TCP接続を閉じるためにTCP FINを該当クライアントに送る。

ステップ322において前記リスニングソケット126(図1)を介して新たなH.323接続リクエストを示すイベントが受信された場合、前記LBM130は前記リスニングソケット126を介して受信した前記新たなコールを受諾する。これに応じて、新たなH.323セッションを伝えるために新たなソケット番号が受信され(ステップ326)、前記方法300は、図3bに示されているステップに進む(ステップ330)。前記新たなソケットは、ソケット127a-c(図1)のうちの1つ、例えばソケット127aであってよい。

ステップ332(図3b)において、前記方法300は、どのH.323インスタンス140a-cが前記コール処理のために利用可能であるかを判定する。この判定は、例えば、前記インスタンスの各々のアクティブコールカウンタをチェックし、セッション数が一番すくないインスタンスを選択することに基づいて行われる。利用可能なH.323インスタンスがステップ334において見つかったならば、そのアクティブコールカウンタがインクリメントされる。ステップ340において、前記H.323ソケットテーブル135(図1)におけるエントリが前記セッションに割り当てられ、該エントリが、エントリID、前記割り当てられたソケット(例えば127a)および前記選択されたインスタンス(例えば140a)で更新される。その後、API ADDコマンドが、Unixドメインソケット接続を介しておよび前記選択されたインスタンスに送られる。前記Unixドメインソケットのヘッダは、それがソケット伝送メッセージであることを示すことができる。前記メッセージのコンテンツは、前記新たなソケット番号127aおよびエントリID番号を含んでいてよい。これに応じて、前記選択されたインスタンス140aは、例えば、当該セッションに使用するための他のソケット番号127a'を得ることになる。この時点342において、前記方法300は、ステップ320(図3a)に戻って、次のイベントを待つ。

ステップ334において利用可能なH.323インスタンスが無い場合、前記LBM130は、ステップ336において、新たなインスタンス140d(図示せず)を作成し、上記ステップ305と同様に該新たなインスタンス140dとの内部接続を設定し、ステップ340に進む。他の実施の形態では、利用可能なH.323インスタンスが見つからなかった場合、前記コールは拒絶されるようになっていてもよい。

図4は、SIPコール処理におけるイベントのフローの一例を示すタイムチャートである。図4の例において、前記SIPコールは、UDPトランスポートプロトコルに基づいており、UDPポート5060を介して受信される。説明上の便宜および明確さのために、UDPポート5060を介したいくつかのイベントを含む1つのコールが示されている。しかしながら、当業者に理解されるように、複数のイベントを含む複数のコールも同様に処理可能である。さらに、図4は、複数のクライアントがSIPプロキシを介して前記MCU100(図1)に接続されている一実施の形態におけるイベントのフローを示している。他の実施の形態において、2つ以上のSIPプロキシが使用されてよく、また、クライアントが直接に前記MCUに接続されていてもよい。これらの場合において、前記タイムチャートは、前記接続の種類に応じて変更されてよい。

図4に図示されたフロー図のはじめのT100a〜T100cにおいて、SIP LBM150(図1)は、SIPインスタンス160a-cの各々との接続を確立する。この接続は、例えばUnix Domain Socket(UDS)のような(しかしこれに限られない)ファイルディスクリプタ伝送メカニズムによってなされてよい。前記SIPインスタンス160a-cの各々との接続を設定した後、SIP LBM150は、T102において、OS120(図1)に対してUDPポート5060を介してSIPトランスポートソケットを開くようリクエストする。これに応じて、T103において、前記OS120(図1)は、入ってくる(インバウンド)SIPデータについてUDPポート5060におけるSIPトランスポートソケットとして機能するようようソケット番号128c(図1)をSIP LBM150に送る。

T104a〜T104cにおいて、前記ソケット番号128cは、前のT100a〜T100cで確立されたUnixドメインソケット接続を介して、SIPインスタンス160a-cの各々に送られる。前記Unixドメインソケットメッセージのヘッダは、それがソケット伝送メッセージであることを示すことができる。前記メッセージのコンテンツは、例えば、SIPトランスポートソケット番号128cを含んでいてよい。従って、前記SIPインスタンス160a-cの各々は、各SIPインスタンスがUDPポート5060およびSIPプロキシを介してSIPデータを関連クライアントに送るためのSTSとして使用するための他の番号129aa-ccを受け取る。

T110において、SIPクライアントは、UDPポート番号5060に向けてSIPデータまたはSIP inviteリクエストを含むSIPパケットを送ることができる。前記SIPデータは、当該SIPコールを開始したクライアントによって割り当てられたCall-ID(CID)と対応付けられる。T111において、前記プロキシは、SIPパケットをMCU100(図1)に送る。前記OS120(図1)は、IPヘッダおよびUDPヘッダを処理した後、T112において、SIPトランスポートソケット128cを介して前記SIPデータをSIP LBM150に送る。該SIP LBM150は、パーサ152(図1)によって前記SIPデータを解析し、該データが新たなSIPセッションの招来リクエストであるのか、または、既存のSIPセッションのSIPデータであるのかを判定する。前記データがセッションのCIDに基づいて既存のSIPセッションであると判定された場合、SIP CIDテーブル153(図1)におけるエントリーがサーチされる。該エントリは、前記セッションを処理するために割り当てられたSIPインスタンス160a-c、例えばインスタンス160aを特定するために解析される。その後、T113において、前記SIPデータは、例えば、T100a時に確立された接続を介してUnix Domain Socketメッセージとして伝送される。

前記SIPデータがSIP招来リクエストを含む場合、SIP LBM150は、どのインスタンス(例えば160a)が利用可能であるかを判定できる。そして、SIPコールCIDテーブル153においてエントリが前記セッションに割り当てられ、前記選択されたインスタンスおよび前記セッションのCIDが前記エントリに記憶される。前記選択されたSIPインスタンスに関連付けられたアクティブコールカウンタが1だけインクリメントされる。T113において、前記SIP招来リクエストは、例えば、前記選択されたインスタンス160aについてT100a時に確立された接続を介してUnix Domain Socketメッセージとして伝送される。

前記選択されたSIPインスタンス160aは前記SIPデータを更に処理してよく、T114において、SIP応答が、適当なSIPインスタンス(例えば160a)によってソケット129ca(“c”はそれがSIPトランスポートソケット128cを介して受信されたUDPセッションであることを示し、“a”はSIPインスタンス160aを示す)を介して、例えば、OS120を介して前記クライアントに送られる。T116において、適当なUDPおよびIPヘッダを付加した後、パケットが、前記プロキシに送られ、T118において、該プロキシから前記クライアントに送られる。前記選択されたインスタンス160aが前記受信されたSIPデータが当該コールを終了するリクエストであると判定し、または、前記SIPインスタンスが前記SIPセッションを終了すると決めるまで、前記セッションは上記と同様に進行する。その後、T120において、前記選択されたSIPインスタンス160aは、該セッションのCIDと共にAPI DELETEコマンドをSIP LBM150に送る。該コマンドは、例えば、前記選択されたインスタンス160aについてT100a時に確立された接続を介してUnix Domain Socketメッセージとして伝送される。終了させられたコールのCIDと共にDELETEコマンドを受け取ると、SIP CIDテーブル153において関連したエントリがサーチされ、リリースされる。前記選択されたSIPインスタンス160aに関連付けられたアクティブコールカウンタが1だけインクリメントされる。プロキシが関与するので、該プロキシとの接続は、1つのコールの終了によって影響されない。該プロキシとの接続は、他のクライアントのために動作するようアクテイブ状態に維持される。

TCPによって通信されるSIPセッションについても同様なフロー図が示されてよい。TCPに基づくSIPセッションでは、TCPトランスポートモジュール122aがUDPトランスポートモジュール122b(図1)に取って代わり、SIPトランスポートソケット128bがSIPトランスポートソケット128cに取って代わり、ソケット129baがソケット129caに取って代わることになる。TCPおよびTLSに基づくSIPセッションでは、TCPトランスポートモジュール122aがUDPトランスポートモジュール122b(図1)に取って代わり、SIPトランスポートソケット128aがSIPトランスポートソケット128cに取って代わり、ソケット129aaがソケット129caに取って代わることになる。さらに、T113において、SIPデータを解析する前に、該SIPデータを解読するための解読処理が追加される。

TCP/IP(ポート5060)またはTLS/TCP/IP(ポート5061)を介して行われるSIPセッションを処理する一実施の形態は、先ず、MCUとSIPプロキシとの間のTCP接続を確立する必要がある。このような一実施の形態において、ポート5060または5061を介してTCP接続によってSIPデータを伝えるためにSIPトランスポートソケットを開くために、先ず、前記MCUとSIPプロキシとの間のTCP接続を確立するために、SIP LBM150とポート5060または5061との間でリスニングソケットを開くことができる。前記TCP接続を確立した後に、SIPトランスポートソケット128aおよび128bが前記SIPデータの処理のために割り当てられてよく、SIP LBM150に伝送される。前記MCUとSIPプロキシとの間のTCP接続を開き、前記SIPトランスポートソケットを割り当てるための典型的な処理は、図2aの(前記TCP接続を設定するための)T1からT14および(前記SIPトランスポートソケットを割り当てるための)T15に開示されたものと同様であってよい。TCPに基づくSIPセッションにおいて、前記TCP接続は、前記MCUがアクティブである間、オープン状態に維持され得る。

図5は、3つの考えられるトランスポートプロトコルオプション、すなわち、TCP接続およびポート5060、UDPおよびポート5060、または暗号化されたTLSセッションについてポート5061介したTCP、によってSIPコールを同時に処理する方法500の一例を示す。該方法500は、SIP LBM150の一実施の形態(図1)によって実施可能である。他の実施の形態は、一種類のSIPセッション(UDP、TCPまたはTLS/TCP)を処理するよう構成されてよい。更に他の実施の形態は、二種類のSIPセッションを処理するよう構成されてよい。これらの実施の形態において、方法500は、使用されるトランスポートプロトコルに整合するよう変更されてよい。

前記方法500は、MCU100(図1)のパワーオン時に開始される(ステップ502)ことができ、前記MCUがアクテイブ状態であるかぎり実行されることができる。開始されると(ステップ504)、SIP LBM150は、MCU100の関連モジュールに導入され、SIP LBM15の動作に関与するモジュールを開始させることができる。該モジュールの例としては、SIP CIDテーブル153、1組のSIPインスタンス160a-c(図1)、各SIPインスタンス160a-c毎に1つの設けられる1組のアクティブコールカウンタ、等である。

開始処理(ステップ502および504)の後、SIP LBM150と各SIPインスタンス160a-cとの間で内部接続が確立される(ステップ505)。この内部接続は、例えばUnix Domain Socketのような(しかしこれに限られない)ファイルディスクリプタ伝送および/またはファイルディスクリプタシェアリングメカニズムに基づくものであってよい。

ステップ506において前記SIPインスタンス160a-cの各々との接続を設定した後、SIP LBM150は、ステップ508において、設定に応じて、1または複数のポートにおけるSIPトランスポートソケットを開くようリクエストする。前記ポートは、TCPポート5060、UDPポート5060およびTCPポート5061であってよい。その後、前記SIP LBMは、ステップ510において、各トランスポート-プロトコルおよびポート対毎にSIPトランスポートソケット番号およびポートを受信するのを待つ。前記ソケット番号のうちの1つが受信されなかった場合、ステップ516において、エラーメッセージがOS120に送られ、前記方法500がステップ518において終了させられる。SIP通信情報を運ぶためにTCPトランスポートプロトコルを使用する実施の形態は、先ず、SIPソケットが伝送され得るTCP接続を確立した後のみにおいて、適当なポート(TLS/TCPのための5060または5061)においてリスニングソケットを開くことによって前記MCUと前記SIPプロキシ間におけるTCP接続を確立する必要がある。

ステップ510において、前記プロキシおよびMCUの構成設定に応じてSIPトランスポートソケットの適当な番号 (例えば、ポート5061におけるTLS/TCPのためのソケット128a、および／または、ポート5060におけるTCPのためのソケット128b、および／または、ポート5060におけるUDPのためのソケット128c)が受信されると、ステップ520において、各前記ソケット番号128a-cは、各前記SIPインスタンス160a-cに送られる。前記SIPインスタンスを各前記SIPインスタンスに送る処理は、ステップ506において各前記SIPインスタンスについて確立された接続を介して、Unixドメインソケットメッセージとして行われ得る。前記Unixドメインソケットメッセージのヘッダは、それがソケット伝送メッセージであることを示すことができる。前記メッセージのコンテンツは、前記伝送されるソケット番号128a、128bまたは128cを含んでいてよい。従って、各インスタンスにおいて受信されたソケット番号は、129a,a-cまたは129b,a-cまたは129c,a-cであり、ここで、1番目の文字はSIPトランスポートソケットを示し、2番目の文字はインスタンス番号を示す。故に、129c,a-cは、3つのソケット、すなわち、ソケット128cを介してインスタンス160aで受信されるセッションのために使用される129ca、ソケット128cを介してインスタンス160bに受信されるセッションのために使用される129cb、および、ソケット128cを介してインスタンス160cに受信されるセッションのために使用される129cc(図1)を示す。

1または複数のSIPトランスポートソケットをSIPインスタンスに送信した後、前記SIP LBM150は、前記インスタンスからその受信ソケット番号と共に応答を得ることができる。該応答は、ステップ506で確立された接続を介して、Unixドメインソケットメッセージとして送信される。前記SIP LBM150は、前記ソケット番号対をSIPソケットテーブルに格納する。典型的なSIPソケットテーブルは、例えば、ローが前記SIPトランスポートソケット128a-cに対応付けられ、コラムが前記SIPインスタンストランス160a-cに対応付けられるマトリックスを含んでいてよい。この例において、前記マトリックスにおける各セルは、前記適当なインスタンス160a-cによって使用されるソケット129aa-ccを含むことになる。

ステップ522および530において、前記方法500は、イベント受信を待つ。イベントは、前記OS120(図1)または前記SIPインスタンス160a-c(図1)のうちの1つから受信され得る。ステップ530において前記インスタンス160a-cのうちの1つからイベントが受信された場合、ステップ536において、それがDELETE APIコマンドであるか否かが判定される。ステップ506で設定された接続のうちの1つを介して受信されたDELETE APIコマンドであるとステップ536において判定された場合、前記DELETE APIコマンドは、該セッションのCIDを指示することができる。ステータス538において、該セッションのCIDに基づいて、前記SIP CIDテーブル153(図1)から関連エントリが読み出され、リリースされる。前記関連するSIPインスタンスに対応付けられたアクティブコールカウンタは1だけデクリメントされ、前記方法500はステップ522にリターンする。ステップ536において前記イベントがDELETE APIコマンドではない場合、前記方法500はステップ522にリターンして次のイベントを待つ。

ステップ530において前記イベントが前記SIPトランスポートソケットのうちの1つ128a-c(図1)を介して前記OS120(図1)から受信された場合、ステップ540において、前記セッションがTLSに基づくものか否かが判定される。この判定は前記SIPトランスポートソケットに基づいて行い得る。前記SIPメッセージがソケット128aを介して受信された場合、当該セッションは、TLSに基づく暗号化されたセッションである。故に、前記メッセージはTLS DEC154(図1)によって解読され、該解読されたメッセージは、ステップ544における更なる分析のためにパーサ152(図1)に送られる。ステップ540において前記SIPメッセージが前記TLSに基づいていない場合、前記メッセージは、ソケット128bまたは128cを介して受信されており、ステップ544における更なる分析のためにパーサ152(図1)に送られ、前記方法500は図5bのステップ552に進む。

図5bに戻り、ステップ552において、前記分析されたSIPメッセージがクライアントからのINVITEリクエストであるか否かを判定する。前記INVITEリクエストは、新たなSIPセッションを開始したいクライアントから送られ得る。ステップ552においてYESである場合、前記方法500は、ステップ554において、当該コールを処理するために利用可能なSIPインスタンス160a-c(図1)をサーチする。このインスタンス選択は、各インスタンスの前記アクティブコールカウンタの値に基づいて、最小のセッション数を有するもの160a-c(図1)を探すことによって行われ得る。ステップ560において利用可能なSIPインスタンス、例えば160a、が見つかった場合、ステップ564において、該新たなセッションに前記SIP CIDテーブル153(図1)におけるエントリが割り当てられる。前記エントリは、前記セッションのCID、前記選択されたインスタンス(例えば160a)、および、該選択されたSIPインスタンス(例えば160a)によって使用される関連ソケット129a-c,aで更新される。前記関連ソケットは、前記SIPソケットテーブルにおける前記セッションがそこから受信されたSIPトランスポートソケット128a-cと前記選択されたインスタンス(例えば160a)との交点にあるセルから読み出される。該インスタンスのアクティブコールカウンタが1だけインクリメントされ、受信されたSIPメッセージが、後述の如くステップ506(図5a)またはステップ562において確立された適当なUnixドメインソケット接続を介して、前記選択されたインスタンスに送信される。前記セッションのCIDは、前記分析されたSIPメッセージから読み出される。他の実施の形態では、Unixドメインソケットの代わりに他のファイルディクリプタシェアリング機構を使用してよい。この時点570において、前記方法500は図5aのステップ522に戻って次のイベントを待つ。

ステップ560において利用可能なSIPインスタンスが見つからなかった場合、前記方法500は、ステップ562において新たなインスタンスを作成する。前記SIP LBMと前記新たなSIPインスタンスとの間の接続は、ステップ506(図5a)について上述したものと同様な方法で確立可能である。前記新たなSIPインスタンスとの接続を設定した後、前記SIP LBM150は、ステップ520(図5a)について上述したように各SIPトランスポートソケット128a-cを前記新たなインスタンスに送る。さらに、前記SIP LBMは、前記インスタンスによって受信されたソケット番号を入手して格納し、ステップ520の説明と同様に前記前記SIPソケットテーブルを更新し、ステップ564に進む。

ステップ552では、前記SIPデータがINVITEリクエストである場合、解析されたCIDに対応付けられたエントリを見つけるために、ステップ556において前記SIP CIDがサーチされる。どのSIPインスタンスが前記セッションに対応付けられているのかを判定するために、前記エントリが読み出され、解析される。その後、前記SIPデータは、ステップ506で確立された接続を介してUnixドメインソケットメッセージとして送信され、前記500はステップ570から図5aのステップ522にリターンする。

上述した方法およびシステムは、例示的なものであって、本発明の範囲を限定するためのものではない。上述した実施の形態は、様々異なる特徴からなるが、これらの特徴のすべてがすべての実施の形態に必要とされるわけではない。前記実施の形態のうちのあるものは、前記特徴のうちの一部または組合せを使用している。上述した実施の形態の変更例および上述した実施の形態について説明された特徴の様々異なる組合せからなる実施の形態が、当業者に明白であろう。

この出願において、“ユニット”および“モジュール”という用語は互換的に使用されている。ユニットまたはモジュールと称される構成要素は、スタンドアローンユニットまたは特化されたモジュールであってよい。ユニットまたはモジュールは、容易に取り外し、他の同様なユニットまたはモジュールと容易に交換可能なモジュール的特徴を有するものであってよい。各ユニットまたはモジュールは、ソフトウエア、ハードウエアおよび／またはファームウエアのいちのいずれか1つまたはこれらの組合せであってよい。論理モジュールのソフトウエアは、読み書き可能ハードディスク、CDROM、フラッシュメモリ、ROM等のコンピュータによって読み取り可能な媒体上に実施されてよい。特定のタスクを実施するために、ソフトウエアプログラムが、必要に応じて適当なプロセッサにロードされてよい。

次の特許請求の範囲の範囲を逸脱することなく、上述した動作方法の詳細に様々な変更を加えることが可能である。例えば、上述した方法300および500は、上記とは異なる順序で様々なステップを実行してもよい。更に、ある実施の形態では、分離したステップとして説明された処理を組合せてよい。同様に、前記方法が実施される特定の動作環境に応じて、上述したステップの1または複数が使用略されてよい。さらに、図1から図5に示した処理は、プログラマブルな制御装置が1または複数のモジュールに統合された命令を実行することによって実行されてもよい。プログラマブルな制御装置は、単一のコンピュータプロセッサ、特殊目的プロセッサ(例えば、ディジタル信号プロセッサであるDSP)、通信リンクによって接続された複数のプロセッサまたはカスタム設計された状態マシーンであってよい。前記カスタム設計された状態マシーンは、例えば用途別集積回路(“ASIC”)またはフィールドプログラマブルゲートアレイ(“FPGA”)を含む集積回路のようなハードウエア装置として実施可能である。コンピュータによって読み取り可能な媒体と呼ばれることがある、プログラム命令を有形的に実施するのに適した記憶装置は、磁気ディスク(固定、フロッピー(登録商標)および着脱式のディスク)およびテープ、CD-ROMおよびディジタルビデオディスク(DVD)のような光媒体、ならびに、電気的にプログラマブルなリードオンリメモリ(“EPROM”)、電気的に消去可能なむプログラム可能なリードオンリメモリ(“EEPROM”)、プログラマブルなゲートアレイならびにフラッシュデバイス(しかし、これらに限られない)を含む。

当業者に理解されるように、本発明の範囲は、上記開示内容に限定されず、以下の特許請求の範囲によって定義される。

100 MCU
120 オペレーティングシステム
130 H.323 LBM
135 H.323ソケットテーブル
150 SIP LBM
153 SIPソケットテーブル
140a _ 140c H.323インスタンス
160a _ 160c SIPインスタンス

Claims

インターネットプロトコルネットワークを介した複数のマルチメディア会議をサポートする処理の複数のインスタンスをロードバランスさせる方法であって、
ホスト処理ユニットで、ロードバランシングモジュールをインスタンス化するステップと、
前記ホスト処理ユニットで、プロトコルスタックの複数のアプリケーションインスタンスを作成するステップと、
前記ロードバランシングモジュールを前記ホスト処理ユニットを制御するオペレーティングシステムのリスニングポートに接続するステップと、
前記複数のアプリケーションインスタンスの各々と前記ロードバランシングモジュールとの間で少なくとも1つのソケット記述子を送るステップと、
前記リスニングポートにおいて複数のマルチメディア会議に参加している複数の端末からインバウンドマルチメディアデータパケットを受け取るステップと、
前記プロトコルスタックの前記複数のアプリケーションインスタンスから選択されたアプリケーションインスタンスによって、前記複数の端末のうちのいずれかの端末から受け取られた各インバウンドマルチメディアデータパケットを処理するステップと、
処理されたデータを関連付けられた端末に送るステップと、
を具備し、
前記マルチメディアデータが、前記プロトコルスタックに応じた制御および信号伝達からなるグループから選択された少なくとも1つのデータタイプからなることを特徴とする方法。
前記ロードバランシングモジュールが、H.323プロトコルを使用してマルチメディア会議に適用される請求項1に記載の方法。
端末からのインバウンドマルチメディアデータパケットおよびアウトバウンドマルチメディアデータパケットが、マルチメディア会議の継続期間中前記端末に対応付けられた前記プロトコルスタックのうちの選択されたアプリケーションインスタンスによって直接に処理される請求項2に記載の方法。
前記ロードバランシングモジュールが、セッション開始プロトコル(SIP)メッセージに適用される請求項1に記載の方法。
前記ロードバランシングモジュールによってすべてのインバウンドマルチメディアデータパケットを受け取るステップと、
各受け取ったインバウンドマルチメディアデータパケットをチェックして、該インバウンドマルチメディアデータパケットが前記プロトコルスタックの既に選択されたアプリケーションインスタンスに関するものであるか否かを判定するステップと、
ファイル記述子伝送メカニズムを使用して、チェックされた前記マルチメディアデータを前記選択されたアプリケーションインスタンスに送るステップと、
を更に具備した請求項4に記載の方法。
前記ロードバランシングモジュールによってすべてのインバウンドマルチメディアデータパケットを受け取るステップと、
各受け取ったインバウンドマルチメディアデータパケットをチェックして、該インバウンドマルチメディアデータパケットが前記プロトコルスタックの既に選択されたアプリケーションインスタンスに関するものであるか否かを判定するステップと、
アプリケーションインスタンスが未だ選択されていない場合、前記プロトコルスタックのアプリケーションインスタンスを選択するステップと、
ファイル記述子伝送メカニズムを使用して、チェックされた前記マルチメディアデータを前記選択されたアプリケーションインスタンスに送るステップと、
を更に具備した請求項4に記載の方法。
1または複数のアプリケーションインスタンスのうちの各々と前記ロードバランシングモジュールとの間で送られる前記ソケット記述子が、Unixドメインソケットを介して送られる請求項1に記載の方法。
前記ファイル記述子伝送メカニズムが、Unixドメインソケットである請求項5または6に記載の方法。
SIPデータを運ぶために使用されるトランスポートプロトコルが、ユーザデータグラムプロトコル(UDP)である請求項4に記載の方法。
前記ホスト処理ユニットが多地点制御ユニットである請求項1に記載の方法。
プログラマブル処理ユニットと、
コンピュータで読み取り可能な媒体と、
前記プログラマブル処理ユニットを制御するために前記コンピュータで読み取り可能な媒体に記憶されたオペレーティングシステムと、
を具備し、
前記プログラマブル処理ユニットは、
前記プログラマブル処理ユニットで、ロードバランシングモジュールをインスタンス化し、
前記プログラマブル処理ユニットで、プロトコルスタックの複数のアプリケーションインスタンスを作成し、
前記ロードバランシングモジュールを前記オペレーティングシステムのリスニングポートに接続し、
前記複数のアプリケーションインスタンスの各々と前記ロードバランシングモジュールとの間で少なくとも1つのソケット記述子を送り、
前記リスニングポートにおいて複数のマルチメディア会議に参加している複数の端末からインバウンドマルチメディアデータパケットを受け取り、
前記プロトコルスタックの前記複数のアプリケーションインスタンスから選択されたアプリケーションインスタンスによって、前記複数の端末から受け取られた各インバウンドマルチメディアデータパケットを処理し、
処理された前記データを関連付けられた端末に送る
よう構成されており、
前記マルチメディアデータが、前記プロトコルスタックに応じた制御および信号伝達からなるグループから選択された少なくとも1つのデータタイプからなる
ことを特徴とするインターネットプロトコル(IP)ホスト。
前記ロードバランシングモジュールが、H.323プロトコルを使用してマルチメディア会議に適用される請求項11に記載のホスト。
端末からのインバウンドマルチメディアデータパケットおよびアウトバウンドマルチメディアデータパケットが、マルチメディア会議の継続期間中前記端末に対応付けられた前記プロトコルスタックのうちの選択されたアプリケーションインスタンスによって直接に処理される請求項12に記載のホスト。
前記ロードバランシングモジュールが、セッション開始プロトコル(SIP)メッセージに適用される請求項11に記載のホスト。
前記プログラマブル処理ユニットが、更に、
前記ロードバランシングモジュールによってインバウンドマルチメディアデータパケットを受け取り、
各受け取ったインバウンドマルチメディアデータパケットをチェックして、該インバウンドマルチメディアデータパケットが前記プロトコルスタックの既に選択されたアプリケーションインスタンスに関するものであるか否かを判定し、
ファイル記述子伝送メカニズムを使用して、チェックされた前記マルチメディアデータを前記選択されたアプリケーションインスタンスに送る
よう構成されている請求項14に記載のホスト。
前記プログラマブル処理ユニットが、更に、
前記ロードバランシングモジュールによってすべてのインバウンドマルチメディアデータパケットを受け取り、
各受け取ったインバウンドマルチメディアデータパケットをチェックして、該インバウンドマルチメディアデータパケットが前記プロトコルスタックの既に選択されたアプリケーションインスタンスに関するものであるか否かを判定し、
アプリケーションインスタンスが未だ選択されていない場合、前記プロトコルスタックのアプリケーションインスタンスを選択し、
ファイル記述子伝送メカニズムを使用して、チェックされた前記マルチメディアデータを前記選択されたアプリケーションインスタンスに送るステップ
よう構成されている請求項14に記載のホスト。
前記プログラマブル処理ユニットが、更に、各アプリケーションインスタンスと前記ロードバランシングモジュールとの間でソケット記述子を送るよう構成されている請求項11に記載のホスト。
前記ファイル記述子伝送メカニズムが、Unixドメインソケットである請求項15または16に記載のホスト。
SIPデータを運ぶために使用されるトランスポートプロトコルが、ユーザデータグラムプロトコル(UDP)である請求項14に記載のホスト。
前記プログラマブル処理ユニットが、多地点制御ユニットに組み込まれている請求項11に記載のホスト。
プログラマブルプロセッサ命令を記憶した、コンピュータによって読み取り可能な媒体であって、前記プログラマブルプロセッサ命令がプログラマブル処理ユニットに、
前記プログラマブル処理ユニットで、ロードバランシングモジュールをインスタンス化し、
前記プログラマブル処理ユニットで、プロトコルスタックの複数のアプリケーションインスタンスを作成し、
前記ロードバランシングモジュールを前プログラマブル処理ユニットを制御するオペレーティングシステムのリスニングポートに接続し、
前記複数のアプリケーションインスタンスの各々と前記ロードバランシングモジュールとの間で少なくとも1つのソケット記述子を送り、
前記リスニングポートにおいて複数のマルチメディア会議に参加している複数の端末からインバウンドマルチメディアデータパケットを受け取り、
前記プロトコルスタックの前記複数のアプリケーションインスタンスから選択されたアプリケーションインスタンスによって、前記複数の端末のうちのいずれかの端末から受け取られた各インバウンドマルチメディアデータパケットを処理し、
処理された前記データを関連付けられた端末に送る
ようにさせ、
前記マルチメディアデータが、前記プロトコルスタックに応じた制御および信号伝達からなるグループから選択された少なくとも1つのデータタイプからなる
ことを特徴とするコンピュータによって読み取り可能な媒体。
前記前記ロードバランシングモジュールが、H.323プロトコルを使用してマルチメディア会議に適用される請求項21に記載のコンピュータによって読み取り可能な媒体。
端末からのインバウンドマルチメディアデータパケットおよびアウトバウンドマルチメディアデータパケットが、マルチメディア会議の継続期間中前記端末に対応付けられた前記プロトコルスタックのうちの選択されたアプリケーションインスタンスによって直接に処理される請求項22に記載のコンピュータによって読み取り可能な媒体。
前記記憶した命令が、前記ロードバランシングモジュールがセッション開始プロトコル(SIP)メッセージに適用されるようにする請求項21に記載のコンピュータによって読み取り可能な媒体。
前記記憶した命令が、前記プログラマブル処理ユニットに、
前記ロードバランシングモジュールによってすべてのインバウンドマルチメディアデータパケットを受け取り、
各受け取ったインバウンドマルチメディアデータパケットをチェックして、該インバウンドマルチメディアデータパケットが前記プロトコルスタックの既に選択されたアプリケーションインスタンスに関するものであるか否かを判定し、
ファイル記述子伝送メカニズムを使用して、チェックされた前記マルチメディアデータを前記選択されたアプリケーションインスタンスに送る
ようにする請求項24に記載のコンピュータによって読み取り可能な媒体。
前記記憶した命令が、更に、前記プログラマブル処理ユニットに、
前記ロードバランシングモジュールによってすべてのインバウンドマルチメディアデータパケットを受け取り、
各受け取ったインバウンドマルチメディアデータパケットをチェックして、該インバウンドマルチメディアデータパケットが前記プロトコルスタックの既に選択されたアプリケーションインスタンスに関するものであるか否かを判定し、
アプリケーションインスタンスが未だ選択されていない場合、前記プロトコルスタックのアプリケーションインスタンスを選択し、
ファイル記述子伝送メカニズムを使用して、チェックされた前記マルチメディアデータを前記選択されたアプリケーションインスタンスに送るステップ
よう構成されている請求項24に記載のコンピュータによって読み取り可能な媒体。
前記記憶した命令が、更に、前記プログラマブル処理ユニットに、各アプリケーションインスタンスと前記ロードバランシングモジュールとの間でソケット記述子を送らせる請求項21に記載のコンピュータによって読み取り可能な媒体。
前記記憶した命令が、更に、前記プログラマブル処理ユニットに、ファイル記述子伝送メカニズムとしてUnixドメインソケットを使用させる請求項25または26に記載のコンピュータによって読み取り可能な媒体。
前記記憶した命令が、更に、前記プログラマブル処理ユニットに、前記SIPデータを運ぶためのトランスポートプロトコルとしてユーザデータグラムプロトコル(UDP)を使用させる請求項24に記載のコンピュータによって読み取り可能な媒体。
前記記憶した命令が、多地点制御ユニットに組み込まれた前記プログラマブル処理ユニットを制御する請求項21に記載のコンピュータによって読み取り可能な媒体。