JP2010220102A - 通信システム、サーバ装置、端末装置及びプログラム - Google Patents
通信システム、サーバ装置、端末装置及びプログラム Download PDFInfo
- Publication number
- JP2010220102A JP2010220102A JP2009066930A JP2009066930A JP2010220102A JP 2010220102 A JP2010220102 A JP 2010220102A JP 2009066930 A JP2009066930 A JP 2009066930A JP 2009066930 A JP2009066930 A JP 2009066930A JP 2010220102 A JP2010220102 A JP 2010220102A
- Authority
- JP
- Japan
- Prior art keywords
- priority
- terminal
- session establishment
- terminal device
- establishment request
- 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.)
- Granted
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】発側の端末からのトリガ情報の入力に基づいて、任意の相手の端末との優先通信を確実に確立させることのできる技術を提供する。
【解決手段】端末、及び端末からの要求を処理するサーバ２を有し、ネットワークを介して複数の端末間でデータを送受するＩＰ電話システムにおいて、端末３Ａは、優先通信の開始に係わるトリガ情報を検知した場合には、他の端末３Ｂとのセッション確立要求を示すＩＮＶＩＴＥに、優先通信であることを示す優先通信識別情報を設定する。優先通信識別情報を設定したＩＮＶＩＴＥについては、ネットワーク上で、端末３とサーバ２との間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して送信する。
【選択図】図５
【解決手段】端末、及び端末からの要求を処理するサーバ２を有し、ネットワークを介して複数の端末間でデータを送受するＩＰ電話システムにおいて、端末３Ａは、優先通信の開始に係わるトリガ情報を検知した場合には、他の端末３Ｂとのセッション確立要求を示すＩＮＶＩＴＥに、優先通信であることを示す優先通信識別情報を設定する。優先通信識別情報を設定したＩＮＶＩＴＥについては、ネットワーク上で、端末３とサーバ２との間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して送信する。
【選択図】図５
Description
本発明は、ＩＰ（Internet Protocol）ネットワークを利用して端末装置間でデータを高優先で送受する通信システム、サーバ装置、端末装置及びサーバ装置や端末装置において使用されるプログラムに関する。
ＩＰネットワークを用いて音声データを送受信する技術として、ＶｏＩＰ（Voice over Internet Protocol）がある。ＶｏＩＰは、例えば光通信ネットワーク上でギガビットイーサネットなどの技術を使用した場合最大１Ｇｂｐｓの帯域が提供される。
災害等により通常使用する光通信ネットワークが物理的に分断されるなどの障害が発生した場合には、代替のネットワークへと切り替えられる。代価ネットワークが無線ネットワークなどの低速ネットワークだった場合、利用できる帯域は、数十Ｍ〜数Ｍｂｐｓとなり、従前の数百分の一に縮退することとなる。代替のネットワークには、音声データのほか、画像データ等の大量のデータが流入することとなり、通話を確保することが難しくなる。
通信を確保するための公知技術については、制御系装置において、予め端末装置の通信の内容に応じて主情報の優先度合いを変化させ、優先転送を実現する技術が提供されている。具体的には、制御系装置（サーバ）において、主情報の優先度合いを示す優先シンボルを生成する。そして、転送系装置において、優先シンボルから主情報を制御するために必要な制御パラメータに翻訳して主情報に付与することにより、優先転送を行う技術について提供されている（例えば、特許文献１）。
上記の公知の技術では、制御系装置が保有するテーブルの内容によって、可能な優先通信のパターンが固定化されてしまうこととなる。すなわち、通信を行う者は、制御系装置が保有するテーブルに記載された端末装置との間で固定的に優先通信を確立することしかできない。
例えば、ＶｏＩＰを利用して固定の端末から固定の相手（固定の相手先端末装置）に優先通話をかけようとして電話をしても、かけた先が通話中であった場合に、制御系装置においては優先通話の設定がなされていない他の端末装置に電話をかけることがある。ネットワークの縮退時等において、このような電話をかけた場合には、優先通話をかけた場合のようには、十分に通話品質を確保することができない。
また、ネットワーク縮退時においては、ルータなどの中継装置は、優先度の低いパケットを破棄してしまう。そのため、制御系装置が高優先として固定の端末のＩＰアドレスを記憶していたとしても、該固定の端末から制御系装置へ至る途中のルータにおいて、該固定の端末からのＩＮＶＩＴＥパケットが破棄されてしまう可能性があり、そのような場合にはそもそも制御系装置に固定の端末からのＩＮＶＩＴＥパケットが到達できないので、当然ながら優先通話を開始することができない。
開示のプログラムは、発側の端末装置において優先通信を判定し、相手先の任意の端末装置との優先通信を確立させることのできる技術を提供することを目的とする。
開示の通信システムによれば、端末装置、及び該端末装置からの要求を処理するサーバ装置を有し、ネットワークを介して複数の端末装置間でデータを送受する通信システムであって、前記端末装置は、優先通信の開始に係わるトリガ情報を検知した場合には、他の端末装置とのセッション確立要求を示すパケットに、優先通信であることを示す優先通信識別情報を設定する設定手段と、前記設定手段により前記優先通信識別情報を設定されたセッション確立要求を示すパケットについては、前記ネットワーク上で、前記端末装置と前記サーバ装置との間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して送信する送信手段と、を備え、前記サーバ装置は、前記端末装置から前記セッション確立要求を受信すると、前記優先通信識別情報が該セッション確立要求に含まれるか否かを判定する判定手段と、前記判定手段において、前記優先通信識別情報が含まれると判定された前記セッション確立要求を示すパケットを、前記ネットワーク上で、前記サーバ装置と前記端末装置との間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して、該セッション確立要求に含まれる送信先である端末装置へ送出する送出手段と、前記判定手段において、前記優先通信識別情報が含まれると判定された前記セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための情報を記憶する記憶手段と、を備える。
端末装置において優先通信開始に係わるトリガ情報を検知すると、端末装置は、セッション確立要求に優先通信であることを示す優先通信識別情報を含め、優先通信識別情報の設定されているセッション確立要求を示すパケットについては、ネットワークの縮退時等の輻輳状態であっても破棄確率が低くなるような情報を付して（高優先で）送信する。サーバ装置は、セッション確立要求に優先通信であることを示す情報が含まれる場合には、セッション確立要求を高優先で着側の端末装置宛に高優先で送出する。これとともに、サーバ装置は、一連のセッションを他のセッションと識別するための情報を記憶しておく。以降にセッションを確立するために送受するパケットには、上記のセッションを他のセッションと識別するための情報を設定し、パケットに設定した上記の情報を用いて、優先通信に係わるパケットであることを認識して高優先で送出する。これにより、発側の端末装置に入力されたトリガ情報に基づき、相手の端末装置との優先通信をより確実に確立させることが可能となる。
開示のプログラムによれば、発側の端末装置において優先通信を判定し、相手先の任意の端末装置との優先通信をより確実に確立させることが可能となる。
以下、本発明を実施するための形態について、図面を参照して詳細に説明する。
図１は、本実施形態に係るＩＰ電話システムの概要を説明する図である。以下においては、ＩＰ通信システムの例としてＩＰ電話システムを挙げ、ＩＰ電話システムにおいて音声データを送受する場合について説明することとする。
図１は、本実施形態に係るＩＰ電話システムの概要を説明する図である。以下においては、ＩＰ通信システムの例としてＩＰ電話システムを挙げ、ＩＰ電話システムにおいて音声データを送受する場合について説明することとする。
図１に示すＩＰ電話システム１は、ＳＩＰ（Session Initiation Protocol）サーバ２及び複数のＶｏＩＰ端末３（図１においては、各ＶｏＩＰ端末３についてはＶｏＩＰ端末３Ａ、３Ｂ、３Ｃ、３Ｄと記載）を有する。ＶｏＩＰ端末３は、中継装置として例えばレイヤ３スイッチ（Ｌ３ＳＷ）４を介してＩＰネットワーク１０に接続し、ＳＩＰサーバ２を介してネゴシエーションを行う。他のＶｏＩＰ端末３と通信が確立されると、他のＶｏＩＰ端末３との通信を開始する。
本実施形態に係るＩＰ電話システム１においては、ＶｏＩＰ端末３の操作が、優先通話を許可された者（以下、優先通話者）による操作であることを認識して、優先通話確立のための処理を開始する。すなわち、優先通話者による発側のＶｏＩＰ端末３を介してのトリガ情報の入力を契機として、ＶｏＩＰ端末３やＳＩＰサーバ２のそれぞれが、ネゴシエーションに係わるパケットを高優先で送信あるいは転送し、優先通話を確立させる。
図１においては、優先通話者が、４台のＶｏＩＰ端末３Ａ〜３ＤのうちＶｏＩＰ端末３Ａを利用する場合を例示する。ＶｏＩＰ端末３Ａが、優先通話者による通話開始の操作を検知すると、ＩＰ電話システム１は、通話先として選択されたＶｏＩＰ端末３Ｃとの間の通話を確立するためのパケットを高優先で送受し、優先通話を確立させる。
このような方法によれば、例えば、優先通話者がまずＶｏＩＰ端末３Ｄに電話をかけたが、ＶｏＩＰ端末３ＤはＶｏＩＰ端末３Ｂと通話中であったため、代わりにＶｏＩＰ端末３Ｃに電話したような場合であっても、優先通話者は、ＶｏＩＰ端末３Ａから任意のＶｏＩＰ端末３Ｃに対して、動的に優先通話をかけることができる。
本実施形態に係るＩＰ電話システム１においては、ＶｏＩＰ端末３Ａが優先通話のためのトリガとなるトリガ情報が優先通話者により入力されたことを認識する。すなわち、通話者が優先通話者か、あるいは優先通話者でない一般の通話者であるかを識別する。優先通話のためのトリガ情報を受信したＶｏＩＰ端末３Ａは、ＳＩＰサーバ２を介して、相手先のＶｏＩＰ端末３との間で、最優先の通話回線を確立するためのネゴシエーションを実施する。以降は、通話が切断されるまで、最優先レベルのパケット送受信を行うことにより、回線品質を確保する。以下、本実施形態に係るＩＰ電話システム１に含まれるＶｏＩＰ端末３Ａ〜３ＤやＳＩＰサーバ２について、具体的に説明する。
図２は、ＶｏＩＰ端末３の機能ブロック図である。図２に示すＶｏＩＰ端末（以下端末と略記）３は、ＲＦＩＤ（Radio Frequency IDentification）受信部３１、オンフック／オフフック検知部３２、操作部３３、ディスプレイ表示部３４、優先パスワード管理データベース（優先ＰＷ管理ＤＢ）３５、ハンドセット部３６、音声コーデック部３７、制御処理部３８及びＬＡＮ（Local Area Network）インターフェース部３９を有する。
ＲＦＩＤ受信部３１は、ＲＦＩＤタグからトリガ情報１１を受信する。実施例では、優先通話者が保有するＲＦＩＤタグから、優先通話者を識別するための情報を受信する。
オンフック／オフフック検知部３２は、端末３のハンドセット部３６の状態がオンフック状態及びオフフック状態を検知する。
オンフック／オフフック検知部３２は、端末３のハンドセット部３６の状態がオンフック状態及びオフフック状態を検知する。
操作部３３は、端末３のユーザから入力されたトリガ情報１２や指示等を受け付ける。実施例では、優先通話者が入力したパスワードの入力を受け付ける。パスワードは、ＩＰ電話システム１において優先通話者ごとに設定される。ＶｏＩＰ端末３は、優先通話者がＲＦＩＤタグを保持していない場合等の緊急時に使用される正しいパスワードの入力をもって、優先通話者を識別する。
ディスプレイ表示部３４は、端末３の状態等を出力表示する。
優先ＰＷ管理ＤＢ３５は、操作部３３を介して入力されたパスワードが優先者用のＲＦＩＤタグの保有者であるか否かを判定するための情報を格納する。
優先ＰＷ管理ＤＢ３５は、操作部３３を介して入力されたパスワードが優先者用のＲＦＩＤタグの保有者であるか否かを判定するための情報を格納する。
ハンドセット部３６は、受話器や送話器等を含み、端末３のユーザにより入力された音声信号を受話器で受け付けるとともに、音声コーデック部３７から入力された音声信号を送話器に出力する。
音声コーデック部３７は、ハンドセット部３６から入力されたアナログ音声信号を、コード化されたデジタル音声信号に変換する。また、音声コーデック部３７は、通話先の端末３から受信したコード化されたデジタル音声信号を、アナログ音声信号に変換し、ハンドセット部３６（送話器）に与える。
制御処理部３８は、端末３の各機能部に対して指示を与え、各機能部の動作を制御する。本実施形態に係わる処理としては、優先通話者の操作により端末３に入力された優先通話の開始を意味するトリガ情報を認識し、セッション確立のために送信するパケットに、優先通話者による優先通話であることを示す優先通話識別情報を設定する。トリガ情報は、実施例では、ＲＦＩＤタグを識別する情報あるいはパスワードである。相手の端末３から受信したパケットに優先通話であることを示す優先通話識別情報が設定されている場合には、相手の端末３に返すパケットにも優先通話であることを示す情報を設定し、送信する。優先通話識別情報の具体的な設定方法については、後述する。
制御処理部３８で生成したパケットは、制御処理部３８の指示により、ＬＡＮインターフェース部３９において、ＩＰヘッダのＤＳＣＰ値を設定し、ＩＰネットワーク１０に送出する。端末３間でセッション確立のために送受するパケットについては、ＳＩＰサーバ２を介して相手の端末３に転送される。
図３は、ＳＩＰサーバ２の機能ブロック図である。図３に示すＳＩＰサーバ（以下サーバと略記）２は、セッションを確立するためのパケットを端末３から受信して、通信先の他の端末３へと転送を行う。サーバ２は、優先通話判定部２２、優先通話管理データベース（優先通話管理ＤＢ）２３、優先パスワード管理データベース管理部（優先ＰＷ管理ＤＢ管理部）２４、ロケーションデータベース（ロケーションＤＢ）２５、ロケーションデータベース管理部（ロケーションＤＢ管理部）２６、レジスタ部２７、プロキシ部２８、リダイレクト部２９及び認証部３０を含む。
サーバ２は、図２に示す端末３がセッション確立のために送信したパケットを、ＬＡＮインターフェース部２１を介して受信するとともに、他の端末３にパケットを送信する。
優先通話判定部２２は、受信したパケットに基づき、優先通話か否かを判定する。すなわち、セッション確立のためのパケットの所定のフィールドを参照して、優先通話者による通話（優先通話）であることを示す優先通話識別情報が設定されているか否かにより、優先通話であるか否かを判定する。優先通話管理ＤＢ２３は、優先通話判定部２２において判定を行うために利用する情報を格納する。
優先通話判定部２２は、受信したパケットに基づき、優先通話か否かを判定する。すなわち、セッション確立のためのパケットの所定のフィールドを参照して、優先通話者による通話（優先通話）であることを示す優先通話識別情報が設定されているか否かにより、優先通話であるか否かを判定する。優先通話管理ＤＢ２３は、優先通話判定部２２において判定を行うために利用する情報を格納する。
優先ＰＷ管理ＤＢ管理部２４は、優先通話者を識別するための情報を管理する。
ロケーションＤＢ２５は、サーバ２において、各端末３の登録状況を管理するための情報を格納する。ロケーションＤＢ管理部２６は、ロケーションＤＢ２５内の端末３の登録に係わる情報を管理する。詳細については後述する。
ロケーションＤＢ２５は、サーバ２において、各端末３の登録状況を管理するための情報を格納する。ロケーションＤＢ管理部２６は、ロケーションＤＢ２５内の端末３の登録に係わる情報を管理する。詳細については後述する。
レジスタ部２７は、端末３からの登録要求（ＲＥＧＩＳＴＥＲ）に対し、登録に係わる処理を実行する。プロキシ部２８は、ある端末３から受信した要求を、相手側の端末３に転送する。リダイレクト部２９は、端末３からの要求に対し、相手側の端末３の移動先のアドレスを端末３に通知する。認証部３０は、登録やセッション確立等に係わる認証処理を実行する。
図３に示すサーバ２は、図２に示す端末３からセッション確立の要求を受信すると、受信した要求の所定のフィールドに格納されている優先通話識別情報に基づき、受信したセッション確立の要求は、優先通話に係わるものであるか否かを判断する。そして、優先通話についてのセッション確立要求と判断した場合には、以降のパケットについては、高優先で端末３宛に送出する。以下、優先通話を確立する方法について、具体的に説明する。
図４は、端末３における優先通話の判定処理を示したフローチャートである。端末３は、ユーザ（通話者）が端末３の受話器を取る等の動作を行ったことにより、図２の端末３のオンフック／オフフック検知部３２においてオフフックを検知したことを契機として、図４に示す処理を開始する。
まず、ステップＳ１で、ＲＦＩＤ受信部３１においてタグ情報を受信するか否かを判定する。タグ情報を受信した場合には、優先通話者がＲＦＩＤタグを端末３に読み取らせて優先通話をしようとしていると判断し、優先通話モードの接続処理を行う。ステップＳ１の判定において、タグ情報を受信しなかった場合には、ステップＳ２に進む。
ステップＳ２で、操作部３３において、ユーザにより、優先通話に関するパスワードが入力されたか否かを判定する。ここでは、入力されたパスワードが優先ＰＷ管理ＤＢ３５に登録されているパスワードと一致するか否かについても判定している。正しいパスワードが入力された場合には、優先通話モードでの接続処理を行う。
ステップＳ２において、端末３の優先ＰＷ管理ＤＢ３５に登録されているパスワードと一致するパスワードの入力がないと判定された場合には、デフォルトの通話モードでの接続処理を行う。デフォルトの通話モードでは、優先度の設定等は特に行わない。
図５は、優先通話モードにおける接続フローを示す図である。以下、図５を参照して、本実施形態に係るＩＰ電話システム１において、発側の端末３Ａが着側の端末３Ｂに優先通話でＩＰ電話をかける場合の手順について説明する。
なお、以下においては、優先通話者による通話であることを認識してセッションを確立する方法を中心に説明することとし、公知の技術であるセッション確立処理の詳細については、説明を割愛する。
まず、ＲＦＩＤタグからタグ情報を受信したこと、あるいはパスワードが入力されたことをトリガ情報として、端末３Ａは、優先通話者により優先通話開始の操作がなされたことを認識する。優先通話開始の操作を認識すると、送信するＩＮＶＩＴＥ（セッション確立要求）メッセージのパケットのうちＳＩＰメッセージのメッセージボディに、セッション情報（Ｓタイプ）として、優先通話であることを示す値すなわち優先通話識別情報を設定する。
そして、サーバ２に高優先で、すなわちＩＰヘッダ部のＤＳＣＰ値をＥＦ（＝１０１１１０）に設定して送信する（Ｓ１０１）。
ここで、優先通話識別情報とは、パケットのＩＰヘッダ部がなくても、サーバ２や端末３内で、パケットが優先通話に係わるパケットであることを認識するための情報である。
ここで、優先通話識別情報とは、パケットのＩＰヘッダ部がなくても、サーバ２や端末３内で、パケットが優先通話に係わるパケットであることを認識するための情報である。
ここで、発側の端末３Ａは、サーバ２に対し、端末３Ａ−端末３Ｂ間のダイアログを他のダイアログと識別するための情報「Ｃａｌｌ−ＩＤ」についても、ＩＮＶＩＴＥメッセージのパケットに含めて送信する。以降のシーケンスで送受信されるパケットにはＣａｌｌ−ＩＤが設定されており、各装置は、受信したパケットのＣａｌｌ−ＩＤに基づき、端末３Ａ−端末３Ｂ間のダイアログ、すなわち優先通話として設定されているダイアログであることを認識する。ダイアログとは、複数の端末間で行われる一連のセッション、即ち、発側の端末によるＩＮＶＩＴＥメッセージの送出から、セッションを切断したことを示すＢＹＥメッセージに対応する２００ＯＫメッセージの受信までを含む、セッションの開始から終了までを指す。同一のダイアログに関するパケットには、同一のＣａｌｌ−ＩＤが用いられる。
また、端末３Ａは、送信するパケットに、ＩＰヘッダ部のＤＳＣＰ値として、ＩＰネットワーク１０において高優先で転送すべきこと（Expedited Forwarding、ＥＦ）を示す値「１０１１１０」を設定している。ＩＰネットワーク１０を構成するルータ等のネットワーク機器は、例えばネットワーク縮退時における迂回ルートへのトラフィック集中により、ネットワークが輻輳してしまった場合などは、ＤＳＣＰ値を参照して、優先順位の高いパケットから転送処理を行い、どうしても転送処理が追いつかないパケットに関しては廃棄処理を行う。
サーバ２は、ＩＮＶＩＴＥメッセージを受信すると、ＬＡＮインターフェース部２１でＤＳＣＰ値を含むＩＰヘッダ部が既に削除されたＩＮＶＩＴＥメッセージに設定されているＳタイプを参照する。Ｓタイプに優先通話であることを示す優先通話識別情報が設定されている場合には、サーバ２は、端末３Ａから受信したＩＮＶＩＴＥメッセージのパケットに格納されていたＣａｌｌ−ＩＤを自装置のデータベースに記憶させる。そして、ＬＡＮインターフェース部２１において、ＩＰヘッダ部のＤＳＣＰ値として「１０１１１０」を設定して、高優先でＩＮＶＩＴＥメッセージを端末３Ｂ宛に送出する（Ｓ１０２）。
以降のフローにおいては、ＩＰ電話システム１を構成する各装置は、端末３Ａ−端末３Ｂ間で送受するパケットに、同一のセッションの間は同一のＣａｌｌ−ＩＤを設定し、また、ＤＳＣＰ値は高優先であることを示す値「１０１１１０」を設定する。すなわち、本実施形態に係るＩＰ電話システム１は、ＩＮＶＩＴＥ以降のメッセージの送受においては、Ｃａｌｌ−ＩＤにより端末３Ａ−端末３Ｂ間の通信であること、すなわち優先通話であることを認識する。そして、優先通話のセッション確立のために送受するパケットについては、ＩＰヘッダ部のＤＳＣＰ値を所定の値に設定して送出する。
着側の端末３Ｂは、ＩＮＶＩＴＥメッセージを受信すると、ＩＮＶＩＴＥメッセージに設定されているＳタイプを参照する。Ｓタイプに、優先通話であることを示す優先通話識別情報が設定されている場合には、ＩＮＶＩＴＥメッセージ中のＣａｌｌ−ＩＤを記憶するとともに、端末３Ａ宛に返すＴｒｙｉｎｇメッセージのＩＰヘッダ部のＤＳＣＰ値に、ＬＡＮインターフェース部３９において「１０１１１０」を設定して、高優先で送信する（Ｓ１０３）。
サーバ２は、端末３ＢからＴｒｙｉｎｇメッセージを受信すると、Ｔｒｙｉｎｇメッセージ中のＣａｌｌ−ＩＤを参照して、保持しているＣａｌｌ−ＩＤと比較する。先にＩＮＶＩＴＥメッセージから取り出して記憶させておいたＣａｌｌ−ＩＤと同一である場合には、端末３Ｂから受信したＴｒｙｉｎｇが、優先通話のセッション確立のために送受されるパケットであると認識する。この場合はＬＡＮインターフェース部２１において、端末３Ａ宛に転送するＴｒｙｉｎｇメッセージのＩＰヘッダ部のＤＳＣＰ値に「１０１１１０」を設定して、高優先で送出する（Ｓ１０４）。
以降は、各端末３Ａ、３Ｂは、受信したメッセージのＣａｌｌ−ＩＤを参照して、保持するＣａｌｌ−ＩＤと一致する場合には、優先通話のセッション確立のために送受されるパケットを受信したと認識する。この場合はＬＡＮインターフェース部３９においてＩＰヘッダ部のＤＳＣＰ値に高優先であることを示す値として「１０１１１０」を設定して送信する（Ｓ１０５、Ｓ１０７、Ｓ１０９）。サーバ２は、端末３Ａ、３Ｂから受信したメッセージのＣａｌｌ−ＩＤを参照する。受信したメッセージのＣａｌｌ−ＩＤが保持しているＣａｌｌ−ＩＤと一致する場合には、優先通話のセッション確立のためのパケットであると認識し、ＬＡＮインターフェース部２１においてＩＰヘッダ部のＤＳＣＰ値に高優先であることを示す値として「１０１１１０」を設定して送出する（Ｓ１０６、Ｓ１０８、Ｓ１１０）。
端末３Ａと端末３Ｂとの間で、サーバ２を介してＲｉｎｇｉｎｇ、２００ＯＫ及びＡＣＫのメッセージを上記の方法で図５に示す順に送受する（Ｓ１０５〜Ｓ１１０）と、端末３Ａ及び端末３Ｂは、高優先での音声データの送受を開始する。
通話中は、端末３Ａ及び端末３Ｂは、ＲＴＰ（Real-time Transport Protocol）を用いて、直接に相手の端末と音声パケットを送受する。優先通話では、ＩＰヘッダ部のＤＳＣＰ値に高優先であることを示す値を設定する事で、双方向で専用線品質の通話回線が確保されることになる。
端末３Ａ、３Ｂにおいてオンフック状態となったことを検知すると、通話終了のための処理を開始する。まず、最初にオンフック状態となった端末側（本実施例においては発側の端末３Ａ）から着側の端末３ＢにＢＹＥメッセージを送信する（Ｓ１１１）。ＬＡＮインターフェース部３９において、ＩＰヘッダ部のＤＳＣＰ値に「１０１１１０」を設定して、高優先で送信する。
サーバ２は、セッション確立時と同様に、メッセージ中のＣａｌｌ−ＩＤが保持するＣａｌｌ−ＩＤと一致する場合には、ＬＡＮインターフェース部２１においてＩＰヘッダ部のＤＳＣＰ値を高優先に設定して、端末３Ｂ宛に送出する（Ｓ１１２）。
ＢＹＥメッセージを受信した端末３Ｂは、セッション確立時と同様に、メッセージ中のＣａｌｌ−ＩＤが保持しているＣａｌｌ−ＩＤと一致するか否かを判断する。一致する場合には、ＬＡＮインターフェース部３９にてＩＰヘッダ部のＤＳＣＰ値に「１０１１１０」を設定して高優先で送信する（Ｓ１１３）。サーバ２は同様にＣａｌｌ−ＩＤを参照して、優先通話の２００ＯＫを判断して、ＬＡＮインターフェース部２１にてＩＰヘッダ部のＤＳＣＰ値に「１０１１１０」を設定して高優先で端末３Ａ宛に送出する（Ｓ１１４）。端末３Ａにおいて２００ＯＫを受信すると、一連の接続フローは完了する。
図５に示す一連のフローが完了すると、各装置（端末３Ａ、３Ｂ及びサーバ２）において、通話のために保持していたＳタイプやＣａｌｌ−ＩＤ等の各種の情報を初期化し、処理を終了する。
図５に示すフローのうち、ＩＮＶＩＴＥ、Ｔｒｙｉｎｇ等のサーバ２を介して送受されるＳＩＰメッセージは、スタートライン、メッセージヘッダ、メッセージボディなどの汎用書式で記述される。本実施形態に係る優先通話の確立方法に関しては、ＩＮＶＩＴＥリクエストのメッセージボディに含まれるＳタイプを利用して、Ｓタイプに優先通話である事を示す識別情報を設定する事で、各装置が初期の優先通話の識別を行っている。また、Ｔｒｙｉｎｇなど、メッセージボディがないＳＩＰメッセージに関しては、Ｃａｌｌ−ＩＤにより優先通話の識別を行っている。ＳＩＰのパケット及び音声パケットのＩＰヘッダ部には、ＬＡＮインターフェース部により、ＤＳＣＰ値が格納される。
ＩＰネットワーク１０上のルータなどの中継装置は、通常パケットが到着した順に即パケットの転送処理を行うが、ネットワーク縮退時などの、迂回ルートに回線容量以上のトラフィックが集中してしまった場合などは、後から到着したパケットは、前に到着したパケットの転送が全て終了するまで待たされる遅延が発生する。さらにこの状況が悪化するとルータが輻輳状態となりルータで処理しきれないパケットの廃棄が行われる。
ルータの輻輳状態による重要パケットの廃棄を回避するために、ルータはＴｏＳフィールドの値を元にパケット転送の優先順位を決める機能を有しており、たとえばＤＳＣＰ値などを使用してトラフィックをいくつかのクラスに分類して、さらにクラスごとに優先度を変えてパケットの転送順位を制御する事ができる。
本実施形態に係るＩＰ電話システム１においては、発側の端末３Ａは、セッション確立シーケンスで最初に送信するＩＮＶＩＴＥメッセージに、優先通話であることを示す値である優先通話識別情報を設定する。また優先通話識別情報が設定されたＩＮＶＩＴＥメッセージが、例えＩＰネットワークが輻輳中であっても、途中で廃棄される確率を小さくするために、ＬＡＮインターフェース部においてＩＰヘッダ部のＤＳＣＰ値を、高優先を示す値、すなわち、ルータ等の中継装置においてパケット転送の優先順位を上げて廃棄されにくくする値（Expedited Forwarding、ＥＦ）に設定して（優先制御を行うための制御情報を設定して）転送する。従って、発側の端末３Ａからサーバ２に至るネットワーク経路の途中にあるＬ３ＳＷ４などの中継装置が輻輳状態であっても、発側の端末３Ａがセッション確立シーケンスで最初に送信するＩＮＶＩＴＥメッセージが、中継装置で破棄されずにサーバ２に到達できる可能性が高い。
サーバ２及び着側の端末３Ｂは、ＩＮＶＩＴＥメッセージ中に優先通話であることを示す優先通話識別情報が設定されている場合には、ＩＮＶＩＴＥメッセージ中のＣａｌｌ−ＩＤを自装置に記憶させ、ＩＮＶＩＴＥメッセージ以降に送受されるメッセージについては、各端末およびサーバ２はＣａｌｌ−ＩＤにより優先通話に係わるメッセージであることを認識する。優先通話に係わるメッセージと認識されたパケットは、それぞれのＬＡＮインターフェース部においてＩＰヘッダ部のＤＳＣＰ値を高優先を示す値に設定する。これにより、ネットワーク上のルータ等が輻輳状態であっても、より確実に優先通話を確立させ、確立した優先通話を維持することが可能となる。
次に、パケットのフォーマットを参照して、これらの情報の格納先について具体的に説明する。
図６は、ＳＩＰパケットのデータフォーマット例を示す図である。ＳＩＰパケットは、メッセージ本体を含むＳＩＰメッセージが、ＩＰヘッダ及びＴＣＰヘッダでカプセル化されている。
図６は、ＳＩＰパケットのデータフォーマット例を示す図である。ＳＩＰパケットは、メッセージ本体を含むＳＩＰメッセージが、ＩＰヘッダ及びＴＣＰヘッダでカプセル化されている。
ＳＩＰメッセージには、スタートライン、メッセージヘッダ及びメッセージボディが含まれる。スタートラインには、ＩＮＶＩＴＥやＡＣＫ等のメッセージを識別するための情報が格納される。メッセージヘッダには、端末３間（図５においては端末３Ａ−３Ｂ間）のダイアログを識別するためのＣａｌｌ−ＩＤが格納され、メッセージボディには、Ｓタイプが格納される。Ｓタイプは、ＳＤＰ（Session Description Protocol）で記述する。実施例では、「ｓ＝ｔａｇ／［タグＩＤ］」と記述する。Ｓタイプに優先通話者の保有するＲＦＩＤタグのタグＩＤを含めることにより、優先通話機能を有さない端末のＳタイプに、偶然優先通話と同じセッション名が設定される確率を小さくすることができる。
なお、メッセージヘッダには、登録処理に関するＥｘｐｉｒｅｓ値についても格納されるが、詳しくは後述する。
ＤＳＣＰ値は、ＩＰヘッダのＴｏＳ（Type of Service）フィールドに格納される。なお、図６においてはＩＰｖ４（Internet Protocol version 4）ヘッダのフォーマットを示す。ＩＰｖ４ヘッダのフォーマットについては公知であるので、ここでは、ＤＳＣＰ値の格納されるＴｏＳフィールド以外についての詳細な説明は省略する。
ＤＳＣＰ値は、ＩＰヘッダのＴｏＳ（Type of Service）フィールドに格納される。なお、図６においてはＩＰｖ４（Internet Protocol version 4）ヘッダのフォーマットを示す。ＩＰｖ４ヘッダのフォーマットについては公知であるので、ここでは、ＤＳＣＰ値の格納されるＴｏＳフィールド以外についての詳細な説明は省略する。
図７は、音声パケットのデータフォーマット例を示す図である。音声パケットは、音声データ本体である音声ペイロードが、ＩＰヘッダ、ＵＤＰ（User Datagram Protocol）ヘッダ及びＲＴＰヘッダでカプセル化されている。
本実施例においては、端末３は、音声パケットについても図６のＳＩＰパケットと同様に、ＩＰヘッダのＴｏＳフィールドに高優先でパケットを転送すべきことを示すＤＳＣＰ値「１０１１１０」を格納する。図７に示すＩＰヘッダについても、図６と同様に公知のＩＰｖ４ヘッダのフォーマットを示しているため、ここでは、ＴｏＳフィールド以外フィールドの説明については、省略することとする。
上記のとおり、本実施形態に係るＩＰ電話システム１においては、優先通話者が電話をかけようとした場合には、ＳＩＰサーバ２を介して送受されるパケットについては、ＬＡＮインターフェース部２１がＩＰヘッダ部のＤＳＣＰ値を「１０１１１０」に設定する。ＩＰヘッダ部のＤＳＣＰ値を「１０１１１０」に設定したパケットについては、ＩＰネットワーク上のＬ３ＳＷが高優先で転送する。
発側の端末と着側の端末との間でＳＩＰパケットを中継するサーバ２の動作について図８を参照して説明する。
図８は、サーバ２における受信したパケットを判定する処理を示したフローチャートである。図８に示す処理は、図３のサーバ２を構成する優先通話判定部２２やプロキシ部２８等のＳＩＰ基本機能部において実行される。サーバ２は、端末３（図５の発側の端末３Ａ及び着側の端末３Ｂ）から図６に示すフォーマットのＳＩＰパケットを受信したことを契機として、図８に示す処理を開始する。
図８は、サーバ２における受信したパケットを判定する処理を示したフローチャートである。図８に示す処理は、図３のサーバ２を構成する優先通話判定部２２やプロキシ部２８等のＳＩＰ基本機能部において実行される。サーバ２は、端末３（図５の発側の端末３Ａ及び着側の端末３Ｂ）から図６に示すフォーマットのＳＩＰパケットを受信したことを契機として、図８に示す処理を開始する。
まず、ステップＳ１１で、受信したパケットがＩＮＶＩＴＥメッセージであるか否かを判定する。ＩＮＶＩＴＥメッセージであると判定した場合には、ステップＳ１２に進み、ＳＩＰメッセージ中のＳタイプを参照し、優先通話であるか否かを判定する。優先通話と判定した場合には、ステップＳ１３に進み、ＩＮＶＩＴＥのパケットに含まれるＣａｌｌ−ＩＤをサーバ２の記憶手段、例えば図３の優先通話管理ＤＢ２３に記憶させる。そして、ステップ１４で、優先通話管理ＤＢ２３を更新し、更に同一タグ通話を確認し、重複する優先通話でないかを確認する。優先通話管理ＤＢ２３については、図１２等を参照して詳しく説明することとする。
ステップＳ１４で確認した結果、重複する優先通話でない場合には、Ｓタイプにより識別されるタグＩＤのセッション状態については、「通話中」を示す値を設定する。重複する優先通話であることが確認された場合の処理については、通話の排他処理として、後に図１８及び図１９を参照して詳しく説明する。
ステップＳ１４において優先通話管理ＤＢ２３のセッション状態を更新すると、ステップＳ１５で、ＳＩＰの公知の機能を利用して、高優先でパケットの転送処理を行う。即ち、送信するパケットのＩＰヘッダ内のＤＳＣＰの値に高優先を示す値を設定し、すなわち、ルータ等の中継装置が輻輳状態であっても優先的にパケットの転送処理が行われ、破棄される確率が低い値に設定し、設定後のパケットを送出する。高優先の設定方法については、図５を参照して説明したとおりである。
ステップＳ１２において、優先通話でないと判定した場合には、ステップＳ２０に進む。ステップＳ２０で、通常の（優先度の設定を特に行わない）パケットの転送処理を行う。通常のパケットの転送処理においてＤＳＣＰ値に設定されるのは、ベストエフォートを表す値であるので、ルータ等の中継装置が輻輳状態の場合には破棄される確率が高い。
ステップＳ１１において、受信したパケットがＩＮＶＩＴＥメッセージ以外であると判定した場合には、ステップＳ１６に進む。ステップＳ１６においては、受信したＳＩＰパケットが登録要求（ＲＥＧＩＳＴＥＲ）であるか否かを更に判定する。受信したパケットが登録要求である場合の処理については、後述する。
ステップＳ１６の判定において、登録要求以外であると判定した場合には、セッション確立のために送受される各種のメッセージのうち、ＩＮＶＩＴＥ以降のメッセージを受信したと判断して、ステップＳ１７に進む。そして、パケットのサーバ２で認識できるメッセージヘッダのＣａｌｌ−ＩＤを参照し、優先通話についてのＣａｌｌ−ＩＤであるか否かを判定する。判定は、ステップＳ１３において記憶させたＣａｌｌ−ＩＤと一致するか否かに基づき行う。
ステップＳ１７の判定において、優先通話についてのＣａｌｌ−ＩＤであると判定した場合には、ステップＳ１８に進む。そして、ステップＳ１８で、受信したＳＩＰパケットが、ＢＹＥに対する２００ＯＫであるか否かを判定する。
ステップＳ１８において、受信したＳＩＰパケットが、ＢＹＥに対する２００ＯＫ以外であると判定した場合には、通話中であると判断し、ステップＳ１４に進む。ステップＳ１４については先に説明したとおりであり、優先通話管理ＤＢのセッション状態を「通話中」で維持し、ステップＳ１５でＳＩＰの機能に基づき、高優先でのＳＩＰパケットの転送を行う。
ステップＳ１８において、ＢＹＥに対する２００ＯＫである場合には、図５に示すシーケンスの最後に転送するパケットを受信したと判断し、ステップＳ１９に進む。ステップＳ１９で、２００ＯＫを高優先で転送するとともに、保持していた当該優先通話についてのＣａｌｌ−ＩＤを削除する。そして、優先通話管理ＤＢ２３のセッション状態に「通話なし」を示す値を設定し、ステップＳ２０に進み、通常の（すなわち優先度の設定を行わない）動作に戻る。
ステップＳ１７の判定において、Ｃａｌｌ−ＩＤをチェックした結果、優先通話についてのＣａｌｌ−ＩＤではないと判定した場合には、ステップＳ２０に進み、ＳＩＰ機能に基づき、優先度の設定を行わずにＳＩＰパケットの転送を行う。
なお、上述の実施例においては、同一のダイアログに関するパケットであるか否かを、端末３及びサーバ２ともにＣａｌｌ−ＩＤを用いて識別しているが、Ｃａｌｌ−ＩＤ以外の情報を用いて同一のダイアログに関するパケットであるか否かを識別しても構わない。例えば、ステップＳ１３において、ＩＮＶＩＴＥのパケットに含まれる発側端末３ＡのＩＰアドレスと着側端末３ＢのＩＰアドレスとの組を優先通話管理ＤＢ２３に記憶することが考えられる。また、同様に、着側端末３Ｂ及び発側端末３Ａにおいても、ＩＮＶＩＴＥのパケットに含まれる発側端末３ＡのＩＰアドレスと着側端末３ＢのＩＰアドレスとの組を記憶する。
Ｃａｌｌ−ＩＤの代わりに、発側端末３ＡのＩＰアドレスと着側端末３ＢのＩＰアドレスとの組を、サーバ２、発側端末３Ａおよび着側端末３Ｂのそれぞれで記憶した場合には、サーバ２及び各端末３Ａ、３Ｂにおいては、受信したパケットに示される発側端末３Ａ及び着側端末３ＢのＩＰアドレスの組と、記憶しておいたＩＰアドレスの組とを比較し、同一であった場合には、優先通話にかかわるパケットであると判断することができる。優先通話にかかわるパケットであると、サーバ２及び各端末３Ａ、３Ｂがそれぞれ判断した後の処理は、上記実施例と同様である。記憶したＩＰアドレスの組については、上述の実施例でＣａｌｌ−ＩＤを初期化するタイミングで、記憶部のＩＰアドレスの組に関する情報を初期化すればよい。
上述のとおり、本実施形態に係るＩＰ電話システム１では、発側の端末３において、ＲＦＩＤタグやパスワードにより優先通話者による通話であることを認識し、ＩＮＶＩＴＥメッセージに優先通話であることを示すＳタイプを設定する。ＩＰ電話システム１内のいずれの端末３を使用しても優先通話者が優先通話をすることができるよう、パスワードについては、ネットワーク内の端末３間で共有している。サーバ２は、端末３間でのパスワードの共有を実現させるため、パスワードの管理を行っている。以下、サーバ２によるパスワードの管理方法について具体的に説明する。
図９は、サーバ２においてパスワードを管理する方法の概要を説明する図である。ＩＰ電話システム１を構成する複数の端末３（３Ａ、３Ｂ、…、３Ｎ）のうち、端末３Ａにおいて、操作部３３を介してパスワード変更の指示が入力された場合を例に説明する。
端末３Ａの操作部３３において、優先通話者によるパスワードの変更操作を受け付けると、端末３Ａは、自装置内の優先ＰＷ管理ＤＢ３５Ａに、優先通話者が新たに設定したパスワードを登録するとともに、サーバ２に更新後のパスワードを通知する。サーバ２は、自装置の優先通話管理ＤＢ２３に、端末３Ａから通知された新たなパスワードを登録し自装置の優先通話管理ＤＢ２３と各端末３の優先ＰＷ管理ＤＢ３５とを同期させる。これにより、優先通話者は、ＩＰ電話システム１内のいずれの端末３からもパスワードを使用して優先通話をかけることが可能となる。
なお、優先通話機能は、端末３によっては設定がされておらず、使用できない場合もある。そこで、実施例では、サーバ２は、ロケーションＤＢ２５の各端末３が優先通話機能を備えるか否かを示す情報を参照し、優先通話機能を備える端末３に対して、データベースの内容を同期させている。
各端末３が優先通話機能を備えるか否かを示す情報については、サーバ２は、端末３の登録時に端末３から受信した情報に基づいて、ロケーションＤＢ２５（図３）に登録を行っている。登録処理については、後述する。
図１０〜図１４を参照して、図９に示すサーバ２によるパスワードの管理方法について、より具体的に説明する。
図１０は、端末３におけるパスワードの変更処理を示したフローチャートである。図１０に示す処理は、図２の端末３の制御処理部３８において実行され、端末３の制御処理部３８は、図９の端末３Ａにおいて、操作部３３を介してパスワード変更の指示が入力されたことを契機として、図１０に示す処理を開始する。
図１０は、端末３におけるパスワードの変更処理を示したフローチャートである。図１０に示す処理は、図２の端末３の制御処理部３８において実行され、端末３の制御処理部３８は、図９の端末３Ａにおいて、操作部３３を介してパスワード変更の指示が入力されたことを契機として、図１０に示す処理を開始する。
まず、ステップＳ３１で、ＲＦＩＤ受信部３１おいて優先通話者の保有するＲＦＩＤタグからトリガ情報としてのタグ情報を受信したか否かを判定する。ＲＦＩＤタグからタグ情報を受信できない場合には、優先通話者による操作ではないと判断し、ステップＳ３６に進む。ステップＳ３６では、パスワードの設定を変更する処理をキャンセルし、処理を終了する。
ステップＳ３１の判定において、ＲＦＩＤタグからタグ情報を受信したと判定した場合には、ステップＳ３２に進み、タグＩＤの確認を行う。具体的には、受信したタグＩＤが、優先ＰＷ管理ＤＢ３５に登録されているか否かを判定する。優先ＰＷ管理ＤＢ３５に登録されていないタグＩＤであった場合には、ステップＳ３６に進み、パスワード変更の処理をキャンセルし、処理を終了する。
ステップＳ３２の判定において、受信したタグＩＤが優先ＰＷ管理ＤＢ３５に登録されていると判定した場合には、ステップＳ３３に進み、パスワードの変更操作を受け付ける。そして、ステップＳ３４で、パスワード確定の指示が入力されたか否かを判定する。パスワードが確定されなかった場合には、ステップＳ３６に進み、パスワード変更の処理をキャンセルして、処理を終了する。
ステップＳ３４において、パスワード確定の指示が入力されたと判定すると、ステップＳ３５に進み、ステップＳ３３で入力されたパスワードを、優先ＰＷ管理ＤＢ３５に新たに登録する。また、サーバ２に対して変更後のパスワードを通知し、処理を終了する。
図１１は、端末３の優先ＰＷ管理ＤＢ３５に格納されるデータの構造例を示す図である。優先ＰＷ管理ＤＢ３５においては、管理番号（管理Ｎｏ．）、タグＩＤ及びパスワードを含む。
管理番号は、優先通話者ごとに登録されている情報を端末３において識別するための識別情報である。
タグＩＤは、優先通話者が保有するＲＦＩＤタグを識別する識別情報である。パスワードは、図９を参照して説明したとおり、ＲＦＩＤタグを保有する優先通話者により端末３を通じて設定された数字や文字を含む文字列である。パスワードは、タグＩＤと関連付けられている。これにより、端末３は、優先通話者がＲＦＩＤタグを保有していない場合等に端末３の操作部３３を介して入力したパスワードに基づき、パスワードを入力したユーザがタグＩＤを割り当てられた優先通話者であることを認証する。
タグＩＤは、優先通話者が保有するＲＦＩＤタグを識別する識別情報である。パスワードは、図９を参照して説明したとおり、ＲＦＩＤタグを保有する優先通話者により端末３を通じて設定された数字や文字を含む文字列である。パスワードは、タグＩＤと関連付けられている。これにより、端末３は、優先通話者がＲＦＩＤタグを保有していない場合等に端末３の操作部３３を介して入力したパスワードに基づき、パスワードを入力したユーザがタグＩＤを割り当てられた優先通話者であることを認証する。
図１２は、サーバ２のデータベースに格納されるデータの構造例を示す図である。図１２（ａ）は、優先通話管理ＤＢ２３のデータ構造例であり、図１２（ｂ）は、ロケーションＤＢ２５のデータ構造例である。
図１２（ａ）に示す優先通話管理ＤＢ２３においては、タグＩＤにパスワード（ＰＷ）及びセッション状態が関連付けられている。
タグＩＤは、優先通話者が保有するＲＦＩＤタグを識別する識別情報である。パスワードは、端末３から通知された、数字や文字を含む文字列である。
タグＩＤは、優先通話者が保有するＲＦＩＤタグを識別する識別情報である。パスワードは、端末３から通知された、数字や文字を含む文字列である。
セッション状態には、タグＩＤにより識別される優先通話者が使用する端末についての接続状況を示す値が格納される。
図１２（ｂ）に示すロケーションＤＢ２５においては、ＳＩＰ−ＵＲＩ（Uniform Resource Identifier）に、優先通話機能情報、ＩＰアドレス及び更新情報が関連付けられている。
図１２（ｂ）に示すロケーションＤＢ２５においては、ＳＩＰ−ＵＲＩ（Uniform Resource Identifier）に、優先通話機能情報、ＩＰアドレス及び更新情報が関連付けられている。
ＳＩＰ−ＵＲＩは、ＳＩＰを利用し通信リソースを識別するための情報であり、ＩＰ通信においては、宛先の端末３を指定するために使用する。
優先通話機能情報は、端末３が優先通話機能を備えるか否かを示す情報である。実施例では、優先通話機能有りの場合は「１」を、優先通話機能なしの場合は「０」を設定する。優先通話機能情報については、端末３の登録時に、端末３から受信する。登録処理については後述する。
優先通話機能情報は、端末３が優先通話機能を備えるか否かを示す情報である。実施例では、優先通話機能有りの場合は「１」を、優先通話機能なしの場合は「０」を設定する。優先通話機能情報については、端末３の登録時に、端末３から受信する。登録処理については後述する。
ＩＰアドレスは、ＩＰネットワーク１０において端末３に割り当てられた識別番号である。例えば、上述の図５の端末３Ａ−端末３Ｂ間の接続の際には、端末３Ａから通話先である端末３ＢのＳＩＰ−ＵＲＩを受信すると、ＳＩＰ−ＵＲＩに対応するＩＰアドレスを求め、求めたＩＰアドレス宛にパケットを送出する。
更新情報は、例えば、図１２（ｂ）に示すレコードの保持期間や最終更新時間を含み、ロケーションＤＢ２５に登録されているレコードが保持されている期間、最後に更新された時刻情報等が格納される。
サーバ２は、図１０のステップＳ３５の処理により端末３から更新後のパスワードの通知を受ける。サーバ２は、通知を受けると、図１２（ａ）に示す優先通話管理ＤＢ２３のパスワードを更新する。そして、図１２（ｂ）に示すロケーションＤＢ２５において優先通話機能「有り」が設定されている端末３の優先ＰＷ管理ＤＢ３５を、サーバ２の優先通話管理ＤＢ２３と同期させる。
図１３及び図１４は、端末３とサーバ２との間のデータベースの同期処理についてのシーケンス図である。図１３は、通常時における同期処理のシーケンス図であり、図１４は、高優先モードにおける同期処理のシーケンス図である。ここでの「通常時」とは、高優先を設定せずにパケットを送出することを示す。
図１３を参照して、同期処理の手順について説明する。通常時における同期処理では、サーバ２と各端末３との間で送受するパケットには、特に高優先の設定は行わない。
まず、サーバ２と各端末３Ａ、３Ｂ、…、３Ｎとの間でハンドシェイク（ＳＹＮ、ＳＹＮ＋ＡＣＫ、ＡＣＫ）を行う（Ｓ１２１〜Ｓ１２３）。ハンドシェイクの後、サーバ２は、優先通話管理ＤＢ２３の差分データを各端末３（３Ａ、…、３Ｎ）に送信する（Ｓ１２４）。ここでの差分データには、新たに設定されたパスワードの他、パスワードに対応する管理番号、タグＩＤが含まれる。タグＩＤ及びパスワードについては、秘匿性を高めるため、暗号化して送信する。
まず、サーバ２と各端末３Ａ、３Ｂ、…、３Ｎとの間でハンドシェイク（ＳＹＮ、ＳＹＮ＋ＡＣＫ、ＡＣＫ）を行う（Ｓ１２１〜Ｓ１２３）。ハンドシェイクの後、サーバ２は、優先通話管理ＤＢ２３の差分データを各端末３（３Ａ、…、３Ｎ）に送信する（Ｓ１２４）。ここでの差分データには、新たに設定されたパスワードの他、パスワードに対応する管理番号、タグＩＤが含まれる。タグＩＤ及びパスワードについては、秘匿性を高めるため、暗号化して送信する。
端末３Ａ、…、３Ｎは、差分データを受信すると、サーバ２にＡＣＫを返す（Ｓ１２５）。そして、変更内容をサーバ２に対して送信する（Ｓ１２６）。サーバ２に送信される情報としては、変更されたパスワードの他、対応する管理番号、タグＩＤが含まれる。変更確認用データのうち、タグＩＤ及びパスワードについては、差分データの場合と同様に、暗号化して送信する。サーバ２は、変更確認用データを送信した端末３Ａ、…、３Ｎのそれぞれに対してＡＣＫを返す（Ｓ１２７）。
変更確認用データの送信に対するＡＣＫを受信した各端末３Ａ、…、３Ｎは、同期処理のための通信を終了するため、サーバ２にＦＩＮを送信する（Ｓ１２８）。サーバ２は、受信したＦＩＮに対してＡＣＫを返す（Ｓ１２９）とともに、ＦＩＮを送信してきた端末３のそれぞれに対してＦＩＮを送信する（Ｓ１３０）。端末３は、サーバ２に対してＦＩＮに対するＡＣＫを返し（Ｓ１３１）、処理を終了する。
例えば、ネットワークの縮退等により、サーバ２または端末３Ａ、…、３Ｎから送出されたパケットが受信側の装置に到達せず、図１３に示す通常時における同期処理が完了しない場合には、同図に示す処理を所定の回数繰り返す。更に、通常時の同期処理を所定回数繰り返しても同期が完了しない場合には、サーバ２は、図１４に示す高優先モードでの同期処理へと移行する。
図１４に示す高優先モードでの同期処理においては、サーバ２と各端末３との間で送受するパケットに高優先を設定する。具体的には、ＬＡＮインターフェース部２１においてＩＰヘッダのＤＳＣＰ値に「１０１１１０」を設定し、ＴＣＰヘッダのコードビットのうち、ＵＲＧ（urgent）フラグをオンに設定（「１」を設定）する。
ＤＳＣＰ値及びＵＲＧフラグに上記の値が設定されたＳＹＮを受信した各端末３は、高優先モードでの同期処理であることを認識する。以降のシーケンスでは、端末３及びサーバ２は、同期処理が完了するまで、ＬＡＮインターフェース部３９にてＩＰヘッダ部のＤＳＣＰ値に高優先を示す値を設定し、ＵＲＧフラグをオンに設定したパケットを送受する。高優先モードにおける同期処理の手順については、図１４に示すとおり、図１３に示す通常時の同期処理と同様であり、図１４のＳ１４１〜Ｓ１５１のステップは、それぞれ図１３のＳ１２１〜Ｓ１３１のステップと対応する。
なお、上記においては、予め設定されているパスワードを変更する場合について説明している。パスワードの初期登録についても同様の方法で行う構成としてもよい。あるいは、初期登録時には、パスワード入力の操作を受け付けた端末３Ａ、…、３Ｎから、上記手段以外の手段を用いてサーバ２に通知をし、サーバ２から各端末３Ａ、…、３Ｎに通知する構成としてもよい。更には、直接サーバ２に初期登録をして、各端末３Ａ、…、３Ｎに通知する構成としてもよい。
また、同期をとる方法についても、上記の方法は一例を示すものであり、これに限定されるものではない。例えば、ＳＩＰの基本的な機能を用いる等、各種の手段を用いることも可能である。
パスワードの同期処理のためにサーバ２−端末３Ａ、…、３Ｎ間で送受するパケットについては高優先で送信することにより、特に高優先を設定せずにパケットを送信する場合と比べて、より確実に同期処理を行うことができる。
ところで、ＶｏＩＰ端末３は、定期的にＳＩＰサーバ２に対して登録要求（ＲＥＧＩＳＴＥＲメッセージ）を送信し、自装置の存在をサーバに認識させておく必要がある。以下、登録処理について説明する。
図１５及び図１６は、端末３の登録処理についてのシーケンス図である。図１５は通常時における登録処理のシーケンス図であり、図１６は、高優先モードにおける登録処理のシーケンス図である。図１３及び図１４を参照して説明した同期処理の場合と同様に、ここでの「通常時」とは、高優先を設定せずにパケットを送出することを言うものとする。
図１５を参照して、登録処理の手順について説明する。図１５に示す登録処理は、端末３がサーバ２に初期登録を行う場合や、初期登録後に定期的に更新を行う際に実行される。ここでは、発側の端末３（図５の端末３Ａ）の登録を例に説明する。
図１３に示す同期処理と同様に、通常時においては、サーバ２と端末３との間で送受するパケットには、特に高優先の設定は行わない。
まず、端末３が、サーバ２に対して登録要求（ＲＥＧＩＳＴＥＲ）を送信する（Ｓ１６１）。サーバ２は、登録要求を受信すると、端末３に対して２００ＯＫ及びＡＣＫを返す（Ｓ１６２、Ｓ１６３）。サーバ２は、ＡＣＫの送信後に、受信した登録要求に含まれる情報に基づき、図１２（ｂ）に示すロケーションＤＢ２５に必要な情報を登録するとともに、優先通話機能を有する旨のメッセージ待ちに係わるタイマを設定する。
まず、端末３が、サーバ２に対して登録要求（ＲＥＧＩＳＴＥＲ）を送信する（Ｓ１６１）。サーバ２は、登録要求を受信すると、端末３に対して２００ＯＫ及びＡＣＫを返す（Ｓ１６２、Ｓ１６３）。サーバ２は、ＡＣＫの送信後に、受信した登録要求に含まれる情報に基づき、図１２（ｂ）に示すロケーションＤＢ２５に必要な情報を登録するとともに、優先通話機能を有する旨のメッセージ待ちに係わるタイマを設定する。
端末３は、サーバ２から２００ＯＫ及びＡＣＫを受信すると、端末３が優先通話機能を有するＶｏＩＰ端末である場合にはその旨を通知するメッセージをサーバ２に対して送信する（Ｓ１６４）。サーバ２は、上記の優先通話機能を有する旨のメッセージ待ちに係わる設定タイマを利用して、登録処理に対するＡＣＫを送信してから所定の期間内に優先通話機能を有する旨のメッセージをＶｏＩＰ端末３から受信するか否かを判断している。優先通話機能を有する旨のメッセージ待ちに係わるタイマで設定した期間内に端末３から優先通話機能を有する旨のメッセージを受信しなかった場合には、その端末３は優先通話機能を有しない端末であると判断する。この場合は、ロケーションＤＢ２５に優先通話機能「なし」であることを示す値「０」を設定し、登録処理を終了する。優先通話機能を有する旨のメッセージ待ちに係わるタイマで設定した期間内に優先通話機能を有する旨のメッセージを受信した場合には、ロケーションＤＢ２５に、端末３の優先通話機能の有無については、「優先通話機能有り」であることを示す値「１」を設定する。そして、端末３に対してメッセージに対するＡＣＫを返し（Ｓ１６５）、登録処理を終了する。
以降は、サーバ２は、次の登録更新のタイミングまで、ロケーションＤＢ２５に登録した情報を保持する。通常時においては、登録更新処理は、例えば、１分ごとに実行する。
図１６に示す高優先モードにおける登録処理が実行される前提としては、例えば、ネットワークの縮退等が原因で、ネットワーク上でパケットロスが生じる等により、図１５に示す通常時における登録処理が正常に終了していないことが挙げられる。登録処理が正常に終了していない場合には、端末３は、所定の時間間隔で、登録要求を再送する。
図１６に示す高優先モードにおける登録処理が実行される前提としては、例えば、ネットワークの縮退等が原因で、ネットワーク上でパケットロスが生じる等により、図１５に示す通常時における登録処理が正常に終了していないことが挙げられる。登録処理が正常に終了していない場合には、端末３は、所定の時間間隔で、登録要求を再送する。
所定の回数登録要求を再送しても、サーバ２からの応答がない等により、登録処理が完了しない場合（図１６中の（＊））には、端末３は、高優先モードへと移行する。高優先モードでは、端末３は、送信する登録要求のメッセージに、優先登録であることを示す値すなわち優先登録識別情報を設定する。そしてサーバ２に高優先で、すなわちＤＳＣＰ値をＥＦ（＝１０１１１０）に設定して送信する（Ｓ１７１）。優先登録識別情報の設定方法は、例えば、ＲＥＧＩＳＴＥＲメッセージのメッセージヘッダに含まれるＥｘｐｉｒｅｓ（エクスパイヤ）値を、通常ありえないような値（本実施例においては「１」）に設定する。
高優先で転送された登録要求のパケットは、高優先の設定されていないパケットと比べて、ネットワーク上の中継装置で破棄される可能性が低いため、サーバ２に到達する確率が高い。サーバ２においては、受信した登録要求のＥｘｐｉｒｅｓ（エクスパイヤ）値が「１」に設定されている場合には、優先登録と認識し、端末３への応答（２００ＯＫ及びＡＣＫ）について、ＩＰヘッダ部のＤＳＣＰ値をＥＦ（＝１０１１１０）に設定して送信する（Ｓ１７２、Ｓ１７３）。
サーバ２は、端末３から高優先で転送された登録要求にしたがって、図１２（ｂ）に示すロケーションＤＢ２５に必要な情報を登録する。この登録を行う際、通常はＲＥＧＩＳＴＥＲメッセージのメッセージヘッダに含まれるＥｘｐｉｒｅｓ値をロケーションＤＢ２５の保持時間として使用するが、優先登録の場合には、一旦「優先通話機能を有する旨のメッセージ待ちに係わるタイマ値」で暫定登録を行ったあと、前述のタイマが切れる前に端末３とサーバ２との間で、優先通話機能対応メッセージ及びその応答の送受があった場合に（Ｓ１７４、Ｓ１７５）、「非常時用優先登録タイマ」の値をロケーションＤＢ２５の保持時間とした本登録を行う。優先登録モードにおいては、これらのメッセージ及び応答についても高優先で送受し、ロケーションＤＢ２５に優先通話機能の有無を登録する。
「非常時用優先登録タイマ」の値については、通常時におけるロケーションＤＢ２５の保持時間よりも長い時間を設定しておくのが望ましい。すなわち、高優先モードでの登録処理が必要となる場合の例としては、ネットワークの縮退等がある。このような場合に、通常時と同様の時間間隔で端末３が登録要求を送信した場合には、ネットワークにかかる負荷が大きくなる。
そこで、登録処理によりネットワークにかかる負荷を軽減させるために、通常時よりもタイマ値を大きく設定することとする。サーバ２は、非常時用優先登録タイマが設定されている期間内は、ロケーションＤＢ２５に優先登録した情報を保持し続ける。端末３は、非常時用優先登録タイマの設定期間に応じて、通常時よりも長い期間をおいてから、次回の登録更新のための処理を開始する。これにより、登録処理のために端末３及びサーバ２からネットワークに送出されるパケットによってネットワークにかかる負荷を低減させている。
高優先モードでの登録が完了し、次に更新登録を行うときは、通常時の登録処理を行う。このような高優先モードでの登録後の更新登録では、例えば、上記の非常時用優先登録タイマの３分の２の期間が経過したときに、端末３が、通常時における登録要求を送信することとする。非常時用優先登録タイマの３分の２の期間が経過したときに、サーバ２が高優先の設定されていない登録要求を受信し、図１５に示す通常時における一連の登録処理が正常に終了した場合には、通常時における登録処理に復旧させる。登録処理を正常に終了できなかった場合には、高優先モードでの登録処理を再度行って、非常時優先登録タイマを再度起動する。
図１７は、サーバ２における登録処理を示したフローチャートである。図１７に示す処理は、図３のサーバ２のロケーションＤＢ管理部２６やレジスタ部２７等のＳＩＰ基本機能部において実行される。サーバ２は、図８のステップＳ１６において、サーバ２が登録要求についてのＳＩＰパケットを受信したと判定した場合には、図１７に示す処理を実行する。
まず、ステップＳ４１で、端末３からの登録要求（ＲＥＧＩＳＴＥＲ）の受信を認識する。ステップＳ４２で、受信したパケットのうち、サーバ２が読むことのできるメッセージヘッダのＥｘｐｉｒｅｓの値に基づき、通常時における登録あるいは高優先モードにおける登録のいずれであるかを判定する。
ステップＳ４２で、Ｅｘｐｉｒｅｓが１でない、すなわち通常時における登録と判定した場合には、ステップＳ４３に進み、サーバ２は、端末３に２００ＯＫ及びＡＣＫを返す。ここでは２００ＯＫ及びＡＣＫには特に優先度の設定は行わない。ステップＳ４４で、ロケーションＤＢ２５に必要な情報を登録する。ステップＳ４５で、端末３からの優先通話機能を有する旨のメッセージ待ちに係わるタイマを設定し、メッセージ待ちの状態に入る。タイマで設定した期間内に当該メッセージを受信したか否かに応じて優先通話機能の有無をロケーションＤＢ２５に登録する。そして、ステップＳ４６に進み、メッセージに対するＡＣＫを端末３に返し、処理を終了する。
これに対し、ステップＳ４２において、Ｅｘｐｉｒｅｓが１である、すなわち高優先モードにおける登録であると判定した場合には、ステップＳ４７に進む。
これに対し、ステップＳ４２において、Ｅｘｐｉｒｅｓが１である、すなわち高優先モードにおける登録であると判定した場合には、ステップＳ４７に進む。
ステップＳ４７で、端末３に対して２００ＯＫ及びＡＣＫを高優先で送信し、ステップＳ４８で、端末３からの優先通話機能を有する旨のメッセージ待ちに係わるタイマ値を使ってロケーションＤＢ２５への暫定登録後、優先通話機能対応メッセージ待ちの状態に入る。ここで優先通話機能対応メッセージを受信した場合には、ステップＳ５０に進み、メッセージに対するＡＣＫを高優先で端末３に返し、ステップＳ５１に進む。ステップＳ５１で、「非常時用優先登録タイマ」を使用してロケーションＤＢ２５に本登録を行う。本登録が完了すると、高優先モードでの登録処理を終了する。
ステップＳ４９で、優先通話機能対応メッセージを受信しなかった場合には、優先通話機能付ではない通常端末が、実際にＥｘｐｉｒｅｓの値を１として登録をかけてきたものと判断し、Ｓ４８でロケーションＤＢ２５に暫定登録した内容を廃棄して登録処理を終了する。
ここで「非常時用優先登録タイマ」には、通常時のＲＥＧＩＳＴＥＲメッセージのメッセージヘッダに含まれるＥｘｐｉｒｅｓ値よりも長い待ち期間が設定されている。
このように、端末３の登録処理のために、サーバ２−端末３間で送受するパケットを高優先で転送することにより、特に高優先を設定せずにパケットを転送する場合と比べて、より確実に登録処理を行うことができる。
このように、端末３の登録処理のために、サーバ２−端末３間で送受するパケットを高優先で転送することにより、特に高優先を設定せずにパケットを転送する場合と比べて、より確実に登録処理を行うことができる。
最後に、優先通話の排他処理について説明する。
上記のとおり、本実施形態に係るＩＰ電話システム１では、ＲＦＩＤタグを認識させることにより、あるいはパスワードを端末３に直接入力することのいずれかの方法によっても優先通話が可能である。このため、例えば、ある優先通話者がＲＦＩＤタグを用いて優先通話を行っているときに、このＲＦＩＤタグと対応するパスワードを第三者が別の端末３に入力して、優先通話をかけようとすることも起こりうる。このような場合には、サーバ２は、優先通話管理ＤＢ２３を参照して、後から優先通話をかけようとしたユーザに対して、優先通話が重複する旨通知し、接続を拒否する。
上記のとおり、本実施形態に係るＩＰ電話システム１では、ＲＦＩＤタグを認識させることにより、あるいはパスワードを端末３に直接入力することのいずれかの方法によっても優先通話が可能である。このため、例えば、ある優先通話者がＲＦＩＤタグを用いて優先通話を行っているときに、このＲＦＩＤタグと対応するパスワードを第三者が別の端末３に入力して、優先通話をかけようとすることも起こりうる。このような場合には、サーバ２は、優先通話管理ＤＢ２３を参照して、後から優先通話をかけようとしたユーザに対して、優先通話が重複する旨通知し、接続を拒否する。
図１８及び図１９は、通話の排他処理を説明する図である。まず、図１８においては、ある優先通話者が、端末３ＡにＲＦＩＤタグを認識させ、端末３Ｂに優先通話をかけた場合を示す。優先通話を確立させるまでの手順については、図５等を参照して先に説明したとおりである。
サーバ２は、端末３Ａについて優先通話のＩＮＶＩＴＥを受信してから、ＢＹＥ及びＢＹＥに対する２００ＯＫのメッセージを確認するまでは、通話中と判定する。そして、この間は、サーバ２の優先通話管理ＤＢ２３のうち、「タグＩＤ：ｕｓｒ００１」については、セッション状態に、通話中であることを示す値を保持する。
図１９においては、端末３Ａと端末３Ｂとが通話している間に、他の通話者が、「タグＩＤ：ｕｓｒ００１」について設定されているパスワード「＃００１」を用いて、端末３Ｃから端末３Ｄに優先通話をかけようとした場合を示す。
サーバ２は、優先通話管理ＤＢ２３を参照し、入力されたパスワード（あるいはタグＩＤ）に対応するセッション状態が「通話なし」であるか否かを判定する。図１９に示す例では、パスワード「＃００１」に対応するセッション状態は、先の端末３Ａの優先通話により、「通話中」となっている。このため、「タグＩＤ：ｕｓｒ００１」について正しいパスワード「＃００１」が入力された場合であっても、重複する優先通話と判断し、端末３Ｃに対してその旨通知をし、優先通話を許可しない。
ところで、図２のＶｏＩＰ端末３と、図３のＳＩＰサーバ２は、それぞれ例えば、図２０に示すような情報処理装置（コンピュータ）を用いて構成することができる。図２０の情報処理装置は、ＣＰＵ（中央処理装置）１００１、メモリ１００２、入力装置１００３、出力装置１００４、外部記憶装置１００５、媒体駆動装置１００６、ネットワーク接続装置１００７を備え、それらはバス１００８により互いに接続されている。
メモリ１００２は、例えば、ＲＯＭ（read only memory）、ＲＡＭ（random access memory）等を含み、処理に用いられるプログラムおよびデータを格納する。ＣＰＵ１００１は、メモリ１００２を利用してプログラムを実行することにより、必要な処理を行う。
図２の制御処理部３８や図３の優先通話判定部２２、優先パスワード（ＰＷ）管理データベース（ＤＢ）管理部２４、ロケーションデータベース（ＤＢ）管理部２６及びＳＩＰ基本機能部は、メモリ１００２に格納されたプログラムを実行することにより実現される機能に対応する。
入力装置１００３は、例えば、キーボード、ポインティングデバイス、タッチパネル等であり、優先通話者等のユーザからの指示や情報の入力に用いられる。出力装置１００４は、例えば、ディスプレイ、プリンタ、スピーカ等であり、ユーザ側への問アラームや処理結果等の出力に用いられる。
外部記憶装置１００５は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク装置、テープ装置等である。情報処理装置は、この外部記憶装置１００５に、上記プログラムおよびデータを格納しておき、必要に応じて、それらをメモリ１００２にロードして使用する。
媒体駆動装置１００６は、可搬記録媒体１００９を駆動し、その記録内容にアクセスする。可搬記録媒体１００９は、メモリカード、フレキシブルディスク、ＣＤ−ＲＯＭ（compact disk read only memory ）、光ディスク、光磁気ディスク等の任意のコンピュータ読み取り可能な記録媒体である。ユーザは、この可搬記録媒体１００９に上記プログラムおよびデータを格納しておき、必要に応じて、それらをメモリ１００２にロードして使用する。
ネットワーク接続装置１００７は、ＬＡＮ（local area network）、インターネット等の任意の通信ネットワークに接続され、通信に伴うデータ変換を行う。情報処理装置は、必要に応じて、上記プログラムおよびデータを外部の装置からネットワーク接続装置１００７を介して受け取り、それらをメモリ１００２にロードして使用する。
図２１は、図２０の情報処理装置にプログラムおよびデータを供給することのできるコンピュータ読み取り可能な記録媒体を示している。可搬記録媒体１００９やサーバ１１０１のデータベース１１０３に格納されたプログラムおよびデータは、情報処理装置１１０２のメモリ１００２にロードされる。サーバ１１０１は、そのプログラムおよびデータを搬送する搬送信号を生成し、ネットワーク上の任意の伝送媒体を介して情報処理装置１１０２に送信する。ＣＰＵ１００１は、そのデータを用いてそのプログラムを実行し、必要な処理を行う。
以上説明したように、本実施形態に係るＩＰ電話システム１によれば、優先通話者がＩＰ電話をかけようとした場合には、ＶｏＩＰ端末３は、優先通話者により入力されたトリガ情報を検知する。優先通話者の操作により入力されたトリガ情報を検知すると、セッションを確立するためのパケットに、優先通話者による優先通話であることを示す優先通話識別情報を設定して高優先で送信する。このように、ＶｏＩＰ端末３が、優先通話を許可された特定の通話者の操作により入力された情報、すなわち、優先通話のためのトリガ情報を直接識別することで、通話の優先度を、ＶｏＩＰ端末３のユーザの必要に応じて、動的に変化させることが可能となる。特定の通話者（優先通話者）が操作を行った場合にのみ、トリガ情報を認識して、高優先でのパケットの送信を行うため、特定のユーザによる任意の端末３間の通信を、高優先の状態を維持して行うことが可能となる。言い換えると、優先通話を許可された優先通話者にとっては、より確実にＩＰ電話システム１内の任意の通話先に対して、高品質の確保されている優先通話をかけることができるようになる。
また、ＶｏＩＰ端末３及びサーバ２は、受信したパケットの所定のフィールドに設定されている情報を参照して、優先通話に係わるパケットであることを認識し、高優先で、パケットの転送や受信したパケットに対する応答等を行う。優先通話であることを判断してセッション確立に係わるパケットを高優先で送受するため、ネットワークの縮退時等であっても、より確実に優先通話を確立させることが可能となる。
以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
端末装置、及び該端末装置からの要求を処理するサーバ装置を有し、ネットワークを介して複数の端末装置間でデータを送受する通信システムであって、
前記端末装置は、
優先通信の開始に係わるトリガ情報を検知した場合には、他の端末装置とのセッション確立要求を示すパケットに、優先通信であることを示す優先通信識別情報を設定する設定手段と、
前記設定手段により前記優先通信識別情報を設定されたセッション確立要求を示すパケットについては、前記ネットワーク上で、前記端末装置と前記サーバ装置との間に存在する中継装置において、輻輳状態であっても廃棄確率が低くなるような制御情報を付して送信する送信手段と、
を備え、
前記サーバ装置は、
前記端末装置から前記セッション確立要求を受信すると、前記優先通信識別情報が該セッション確立要求に含まれるか否かを判定する判定手段と、
前記判定手段において、前記優先通信識別情報が含まれると判定された前記セッション確立要求を示すパケットを、前記ネットワーク上で、前記サーバ装置と前記端末装置との間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して、該セッション確立要求に含まれる送信先である端末装置へ送出する送出手段と、
前記判定手段において、前記優先通信識別情報が含まれると判定された前記セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための情報を記憶する記憶手段と、
を備えることを特徴とする通信システム。
（付記２）
ネットワークを介して他の端末装置とデータを送受する端末装置であって、
優先通信の開始に係わるトリガ情報を検知した場合には、前記他の端末装置とのセッション確立要求を示すパケットに、優先通信であることを示す優先通信識別情報を設定する設定手段と、
前記設定手段により前記優先通信識別情報を設定したセッション確立要求を示すパケットについては、前記ネットワーク上で、サーバ装置との間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して送信する送信手段と、
を備えたことを特徴とする端末装置。
（付記３）
自装置以外の端末装置から受信したセッション確立要求に前記優先通信識別情報が含まれるか否かを判定し、該優先通信識別情報が含まれると判定した場合には、該セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための情報を該セッション確立要求から読み出して記憶装置に記憶させるとともに、前記送信手段は、該セッション確立要求に対する応答に、該セッションを他のセッションと識別するための情報を設定し、前記制御情報を付して送信する
ことを特徴とする付記２記載の端末装置。
（付記４）
前記トリガ情報には、優先通信を許可された優先通信者による前記端末装置の操作であることを示す情報が含まれる
ことを特徴とする付記２記載の端末装置。
（付記５）
前記セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための情報として、自装置と通信相手の前記他の端末装置間のダイアログを識別するダイアログ識別情報を使用する
ことを特徴とする付記２記載の端末装置。
（付記６）
ネットワークを介してデータを送受する端末装置からの要求を処理するサーバ装置あって、
端末装置からセッション確立要求を受信すると、優先通信であることを示す優先通信識別情報が該セッション確立要求に含まれるか否かを判定する判定手段と、
前記判定手段において、前記優先通信識別情報が含まれると判定された前記セッション確立要求を示すパケットを、前記ネットワーク上で、前記端末装置との間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して、該セッション確立要求に含まれる送信先である端末装置へ送出する送出手段と、
前記判定手段において、前記優先通信識別情報が含まれると判定された前記セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための情報を記憶する記憶手段と、
を備えたことを特徴とするサーバ装置。
（付記７）
コンピュータをネットワークを介して他の端末装置とデータを送受する端末装置として動作させるためのプログラムであって、
優先通信の開始に係わるトリガ情報を検知した場合には、他の端末装置とのセッション確立要求を示すパケットに、優先通信であることを示す優先通信識別情報を設定し、
前記優先通信識別情報を設定した前記セッション確立要求を示すパケットについては、前記ネットワーク上で、前記端末装置とサーバ装置との間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して送信する、
処理をコンピュータに実行させることを特徴とするプログラム。
（付記８）
自装置以外の端末装置から受信したセッション確立要求に前記優先通信識別情報が含まれるか否かを判定し、
前記優先通信識別情報が含まれると判定した場合には、前記セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための情報を該セッション確立要求から読み出して記憶装置に記憶させるとともに、該セッション確立要求に対する応答に該セッションを他のセッションと識別するための情報を設定して、前記制御情報を付して送信する、
処理を更にコンピュータに実行させることを特徴とする付記７記載のプログラム。
（付記９）
前記トリガ情報には、優先通信を許可された優先通信者による前記端末装置の操作であることを示す情報が含まれる
ことを特徴とする付記７記載のプログラム。
（付記１０）
前記セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための情報として、自装置と通信相手の前記他の端末装置間のダイアログを識別するダイアログ識別情報を使用する
ことを特徴とする付記７記載のプログラム。
（付記１１）
優先通信を許可されている優先通信者を認証するための認証情報が新たに入力されたことを検知すると、該認証情報及び該認証情報が対応付けられている前記優先通信識別情報を前記サーバ装置に対して通知し、
前記サーバ装置からの同期指示があった場合には、該指示にしたがって、前記優先通信識別情報と前記新たに入力された認証情報とを対応付けて記憶手段に記憶させる
処理を更にコンピュータに実行させ、
所定期間内に前記サーバ装置から受信した同期の指示に前記制御情報が付されている場合には、上記の同期の処理に係わるパケットについては、該サーバ装置に前記制御情報を付して送信する
ことを特徴とする付記７記載のプログラム。
（付記１２）
前記制御情報を付さずに送信した登録要求に対し、前記サーバ装置からの応答を所定の期間内に受信できなかった場合には、該登録要求に係わるパケットに待ち期間切れを示す値を設定して前記制御情報を付して送信し、
前記待ち期間切れを示す値を設定して前記制御情報を付して送信した登録要求に基づき登録処理が完了した場合には、該制御情報の付されていない登録要求に基づき登録処理が完了した場合に次に登録要求を送信するまでの期間よりも長い期間をおいて、優先度を設定しない登録要求を送信し、
前記制御情報の付されていない登録要求に基づき登録処理を完了できなかった場合には、前記待ち期間切れを示す値を設定した登録要求の送信を継続する
処理を更にコンピュータに実行させることを特徴とする付記７記載のプログラム。
（付記１３）
コンピュータをネットワークを介してデータを送受する端末装置からの要求を処理するサーバ装置として動作させるためのプログラムであって、
前記端末装置からセッション確立要求を受信すると、優先通信であることを示す優先通信識別情報が該セッション確立要求に含まれるか否かを判定し、
前記優先通信識別情報が含まれると判定した場合には、該優先通信識別情報が含まれると判定された前記セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための制御情報を、該セッション確立要求から読み出して記憶させるとともに、該セッション確立要求を示すパケットを、前記ネットワーク上で、前記端末装置と前記サーバ装置の間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して、該セッション確立要求に含まれる送信先である端末装置へ送出する
処理をコンピュータに実行させることを特徴とするプログラム。
（付記１４）
優先通信を許可されている優先通信者を認証するための認証情報を前記端末装置から通知された場合には、該通知された認証情報を該優先通信識別情報と対応付けて記憶手段に記憶させ、
前記記憶手段と、前記端末装置及び他の端末装置の記憶手段とを同期させるための指示を該端末装置及び他の端末装置宛に送出する
処理を更にコンピュータに実行させ、
前記同期処理が所定の期間内に完了しない場合には、前記端末装置及び他の端末装置に対する上記の同期の指示に係わるパケットを、前記制御情報を付して送出する
ことを特徴とする付記１３記載のプログラム。
（付記１５）
前記端末装置から受信した登録要求に待ち期間切れを示す値が設定されている場合には、該端末装置に送信する該登録要求の応答を、前記制御情報を付して送出し、
次に登録要求を受信するまでの待ち期間を、前記制御情報が付されていない登録要求を処理した場合の待ち期間よりも長く設定し、
前記設定した期間内に前記端末装置から前記制御情報の付されていない登録要求を受信し、該登録要求に基づく登録処理が完了した場合には、前記待ち期間として、前記制御情報が付されていない登録要求を処理した場合の値に変更する
処理を更にコンピュータに実行させることを特徴とする付記１３記載のプログラム。
（付記１６）
前記端末装置の送信手段が前記パケットに付する制御情報、および前記サーバ装置の送出手段は、前記パケットに付する制御情報としてＥＦ値を設定することを特徴とする付記１記載の通信システム。
（付記１）
端末装置、及び該端末装置からの要求を処理するサーバ装置を有し、ネットワークを介して複数の端末装置間でデータを送受する通信システムであって、
前記端末装置は、
優先通信の開始に係わるトリガ情報を検知した場合には、他の端末装置とのセッション確立要求を示すパケットに、優先通信であることを示す優先通信識別情報を設定する設定手段と、
前記設定手段により前記優先通信識別情報を設定されたセッション確立要求を示すパケットについては、前記ネットワーク上で、前記端末装置と前記サーバ装置との間に存在する中継装置において、輻輳状態であっても廃棄確率が低くなるような制御情報を付して送信する送信手段と、
を備え、
前記サーバ装置は、
前記端末装置から前記セッション確立要求を受信すると、前記優先通信識別情報が該セッション確立要求に含まれるか否かを判定する判定手段と、
前記判定手段において、前記優先通信識別情報が含まれると判定された前記セッション確立要求を示すパケットを、前記ネットワーク上で、前記サーバ装置と前記端末装置との間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して、該セッション確立要求に含まれる送信先である端末装置へ送出する送出手段と、
前記判定手段において、前記優先通信識別情報が含まれると判定された前記セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための情報を記憶する記憶手段と、
を備えることを特徴とする通信システム。
（付記２）
ネットワークを介して他の端末装置とデータを送受する端末装置であって、
優先通信の開始に係わるトリガ情報を検知した場合には、前記他の端末装置とのセッション確立要求を示すパケットに、優先通信であることを示す優先通信識別情報を設定する設定手段と、
前記設定手段により前記優先通信識別情報を設定したセッション確立要求を示すパケットについては、前記ネットワーク上で、サーバ装置との間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して送信する送信手段と、
を備えたことを特徴とする端末装置。
（付記３）
自装置以外の端末装置から受信したセッション確立要求に前記優先通信識別情報が含まれるか否かを判定し、該優先通信識別情報が含まれると判定した場合には、該セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための情報を該セッション確立要求から読み出して記憶装置に記憶させるとともに、前記送信手段は、該セッション確立要求に対する応答に、該セッションを他のセッションと識別するための情報を設定し、前記制御情報を付して送信する
ことを特徴とする付記２記載の端末装置。
（付記４）
前記トリガ情報には、優先通信を許可された優先通信者による前記端末装置の操作であることを示す情報が含まれる
ことを特徴とする付記２記載の端末装置。
（付記５）
前記セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための情報として、自装置と通信相手の前記他の端末装置間のダイアログを識別するダイアログ識別情報を使用する
ことを特徴とする付記２記載の端末装置。
（付記６）
ネットワークを介してデータを送受する端末装置からの要求を処理するサーバ装置あって、
端末装置からセッション確立要求を受信すると、優先通信であることを示す優先通信識別情報が該セッション確立要求に含まれるか否かを判定する判定手段と、
前記判定手段において、前記優先通信識別情報が含まれると判定された前記セッション確立要求を示すパケットを、前記ネットワーク上で、前記端末装置との間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して、該セッション確立要求に含まれる送信先である端末装置へ送出する送出手段と、
前記判定手段において、前記優先通信識別情報が含まれると判定された前記セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための情報を記憶する記憶手段と、
を備えたことを特徴とするサーバ装置。
（付記７）
コンピュータをネットワークを介して他の端末装置とデータを送受する端末装置として動作させるためのプログラムであって、
優先通信の開始に係わるトリガ情報を検知した場合には、他の端末装置とのセッション確立要求を示すパケットに、優先通信であることを示す優先通信識別情報を設定し、
前記優先通信識別情報を設定した前記セッション確立要求を示すパケットについては、前記ネットワーク上で、前記端末装置とサーバ装置との間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して送信する、
処理をコンピュータに実行させることを特徴とするプログラム。
（付記８）
自装置以外の端末装置から受信したセッション確立要求に前記優先通信識別情報が含まれるか否かを判定し、
前記優先通信識別情報が含まれると判定した場合には、前記セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための情報を該セッション確立要求から読み出して記憶装置に記憶させるとともに、該セッション確立要求に対する応答に該セッションを他のセッションと識別するための情報を設定して、前記制御情報を付して送信する、
処理を更にコンピュータに実行させることを特徴とする付記７記載のプログラム。
（付記９）
前記トリガ情報には、優先通信を許可された優先通信者による前記端末装置の操作であることを示す情報が含まれる
ことを特徴とする付記７記載のプログラム。
（付記１０）
前記セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための情報として、自装置と通信相手の前記他の端末装置間のダイアログを識別するダイアログ識別情報を使用する
ことを特徴とする付記７記載のプログラム。
（付記１１）
優先通信を許可されている優先通信者を認証するための認証情報が新たに入力されたことを検知すると、該認証情報及び該認証情報が対応付けられている前記優先通信識別情報を前記サーバ装置に対して通知し、
前記サーバ装置からの同期指示があった場合には、該指示にしたがって、前記優先通信識別情報と前記新たに入力された認証情報とを対応付けて記憶手段に記憶させる
処理を更にコンピュータに実行させ、
所定期間内に前記サーバ装置から受信した同期の指示に前記制御情報が付されている場合には、上記の同期の処理に係わるパケットについては、該サーバ装置に前記制御情報を付して送信する
ことを特徴とする付記７記載のプログラム。
（付記１２）
前記制御情報を付さずに送信した登録要求に対し、前記サーバ装置からの応答を所定の期間内に受信できなかった場合には、該登録要求に係わるパケットに待ち期間切れを示す値を設定して前記制御情報を付して送信し、
前記待ち期間切れを示す値を設定して前記制御情報を付して送信した登録要求に基づき登録処理が完了した場合には、該制御情報の付されていない登録要求に基づき登録処理が完了した場合に次に登録要求を送信するまでの期間よりも長い期間をおいて、優先度を設定しない登録要求を送信し、
前記制御情報の付されていない登録要求に基づき登録処理を完了できなかった場合には、前記待ち期間切れを示す値を設定した登録要求の送信を継続する
処理を更にコンピュータに実行させることを特徴とする付記７記載のプログラム。
（付記１３）
コンピュータをネットワークを介してデータを送受する端末装置からの要求を処理するサーバ装置として動作させるためのプログラムであって、
前記端末装置からセッション確立要求を受信すると、優先通信であることを示す優先通信識別情報が該セッション確立要求に含まれるか否かを判定し、
前記優先通信識別情報が含まれると判定した場合には、該優先通信識別情報が含まれると判定された前記セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための制御情報を、該セッション確立要求から読み出して記憶させるとともに、該セッション確立要求を示すパケットを、前記ネットワーク上で、前記端末装置と前記サーバ装置の間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して、該セッション確立要求に含まれる送信先である端末装置へ送出する
処理をコンピュータに実行させることを特徴とするプログラム。
（付記１４）
優先通信を許可されている優先通信者を認証するための認証情報を前記端末装置から通知された場合には、該通知された認証情報を該優先通信識別情報と対応付けて記憶手段に記憶させ、
前記記憶手段と、前記端末装置及び他の端末装置の記憶手段とを同期させるための指示を該端末装置及び他の端末装置宛に送出する
処理を更にコンピュータに実行させ、
前記同期処理が所定の期間内に完了しない場合には、前記端末装置及び他の端末装置に対する上記の同期の指示に係わるパケットを、前記制御情報を付して送出する
ことを特徴とする付記１３記載のプログラム。
（付記１５）
前記端末装置から受信した登録要求に待ち期間切れを示す値が設定されている場合には、該端末装置に送信する該登録要求の応答を、前記制御情報を付して送出し、
次に登録要求を受信するまでの待ち期間を、前記制御情報が付されていない登録要求を処理した場合の待ち期間よりも長く設定し、
前記設定した期間内に前記端末装置から前記制御情報の付されていない登録要求を受信し、該登録要求に基づく登録処理が完了した場合には、前記待ち期間として、前記制御情報が付されていない登録要求を処理した場合の値に変更する
処理を更にコンピュータに実行させることを特徴とする付記１３記載のプログラム。
（付記１６）
前記端末装置の送信手段が前記パケットに付する制御情報、および前記サーバ装置の送出手段は、前記パケットに付する制御情報としてＥＦ値を設定することを特徴とする付記１記載の通信システム。
１ ＩＰ電話システム
２ ＳＩＰサーバ（サーバ）
３ ＶｏＩＰ端末（端末）
２１ ＬＡＮインターフェース部
２２ 優先通話判定部
２３ 優先通話管理データベース（ＤＢ）
２４ 優先パスワード（ＰＷ）管理データベース（ＤＢ）管理部
２５ ロケーションデータベース（ＤＢ）
２６ ロケーションデータベース（ＤＢ）管理部
２７ レジスタ部
２８ プロキシ部
２９ リダイレクト部
３０ 認証部
３１ ＲＦＩＤ受信部
３２ オンフック／オフフック検知部
３３ 操作部
３４ ディスプレイ表示部
３５ 優先パスワード（ＰＷ）管理データベース（ＤＢ）
３６ ハンドセット部
３７ 音声コーデック部
３８ 制御処理部
３９ ＬＡＮインターフェース部
２ ＳＩＰサーバ（サーバ）
３ ＶｏＩＰ端末（端末）
２１ ＬＡＮインターフェース部
２２ 優先通話判定部
２３ 優先通話管理データベース（ＤＢ）
２４ 優先パスワード（ＰＷ）管理データベース（ＤＢ）管理部
２５ ロケーションデータベース（ＤＢ）
２６ ロケーションデータベース（ＤＢ）管理部
２７ レジスタ部
２８ プロキシ部
２９ リダイレクト部
３０ 認証部
３１ ＲＦＩＤ受信部
３２ オンフック／オフフック検知部
３３ 操作部
３４ ディスプレイ表示部
３５ 優先パスワード（ＰＷ）管理データベース（ＤＢ）
３６ ハンドセット部
３７ 音声コーデック部
３８ 制御処理部
３９ ＬＡＮインターフェース部
Claims (8)
- 端末装置、及び該端末装置からの要求を処理するサーバ装置を有し、ネットワークを介して複数の端末装置間でデータを送受する通信システムであって、
前記端末装置は、
優先通信の開始に係わるトリガ情報を検知した場合には、他の端末装置とのセッション確立要求を示すパケットに、優先通信であることを示す優先通信識別情報を設定する設定手段と、
前記設定手段により前記優先通信識別情報を設定されたセッション確立要求を示すパケットについては、前記ネットワーク上で、前記端末装置と前記サーバ装置との間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して送信する送信手段と、
を備え、
前記サーバ装置は、
前記端末装置から前記セッション確立要求を受信すると、前記優先通信識別情報が該セッション確立要求に含まれるか否かを判定する判定手段と、
前記判定手段において、前記優先通信識別情報が含まれると判定された前記セッション確立要求を示すパケットを、前記ネットワーク上で、前記サーバ装置と前記端末装置との間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して、該セッション確立要求に含まれる送信先である端末装置へ送出する送出手段と、
前記判定手段において、前記優先通信識別情報が含まれると判定された前記セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための情報を記憶する記憶手段と、
を備えたことを特徴とする通信システム。 - ネットワークを介して他の端末装置とデータを送受する端末装置であって、
優先通信の開始に係わるトリガ情報を検知した場合には、前記他の端末装置とのセッション確立要求を示すパケットに、優先通信であることを示す優先通信識別情報を設定する設定手段と、
前記設定手段により前記優先通信識別情報を設定したセッション確立要求を示すパケットについては、前記ネットワーク上で、サーバ装置との間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して送信する送信手段と、
を備えたことを特徴とする端末装置。 - 自装置以外の端末装置から受信したセッション確立要求に前記優先通信識別情報が含まれるか否かを判定し、該優先通信識別情報が含まれると判定した場合には、該セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための情報を該セッション確立要求から読み出して記憶装置に記憶させるとともに、前記送信手段は、該セッション確立要求に対する応答に、該セッションを他のセッションと識別するための情報を設定し、前記制御情報を付して送信する
ことを特徴とする請求項２記載の端末装置。 - 前記トリガ情報には、優先通信を許可された優先通信者による前記端末装置の操作であることを示す情報が含まれる
ことを特徴とする請求項２記載の端末装置。 - 前記セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための情報として、自装置と通信相手の前記他の端末装置間のダイアログを識別するダイアログ識別情報を使用する
ことを特徴とする請求項２記載の端末装置。 - ネットワークを介してデータを送受する端末装置からの要求を処理するサーバ装置あって、
端末装置からセッション確立要求を受信すると、優先通信であることを示す優先通信識別情報が該セッション確立要求に含まれるか否かを判定する判定手段と、
前記判定手段において、前記優先通信識別情報が含まれると判定された前記セッション確立要求を示すパケットを、前記ネットワーク上で、前記端末装置との間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して、該セッション確立要求に含まれる送信先である端末装置へ送出する送出手段と、
前記判定手段において、前記優先通信識別情報が含まれると判定された前記セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための情報を記憶する記憶手段と、
を備えたことを特徴とするサーバ装置。 - コンピュータをネットワークを介して他の端末装置とデータを送受する端末装置として動作させるためのプログラムであって、
優先通信の開始に係わるトリガ情報を検知した場合には、他の端末装置とのセッション確立要求を示すパケットに、優先通信であることを示す優先通信識別情報を設定し、
前記優先通信識別情報を設定した前記セッション確立要求を示すパケットについては、前記ネットワーク上で、前記端末装置とサーバ装置との間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して送信する、
処理をコンピュータに実行させることを特徴とするプログラム。 - コンピュータをネットワークを介してデータを送受する端末装置からの要求を処理するサーバ装置として動作させるためのプログラムであって、
前記端末装置からセッション確立要求を受信すると、優先通信であることを示す優先通信識別情報が該セッション確立要求に含まれるか否かを判定し、
前記優先通信識別情報が含まれると判定した場合には、該優先通信識別情報が含まれると判定された前記セッション確立要求に基づいて開始される一連のセッションを他のセッションと識別するための情報を、該セッション確立要求から読み出して記憶させるとともに、該セッション確立要求を示すパケットを、前記ネットワーク上で、前記端末装置と前記サーバ装置の間に存在する中継装置において、輻輳状態であっても破棄確率が低くなるような制御情報を付して、該セッション確立要求に含まれる送信先である端末装置へ送出する
処理をコンピュータに実行させることを特徴とするプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2009066930A JP5532641B2 (ja) | 2009-03-18 | 2009-03-18 | 通信システム、サーバ装置、端末装置及びプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2009066930A JP5532641B2 (ja) | 2009-03-18 | 2009-03-18 | 通信システム、サーバ装置、端末装置及びプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2010220102A true JP2010220102A (ja) | 2010-09-30 |
| JP5532641B2 JP5532641B2 (ja) | 2014-06-25 |
Family
ID=42978417
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2009066930A Expired - Fee Related JP5532641B2 (ja) | 2009-03-18 | 2009-03-18 | 通信システム、サーバ装置、端末装置及びプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP5532641B2 (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2013118578A (ja) * | 2011-12-05 | 2013-06-13 | Oki Electric Ind Co Ltd | 音声通信装置及びプログラム |
| JP2014511072A (ja) * | 2011-03-15 | 2014-05-01 | アルカテル−ルーセント | Ｓｉｐを用いた企業ネットワークの生存性のためのバックアップｓｉｐサーバ |
| WO2014187305A1 (zh) * | 2013-05-20 | 2014-11-27 | 电信科学技术研究院 | 一种邻近组通信方法及终端 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005278028A (ja) * | 2004-03-26 | 2005-10-06 | Matsushita Electric Ind Co Ltd | 通信装置およびシステム |
| JP2006186811A (ja) * | 2004-12-28 | 2006-07-13 | Takanao Handa | 災害防災支援情報電話および災害防災支援情報システム |
| WO2007127128A2 (en) * | 2006-04-27 | 2007-11-08 | Lucent Technologies Inc. | Method and apparatus for sip message prioritization |
| JP2008034947A (ja) * | 2006-07-26 | 2008-02-14 | Fujitsu Ltd | 負荷分散型呼処理システム |
-
2009
- 2009-03-18 JP JP2009066930A patent/JP5532641B2/ja not_active Expired - Fee Related
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005278028A (ja) * | 2004-03-26 | 2005-10-06 | Matsushita Electric Ind Co Ltd | 通信装置およびシステム |
| JP2006186811A (ja) * | 2004-12-28 | 2006-07-13 | Takanao Handa | 災害防災支援情報電話および災害防災支援情報システム |
| WO2007127128A2 (en) * | 2006-04-27 | 2007-11-08 | Lucent Technologies Inc. | Method and apparatus for sip message prioritization |
| JP2008034947A (ja) * | 2006-07-26 | 2008-02-14 | Fujitsu Ltd | 負荷分散型呼処理システム |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2014511072A (ja) * | 2011-03-15 | 2014-05-01 | アルカテル−ルーセント | Ｓｉｐを用いた企業ネットワークの生存性のためのバックアップｓｉｐサーバ |
| JP2013118578A (ja) * | 2011-12-05 | 2013-06-13 | Oki Electric Ind Co Ltd | 音声通信装置及びプログラム |
| WO2014187305A1 (zh) * | 2013-05-20 | 2014-11-27 | 电信科学技术研究院 | 一种邻近组通信方法及终端 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP5532641B2 (ja) | 2014-06-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3855909B2 (ja) | ポリシ設定可能なピアツーピア通信システム | |
| JP5332544B2 (ja) | 呼制御装置、呼制御システム、呼制御方法及びコンピュータプログラム | |
| JP4673369B2 (ja) | ハイブリッド通信ネットワークにおいて相関手段を提供する方法および装置 | |
| JP3853788B2 (ja) | ユニバーサル・モバイル遠隔通信システムのマルチメディア使用可能ユニットの間で通信される情報を削減するためのシステムおよび方法 | |
| JP4392029B2 (ja) | 通信ネットワークにおけるｉｐパケット中継方法 | |
| US8606936B2 (en) | Communication system, session control management server and session control method | |
| US20090313386A1 (en) | Communication apparatus, communication method and communication system | |
| KR20070010693A (ko) | Ｓｉｐ를 이용한 통신 시스템에서 호 해제 요청/응답메시지를 이용한 네트워크 상태 관리 방법 | |
| WO2008022596A1 (fr) | Procédé, système et appareil pour la remise de sms en mode de partage dynamique | |
| JP2005229273A (ja) | サーババックアップ装置 | |
| JP5532641B2 (ja) | 通信システム、サーバ装置、端末装置及びプログラム | |
| RU2374777C2 (ru) | Обработка начальных мультимедийных данных i | |
| WO2024088233A1 (zh) | 异常网络服务恢复方法、装置、电子设备和服务器 | |
| US7899058B2 (en) | Using a hash value as a pointer to an application class in a communications device | |
| ES2731691T3 (es) | Tratamiento de transferencia de comunicación en modo SIP | |
| CN1988546A (zh) | 获取会话起始协议消息传输路径的方法及*** | |
| KR100825170B1 (ko) | 무선 통신 단말기 | |
| WO2008095430A1 (fr) | Procédé et système pour protéger un organisme médiatique contre une attaque de pirates informatiques | |
| US20090122786A1 (en) | Signaling method in ip telephone system , ip telephone system, and ip telephone device | |
| JP5609519B2 (ja) | Ｓｉｐ機器 | |
| JP4480698B2 (ja) | 通信制御装置，通信制御方法ならびに通信制御用プログラム | |
| JP4798785B2 (ja) | Ｓｉｐ端末装置におけるピアツーピア接続の接続規制方法 | |
| JP2008236470A (ja) | Ｉｐ電話端末及びｉｐ電話システム | |
| JP2005286944A (ja) | ネットワーク通信装置及びその通信方法 | |
| JP2010130458A (ja) | 通信システム、加入者系サーバ、中継系サーバ、通信方法、加入者系サーバの制御方法、中継系サーバの制御方法、及びプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20111107 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20121023 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20121030 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20121220 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20130924 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20140401 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5532641 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20140414 |
|
| LAPS | Cancellation because of no payment of annual fees |