リアルタイム通信システム、リアルタイム通信方法、およびリアルタイム通信プログラム
【課題】 帯域を節約し、柔軟性を高める。
【解決手段】 第１の通信端末と第２の通信端末のあいだで呼を設定してリアルタイム通信を行っている状態で、第２の通信端末のほうから保留を指示してリアルタイム通信を一時中断し、保留解除するまでのあいだに、保留されたほうの第１の通信端末のユーザインタフェースを介して、リアルタイム通信による信号の替わりに所定の保留信号を出力するリアルタイム通信システムにおいて、第２の通信端末以外の保留信号源通信端末、または第１の通信端末は、第２の通信端末から保留の指示が出されたことを検出する保留指示検出部と、保留指示検出部が第２の通信端末から保留の指示が出されたことを検出すると、保留信号を供給する保留信号供給部とを備える。
【解決手段】 第１の通信端末と第２の通信端末のあいだで呼を設定してリアルタイム通信を行っている状態で、第２の通信端末のほうから保留を指示してリアルタイム通信を一時中断し、保留解除するまでのあいだに、保留されたほうの第１の通信端末のユーザインタフェースを介して、リアルタイム通信による信号の替わりに所定の保留信号を出力するリアルタイム通信システムにおいて、第２の通信端末以外の保留信号源通信端末、または第１の通信端末は、第２の通信端末から保留の指示が出されたことを検出する保留指示検出部と、保留指示検出部が第２の通信端末から保留の指示が出されたことを検出すると、保留信号を供給する保留信号供給部とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はリアルタイム通信システム、リアルタイム通信方法、およびリアルタイム通信プログラムに関し、例えば、ＶｏＩＰ技術を利用したＩＰ電話機で保留音を出力させる場合など適用して好適なものである。
【背景技術】
【０００２】
従来のＩＰ電話機で保留を行う場合の動作の流れは、図２の動作シーケンスに示す通りである。図２の動作シーケンスは、ＩＰ網などのネットワークを経由して端末１１，１２，ＳＩＰ（セッション開始プロトコル）サーバ１０間で行われる信号のやり取りを示し、Ｓ１０〜Ｓ１９の各ステップを備えている。
【０００３】
ＩＰ電話機である端末１１と１２のあいだで、すでに呼（セッション）が確立されて、各端末１１，１２のユーザＵ１，Ｕ２が双方向で音声通話を行っている（Ｓ１０）。
【０００４】
このとき、例えば第３の端末（図示せず）から端末１２に着信すると、それを契機として、ユーザＵ２が端末１２の保留ボタン（自己保留ボタン）を押下し、当該端末１２からｒｅ−ＩＮＶＩＴＥメッセージが送信される（Ｓ１１）。以降のステップＳ１２〜Ｓ１８では、ＳＩＰプロトコルで定められた保留時の呼制御メッセージがやり取りされ、端末１１が正常に保留を受付けたことを確認したあとで、端末１２から保留音が送信される（Ｓ１９）。
【０００５】
この保留音は、前記ステップＳ１０における双方向の音声通話のうち、ユーザＵ２の発話した音声の内容をユーザＵ１に伝えるための音声通話と同様、端末１２からＩＰパケットで送信され、前記ネットワークを経由して端末１１まで届けられる。当該保留音を聴取したユーザＵ１は、保留状態になったことを認識し、保留解除によってユーザＵ２との音声通話が再開されるのを待つことができる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ところが、図２のような動作を行う従来の通信システムの場合、保留音まで、ユーザＵ２が発話した音声と同様にＩＰパケットに収容してネットワーク経由で伝送させることになるため、ネットワークの帯域を無駄に消費してしまう。
【０００７】
また、保留音の送信元が端末１２であるため、保留音の内容に、聴取するユーザＵ１の好みを反映することが困難で、ネットワークの帯域が十分に広くない場合などにはユーザＵ１が聴取する保留音の音質を高めることも難しいから、柔軟性が低いといえる。
【課題を解決するための手段】
【０００８】
かかる課題を解決するために、第１の本発明では、第１の通信端末と第２の通信端末のあいだで呼を設定してリアルタイム通信を行っている状態で、第２の通信端末のほうから保留を指示して当該リアルタイム通信を一時中断し、保留解除するまでのあいだに、保留されたほうの第１の通信端末のユーザインタフェースを介して、前記リアルタイム通信による信号の替わりに所定の保留信号を出力するリアルタイム通信システムにおいて、（１）前記第２の通信端末以外の保留信号源通信端末、または前記第１の通信端末は、（２）前記第２の通信端末から保留の指示が出されたことを検出する保留指示検出部と、（３）当該保留指示検出部が前記第２の通信端末から保留の指示が出されたことを検出すると、前記保留信号を供給する保留信号供給部とを備えたことを特徴とする。
【０００９】
また、第２の本発明では、第１の通信端末と第２の通信端末のあいだで呼を設定してリアルタイム通信を行っている状態で、第２の通信端末のほうから保留を指示して当該リアルタイム通信を一時中断し、保留解除するまでのあいだに、保留されたほうの第１の通信端末のユーザインタフェースを介して、前記リアルタイム通信による信号の替わりに所定の保留信号を出力するリアルタイム通信方法において、（１）前記第２の通信端末以外の保留信号源通信端末、または前記第１の通信端末では、（２）保留指示検出部が、前記第２の通信端末から保留の指示が出されたことを検出し、（３）当該保留指示検出部が前記第２の通信端末から保留の指示が出されたことを検出すると、保留信号供給部が、前記保留信号を供給することを特徴とする。
【００１０】
さらに、第３の本発明では、第１の通信端末と第２の通信端末のあいだで呼を設定してリアルタイム通信を行っている状態で、第２の通信端末のほうから保留を指示して当該リアルタイム通信を一時中断し、保留解除するまでのあいだに、保留されたほうの第１の通信端末のユーザインタフェースを介して、前記リアルタイム通信による信号の替わりに所定の保留信号を出力するリアルタイム通信プログラムにおいて、（１）前記第２の通信端末以外の保留信号源通信端末、または前記第１の通信端末では、コンピュータに、（２）前記第２の通信端末から保留の指示が出されたことを検出する保留指示検出機能と、（３）当該保留指示検出機能が前記第２の通信端末から保留の指示が出されたことを検出すると、前記保留信号を供給する保留信号供給機能とを実現させることを特徴とする。
【発明の効果】
【００１１】
本発明によれば、帯域を節約し、柔軟性を高めることができる。
【発明を実施するための最良の形態】
【００１２】
（Ａ）実施形態
以下、本発明にかかるリアルタイム通信システム、リアルタイム通信方法、およびリアルタイム通信プログラムを、ＶｏＩＰ通信システムに適用した場合を例に、実施形態について説明する。
【００１３】
（Ａ−１）実施形態の構成
本実施形態にかかるＶｏＩＰ通信システム２０の全体構成例を図１に示す。
【００１４】
図１において、当該ＶｏＩＰ通信システム２０は、ネットワーク２１と、端末２２，２３と、音源サーバ２４と、ＳＩＰサーバ２５とを備えている。
【００１５】
このうちネットワーク２１は、インターネットなどであってもよいが、ここではＩＰ網であるものとする。ＩＰ網はＯＳＩ参照モデルのネットワーク層でＩＰプロトコルを用いるネットワークである点でインターネットと同じであるが、１つの通信事業者が管理運営するネットワークであるので、インターネットに比べて、高い通信品質を保証しやすい。
【００１６】
端末２２，２３はともにＩＰ電話機である。端末２２，２３のうち少なくとも端末２２は、本実施形態で特徴的な端末である。端末２３のほうは、端末２２と同じ構成を持つ端末である場合と、端末２２と異なり、既存のＩＰ電話機である場合があるものとする。また、以下の説明では、主として、ユーザＵ１１とＵ１２がＶｏＩＰ通信による音声通話を行っている途中で、端末２３側から保留を指示して、当該音声通話を一時中断するケースを想定する。
【００１７】
端末２２はユーザＵ１１によって利用され、端末２３はユーザＵ１２によって利用される。
【００１８】
ＳＩＰサーバ２５は、呼制御用のサーバである。呼制御プロトコルとしてはＳＩＰプロトコル以外のプロトコルを使用することも可能であるが、ここでは、ＳＩＰプロトコルを想定する。
【００１９】
ユーザＵ１１とＵ１２がＶｏＩＰ通信による音声通話を開始する前の呼設定のための呼制御の過程では、端末２２，２３間の呼制御メッセージのやり取りにＳＩＰサーバ２５が介在するが、保留の場合にも端末２２，２３間で呼制御メッセージのやり取りが行われ、そのやり取りにＳＩＰサーバ２５が介在することになる。
【００２０】
ＳＩＰサーバ２５の機能は基本的に既存のＳＩＰサーバと同じであってよい。
【００２１】
音源サーバ２４は、端末（ここでは、２２）とセッションを確立したとき、その端末に保留音情報（ユーザＵ１１が聴取する保留音ＨＡ１に対応）を届けるためのサーバである。
【００２２】
次に、本実施形態で特徴的な前記端末２２は、例えば、図３に示すような内部構成を備える。
【００２３】
（Ａ−１−１）端末２２の内部構成例
図３において、当該端末２２は、通信部３０と、制御部３１と、操作部３２と、記憶部３３と、呼制御部３４と、ローカル保留音発生部３５と、リモート保留音検出部３６と、音源選択部３７と、リモート保留音発生部３８と、送受話部３９とを備えている。
【００２４】
このうち通信部３０は端末２２が通信を行う際に機能する部分である。具体的には、呼制御メッセージの通信、音声情報の通信、前記保留音情報の通信などにおいて、当該通信部３０が機能する。ただし、当該端末２２は、ユーザＵ１１に聴取させる保留音ＨＡ１に対応する保留音情報の発生源を端末２３，音源サーバ２４，端末２２自身が備える前記ローカル保留音発生部３５の３つのうちから選ぶことができるので、保留音情報の通信で当該通信部３０が機能するのは、端末２３または音源サーバ２４を選んだケースである。
【００２５】
制御部３１は、ハードウエア的には当該端末２２のＣＰＵ（中央処理装置）に相当し、ソフトウエア的にはＯＳ（オペレーティングシステム）などの各種プログラムに相当し得る部分である。当該制御部３１はＶｏＩＰに対応する処理を実行するＶｏＩＰ対応機能を備える。制御部３１の当該ＶｏＩＰ対応機能は、ユーザＵ１１が発話した音声に対応する音声情報を処理するときには音声情報の符号化、符号化された音声情報をＩＰパケットに収容する処理などを実行し、反対に、ユーザＵ１２が発話した音声に対応する音声情報を収容したＩＰパケットを受信したときには、符号化されている当該音声情報をＩＰパケットから取り出して復号する処理などを実行する。
【００２６】
保留音ＨＡ１に対応する保留音情報が、端末２３または音源サーバ２４から供給される場合、当該保留音情報も、前記ユーザＵ１２が発話した音声に対応する音声情報と同様、符号化された状態でＩＰパケットに収容されて伝送されてくるので、制御部３１はこれをＩＰパケットから取り出して復号することになる。
【００２７】
なお、構成要素３４〜３７などの機能の大部分は、ソフトウエア的に実現されるのが普通であると考えられるが、図３ではこれらを当該制御部３１とは別個な構成要素として示している。
【００２８】
記憶部３３はハードウエア的には、揮発性記憶手段（ＲＡＭなど）や、不揮発性記憶手段（ＥＥＰＲＯＭなど）によって構成される記憶資源であり、ソフトウエア的には、各種のファイルがこの部分に含まれ得る。前記ＯＳなどのプログラムファイルもこのようなファイルの一つであってよいから、ＯＳなども、その物理的な実体は、この記憶部３３に位置する。
【００２９】
操作部３２は、電話をかける場合などにユーザＵ１１が操作する部分で、通常、複数のボタンなどによって構成される。ＩＰ電話機の外形的な構成には様々なものがあり、例えば、通常のパーソナルコンピュータにＩＰ電話用のソフトウエアをインストールし、ヘッドセットなどを装着することによって実現されたＩＰ電話機の場合、外形的な構成は、ほとんど通常のパーソナルコンピュータと同じであり、その場合には、キーボードやマウスなどが、当該操作部３２に該当するが、一般電話機（ＶｏＩＰ非対応の通常の電話機）と同様な外形的構成を持つ場合には、例えば１０個程度のボタンによって当該操作部３２が構成されることになる。
【００３０】
呼制御部３４は、呼制御メッセージを処理する部分である。当該端末２２も、上述した端末１１と同様に、ｒｅ−ＩＮＶＩＴＥメッセージの受信やＴｒｙｉｎｇメッセージの送信などを行う必要があるが、これらの呼制御メッセージは当該呼制御部３４によって処理される。したがって、通話相手の端末２３から保留の指示が届き、当該端末２２で保留音ＨＡ１をユーザＵ１１に聴取させる必要が生じたことを端末２２内で最初に検出するのは、この呼制御部３４である。
【００３１】
送受話部３９は、ユーザＵ１１が発話した音声を集音するマイクや、通話相手であるユーザＵ１２が発話した音声を出力するスピーカを備えた部分である。前記保留音ＨＡ１は、その発生源がいずれであるかにかかわらず、当該スピーカから出力されて、ユーザＵ１１に聴取される。
【００３２】
残りの構成要素３５〜３８は本実施形態に特徴的な構成要素である。
【００３３】
このうちローカル保留音発生部３５は、当該端末２２を利用するユーザＵ１１に聴取させるための保留音ＨＡ１に対応する保留音情報を発生する部分である。従来、保留音情報は、必ず通話相手の端末２３から届くものであったが、本実施形態では、当該ローカル保留音発生部３５が供給することがある。
【００３４】
当該ローカル保留音発生部３５から符号化された状態の保留音情報を出力するようにすれば、制御部３１が備える前記ＶｏＩＰ対応機能を活用することができるが、必ずしもその必要はない。目的の保留音ＨＡ１さえユーザＵ１１に聴取させることができれば、ローカル保留音発生部３５が発生した情報をどのように処理するかは、完全に、端末２２内部の問題であるので、様々な構成が可能である。
【００３５】
いずれにしても、当該ローカル保留音発生部３５を用いれば、ネットワーク２１の帯域の広さや、輻輳度合いなどの影響を受けることなく保留音ＨＡ１を出力することができる。これにより、例えば、ＩＴＵ−Ｔ勧告Ｇ．７２２程度の高い音質を実現することは容易である。また、必ずしも、制御部３１が復号のために実装している機能による復号処理を経る必要もないため、さらに高い音質の保留音ＨＡ１を出力できる可能性もある。
【００３６】
なお、端末２２内のローカル保留音発生部３５が出力する保留音情報に対応する保留音ＨＡ１の場合、端末２２の設定変更などにより、ユーザＵ１１が保留音ＨＡ１の内容を自由に選べるように構成することは容易である。
【００３７】
さらに、当該ローカル保留音発生部３５を用いれば、保留音情報の伝送のためにネットワーク２１の帯域が消費されることがないため、帯域の節約にも寄与する。
【００３８】
リモート保留音検出部３６は、保留を指示してきた相手の端末（ここでは、２３）が、その指示につづいて保留音情報を送信した場合に、その保留音情報を検出する部分である。本実施形態では、相手の端末２３が上述したように端末２２と同じ構成を持つ場合には、保留を指示しても保留音情報は送信しない可能性がある。ただし、相手の端末２３が既存のＩＰ電話機である場合には、保留を指示してきたら必ず、保留音情報も送信してくる。
【００３９】
相手の端末２３が送信してきた保留音情報を無視して、ローカル保留音発生部３５が発生する保留音情報に対応する保留音をユーザＵ１１に聴取させる構成とすることも可能であるが、ここでは、端末２３が保留音情報を送信してきた場合には、その保留音情報に対応する保留音ＨＡ１をユーザＵ１１に聴取させるものとする。この端末２３が送信してきた保留音情報に対応する保留音ＨＡ１の内容は端末２３側で決まるものなので、ユーザＵ１１の好みに応じて変更することは難しい。
【００４０】
音源選択部３７は、前記リモート保留音検出部３６が、保留を指示してきた相手の端末２３が送信した保留音情報を検出しなかった場合（すなわち、相手の端末２３が保留音情報を送信しなかった場合）に機能する部分で、前記ローカル保留音発生部３５または前記音源サーバ２４のいずれかを選択し、選択したほうの保留音情報に対応した保留音ＨＡ１を、前記送受話部３９から出力させる。ただし、音源サーバ２４を選択した場合には、保留音情報を受信するため、当該端末２２が音源サーバ２４とのあいだでセッションを確立する必要がある。
【００４１】
当該音源選択部３７がいずれを選択するかは、例えば、予めユーザＵ１１などが、当該端末２２に設定した内容によって決めるようにするとよい。
【００４２】
ネットワーク２１の帯域を節約できる点などでは、ネットワーク２１経由の通信が必要ないローカル保留音発生部３５を選択するほうが有利であるが、音源サーバ２４を用いると、音源サーバ２４側に用意された豊富な保留音のなかから好みの保留音を選択できる点などで有利となる可能性がある。
【００４３】
なお、端末２２へ供給される保留音情報が、相手の端末２３から届けられるケースと、音源サーバ２４から届けられるケースを比べた場合、音源サーバ２４と端末２２のあいだのホップ数（ルータ（図示せず）の数）が、端末２３と端末２２のあいだのホップ数に比べて小さい場合などには、ネットワーク２１の帯域の節約の観点で音源サーバ２４のほうが有利であるといえる。また、この場合には、ネットワーク２１のボトルネックの部分の帯域の影響を排除して保留音の音質を高めることができる点などでも、音源サーバ２４のほうが有利であるといえる。
【００４４】
前記リモート保留音発生部３８は、当該端末２２側から保留を指示するケースに、保留音情報を発生する部分である。
【００４５】
音源サーバ２４が存在しない場合や、通話相手の端末が、既存のＩＰ電話機のように自身の内部で保留音を発生できない場合には、端末２２側から保留を指示するとき、端末２２内の当該リモート保留音発生部３８が出力する保留音情報で通話相手に保留音を聴取させることが必要になる。相手の端末が、自身の内部で保留音を発生する機能を持つか否かをその電話番号などに対応付けて管理しておけば、相手の電話番号などに応じて、当該リモート保留音発生部３８が発生した保留音情報を、相手の端末へ送信するか否かを制御することができる。
【００４６】
すなわち、相手の端末が自身の内部で保留音を発生する機能を持つ場合や、音源サーバ２４が存在し、相手の端末が音源サーバ２４が送信する保留音情報を利用する機能を持つ場合には、端末２２内の当該リモート保留音発生部３８が発生する保留音情報を相手の端末に送信せず、そうでない場合には、送信するように制御することができる。
【００４７】
また、本来、保留音情報を送信すべきタイミングで送信しないということは、ＳＩＰプロトコルの拡張とみることができるので、相手の端末（例えば、２３）がこの拡張をサポートしているか否か（自身の内部で保留音を発生する機能などを持つか否か）を、ＩＮＶＩＴＥメッセージ（ｒｅ−ＩＮＶＩＴＥメッセージ）に含まれるＲｅｑｕｉｒｅヘッダやＳｕｐｐｏｒｔｅｄヘッダを使用して、その都度、確認し、確認の結果に応じて、当該リモート保留音発生部３８が発生した保留音情報を相手の端末に送信するか否かを決めるようにしてもよい。
【００４８】
ここで、当該Ｒｅｑｕｉｒｅヘッダは、これから使用するＳＩＰの拡張機能を記述して相手の端末に伝えるためのヘッダで、Ｓｕｐｐｏｒｔｅｄヘッダは自端末がサポートしているすべての機能を記述して相手の端末に伝えるヘッダである。
【００４９】
既存のＩＰ電話機の内部構成例を図４に示す。前記端末２３が既存のＩＰ電話機である場合、図４に示した構成を持つことになる。
【００５０】
（Ａ−１−２）既存のＩＰ電話機の内部構成例
図４において、当該ＩＰ電話機（例えば、端末２３）は、通信部４０と、制御部４１と、操作部４２と、記憶部４３と、呼制御部４４と、リモート保留音発生部４５と、送受話部４６とを備えている。
【００５１】
このうち通信部４０は前記通信部３０に対応し、制御部４１は前記制御部３１に対応し、操作部４２は前記操作部３２に対応し、記憶部４３は前記記憶部３３に対応し、呼制御部４４は前記呼制御部３４に対応し、リモート保留音発生部４５は前記リモート保留音発生部３８に対応し、送受話部４６は前記送受話部３９に対応するので、その詳しい説明は省略する。
【００５２】
ただし、前記リモート保留音発生部４５は、相手の端末（例えば、端末２２）が、端末２２と同じ構成を持つＩＰ電話機であるか、既存のＩＰ電話機であるかと無関係に、当該端末２３側から保留を指示した場合には保留音情報を送信する。
【００５３】
前記音源サーバ２４の内部構成は、例えば、図５に示す通りであってよい。
【００５４】
（Ａ−１−３）音源サーバの内部構成例
図５において、当該音源サーバ２４は、通信部５０と、制御部５１と、保留音発生部５２と、記憶部５３とを備えている。
【００５５】
このうち通信部５０は前記通信部３０に対応し、制御部５１は前記制御部３１に対応し、保留音発生部５２は前記リモート保留音発生部３８に対応し、記憶部５３は前記記憶部３３に対応するので、その詳しい説明は省略する。
【００５６】
ただし通信部５０は、前記ＳＩＰサーバ２５または保留音情報を届ける先の端末（例えば、２２）と通信するだけである。
【００５７】
保留音発生部５２は、基本的に前記リモート保留音発生部３５と同じであるが、多くのユーザ（その一人が、Ｕ１１）の好みに合わせて、多種多様な保留音をデータベースに蓄積しておき、予めユーザが選択した保留音をそのユーザに対応付けておく。そして、そのユーザの端末へ保留音情報を送信するときには、対応付けてある保留音の保留音情報を送信する。
【００５８】
以下、上記のような構成を有する本実施形態の動作について、図８のフローチャートと、図６、図７の動作シーケンスを用いて説明する。
【００５９】
図８は、保留の指示を受ける端末の動作を示すフローチャートで、Ｓ３０〜Ｓ３６の各ステップを備えている。
【００６０】
図６と図７は、ＶｏＩＰ通信システム１０全体の動作を示す。図６は、保留の指示を受ける端末が自身で保留音を発生する場合の動作シーケンスで、Ｓ４０〜Ｓ４８の各ステップを備えている。また、図７は、音源サーバ２４が保留音を発生する場合の動作シーケンスで、Ｓ５０〜Ｓ６７の各ステップを備えている。
【００６１】
ここでも、ユーザＵ１１とＵ１２がＶｏＩＰ通信による音声通話を行っている途中で、端末２３側から保留を指示して、当該音声通話を一時中断するケースを想定する。
【００６２】
（Ａ−２）実施形態の動作
図６に示すように、端末２２，２３間ですでにセッションが確立され、端末２２を利用するユーザＵ１１と端末２３を利用するユーザＵ１２がＶｏＩＰ通信で音声通話を行っている（Ｓ４０）。このとき、例えば、第３の端末（図示せず）から呼設定を要求する呼制御メッセージが端末２３に着信すると、それを契機として、ユーザＵ１２が端末２３の保留ボタン（自己保留ボタン）を押下し、当該端末２３の呼制御部（例えば、４４）からｒｅ−ＩＮＶＩＴＥメッセージが送信される（Ｓ４１）。ｒｅ−ＩＮＶＩＴＥメッセージは、セッションの内容の修正を要求する呼制御メッセージである。
【００６３】
また、当該「ｒｅ−ＩＮＶＩＴＥ」のあとの「ＳＤＰ：ａ＝ｓｅｎｄｏｎｌｙ」は、このｒｅ−ＩＮＶＩＴＥメッセージのメッセージボディ中にＳＤＰ（セッション記述プロトコル）でａ（すなわち、メディア属性）として、ｓｅｎｄｏｎｌｙ（送信専用）であることが記述されていることを意味する。このｒｅ−ＩＮＶＩＴＥメッセージの送信元である端末２３側からみて送信専用であるから、当該ｒｅ−ＩＮＶＩＴＥメッセージを受信する端末２２側からみると受信専用のセッションとなる。
【００６４】
このｒｅ−ＩＮＶＩＴＥメッセージがＳＩＰサーバ２５に受信されると、ＳＩＰサーバ２５は、端末２３へＴｒｙｉｎｇメッセージを送信し（Ｓ４２）、端末２２へｒｅ−ＩＮＶＩＴＥメッセージを送信する（Ｓ４３）。Ｔｒｙｉｎｇメッセージは、試行中であることを伝えるメッセージである。「Ｔｒｙｉｎｇ」の前の「１００」は応答コードの一種であり、やはり試行中であることを意味する。
【００６５】
当該ｒｅ−ＩＮＶＩＴＥメッセージを受信した端末２２の呼制御部３４は、ＳＩＰサーバ２５へ、Ｔｒｙｉｎｇメッセージを送信し（Ｓ４４）、つづいてＯＫメッセージを送信する（Ｓ４５）。ＯＫメッセージは、要求（この場合、保留によるセッションの内容の修正）を受け入れたこと（要求が成功したこと）を伝えるメッセージである。「ＯＫ」の前の「２００」は応答コードの一種で、やはり、ＯＫ（要求が成功したこと）を意味する。
【００６６】
当該ＯＫメッセージを受信したＳＩＰサーバ２５は、ＯＫメッセージを前記端末２３に送信する（Ｓ４６）。
【００６７】
当該ＯＫメッセージを受信した端末２３の呼制御部は、ＳＩＰサーバ２５へＡＣＫメッセージを送信する（Ｓ４７）。このＡＣＫメッセージは、前記ステップＳ４６のＯＫメッセージが正常に端末２３まで届いたことの確認のためのメッセージである。
【００６８】
当該ＡＣＫメッセージを受信したＳＩＰサーバ２５は、ＡＣＫメッセージを端末２２に送信する（Ｓ４８）。
【００６９】
このＡＣＫメッセージを端末２２内の前記呼制御部３４が受信したことをもって、図８上では、被保留指示の受信（Ｓ３０）が完了する。
【００７０】
これにつづき、図８では、端末２２内のリモート保留音検出部３６がＲＴＰ（Real-time Transport Protocol）パケットの受信の有無を検出する状態となる（Ｓ３１）。ＲＴＰパケットは、前記端末２３が送信する可能性のある保留音情報を収容したパケットである。ＲＴＰパケットは、前記ＩＰパケットに収容されてネットワーク２１上を送信されるものである。当該ＲＴＰパケットは、ユーザＵ１２の発話した内容を示す音声情報を収容するためにも用いられるが、前記ステップＳ４８でＡＣＫメッセージを受信した直後に、端末２２にＲＴＰパケットが受信された場合、そのＲＴＰパケットは保留音情報を収容したものであるとみなすことができる。
【００７１】
必要ならば、所定の閾値（タイマ）ＴＨ１を設定し、ステップＳ４８でＡＣＫメッセージを受信してから当該閾値ＴＨ１で指定される時間が経過するまでにＲＴＰパケットが受信できなければ、端末２３から保留音情報が送信されなかったものと判定するようにしてもよい。
【００７２】
いずれにしても、このタイミングでＲＴＰパケットが届いた場合には、ステップＳ３１はＹｅｓ側に分岐し、端末２３から保留音情報が届いたものとみなす（Ｓ３２）。この場合、その保留音情報に、復号などの処理を施し、その処理の結果を前記保留音ＨＡ１として送受話部３９から出力するので、ユーザＵ１１は、端末２３から供給された保留音情報に対応する保留音ＨＡ１を聴取することになる。
【００７３】
これに対し、このタイミングでＲＴＰパケットが届かなかった場合、ステップＳ３１はＮｏ側に分岐して、ステップＳ３３の検査が実行される。
【００７４】
ステップＳ３３では、前記音源選択部３７が、保留音ＨＡ１の音源として、自音源（すなわち、ローカル保留音発生部３５）または、サーバ音源（すなわち、音源サーバ２４の保留音発生部５２）のいずれかを選択する。この選択は、予めユーザＵ１１などが、当該端末２２に設定した内容を検査することによって行うものであってよい。
【００７５】
検査の結果、自音源を選択したものであった場合には、処理はステップＳ３４に進み、前記ローカル保留音発生部３５に発生させた保留音情報に応じた保留音ＨＡ１を、送受話部３９から出力する。この場合、ユーザＵ１１は端末２２内部で発生された保留音情報に応じた保留音ＨＡ１を聴取することになる。したがって当該保留音情報は、ネットワーク２１を伝送する必要はない。また、どのような内容の保留音ＨＡ１を聴取するかは、ユーザＵ１１が決めることができる。
【００７６】
なお、当該保留を解除するときには、ＳＩＰサーバ２５経由で相手の端末２３から呼制御メッセージが届くため、保留音情報が相手の端末２３から送信されたものでなくても、端末２２では保留解除のタイミングを認識し、そのタイミングで保留音ＨＡ１の出力を停止すること等ができるから、端末２２を利用するユーザＵ１１は、保留解除後に端末２３を利用するユーザＵ１２と通話を再開することができる。
【００７７】
一方、検査の結果、サーバ音源を選択したものであった場合には、処理はステップＳ３５に進み、端末２２の呼制御部３４は、音源サーバ２４と端末２２とのあいだでセッションを確立し、音源サーバ２４から保留音情報を受信する。
【００７８】
このとき、端末２２，ＳＩＰサーバ２５、音源サーバ２４のあいだでやり取りされる呼制御メッセージは、図７のステップＳ５９〜Ｓ６４に示す通りである。
【００７９】
なお、図７のステップＳ５０〜Ｓ５８は、図６のステップＳ４０〜Ｓ４８に対応する。すなわち、ステップＳ５０は前記ステップＳ４０に対応し、ステップＳ５１は前記ステップＳ４１に対応し、ステップＳ５２は前記ステップＳ４２に対応し、ステップＳ５３は前記ステップＳ４３に対応し、ステップＳ５４は前記ステップＳ４４に対応し、ステップＳ５５は前記ステップＳ４５に対応し、ステップＳ５６は前記ステップＳ４６に対応し、ステップＳ５７は前記ステップＳ４７に対応し、ステップＳ５８は前記ステップＳ４８に対応するので、その詳しい説明は省略する。
【００８０】
このステップＳ５８につづくステップＳ５９では、端末２２が、音源サーバ２４とのセッションの確立を要求するＩＮＶＩＴＥメッセージを、ＳＩＰサーバ２５へ送信している。
【００８１】
以降の処理は前記ステップＳ４２〜Ｓ４８と基本的に同じである。ただし、前記ステップＳ４２〜Ｓ４８がすでに確立されているセッションの内容を修正するためのものであったのに対し、ステップＳ５９〜Ｓ６４、Ｓ６６，Ｓ６７は、まったく新たにセッションを確立するためのものである点が相違するだけである。
【００８２】
ステップＳ６０〜Ｓ６４、Ｓ６６，Ｓ６７のうち、ステップＳ６０は前記ステップＳ４３に対応し、ステップＳ６１は前記ステップＳ４４に対応し、ステップＳ６２は前記ステップＳ４２に対応し、ステップＳ６３は前記ステップＳ４５に対応し、ステップＳ６４は前記ステップＳ４６に対応し、ステップＳ６６は前記ステップＳ４７に対応し、ステップＳ６７は前記ステップＳ４８に対応する。
【００８３】
セッションが確立され、保留音情報を送信してもよい状態になると、前記音源サーバ２４は、端末２２へ保留音情報を送信する（Ｓ６５）。これを受信した端末２２は、相手の端末２３から保留音情報を受信する場合と同様の処理で、当該保留音情報を処理し、前記送受話部３９から当該保留音情報に対応する保留音ＨＡ１を出力する。
【００８４】
このように音源サーバ２４が送信した保留音情報を用いる場合には、ネットワーク２１の帯域は消費されるが、上述したように、端末２３と端末２２のあいだのホップ数に比べて音源サーバ２４と端末２２のあいだのホップ数が小さい場合などには、ネットワーク２１の帯域の節約の観点でも音源サーバ２４を用いるほうが有利であるといえる。また、この場合には、ネットワーク２１のボトルネックの部分の帯域の影響を排除して保留音の音質を高めることができる可能性も高い。
【００８５】
（Ａ−３）実施形態の効果
本実施形態によれば、端末（２２）自身のローカル保留音発生部（３５）を用いる場合には、ネットワーク（２１）の帯域を節約することができる。また、音源サーバ（２４）を用いる場合にも、ネットワークの帯域を節約できる可能性がある。
【００８６】
また、本実施形態では、ローカル保留音発生部を用いる場合でも、音源サーバを用いる場合でも、保留音（ＨＡ１）の内容に、聴取するユーザ（Ｕ１１）の好みを反映することができ、音質を高めることも可能であるから、柔軟性が向上する。
【００８７】
（Ｂ）他の実施形態
上記実施形態にかかわらず、端末２２のローカル保留音発生部３５と、音源サーバ２４は、いずれか一方を省略することもできる。
【００８８】
なお、上記実施形態では、１対１の通信に本発明を適用したが、本発明は、１対多の通信にも適用できる。
【００８９】
また、上記実施形態では、音を前提としたが、本発明は、音以外のマルチメディア情報に適用できる可能性がある。例えば、テレビ電話システムなどでは、保留音とともに、または、保留音に替えて、保留用の画像を相手に目視させる構成もあり得、そのようなケースに本発明を適用することは効果的である。
【００９０】
さらに、通常、リアルタイム性の高い通信にしか保留を実施する必要はないものと考えられるが、リアルタイム性の低い通信であっても、保留を実施する可能性のある場合には、本発明を適用することができる。
【００９１】
なお、上記実施形態で用いた通信プロトコルは必要に応じてその他の通信プロトコルに置き換えてもよい。
【００９２】
例えば、ＩＰプロトコルの替わりに、ＩＰＸプロトコルなどを用いることができる可能性がある。
【００９３】
以上の説明でハードウエア的に実現した機能の大部分はソフトウエア的に実現することが可能であり、ソフトウエア的に実現した機能のほとんど全ては、ハードウエア的に実現することが可能である。
【図面の簡単な説明】
【００９４】
【図１】実施形態にかかるＶｏＩＰ通信システムの全体構成例を示す概略図である。
【図２】従来の保留音送出時の動作を示すシーケンス図である。
【図３】実施形態にかかるＶｏＩＰ通信システムで使用する端末の内部構成例を示す概略図である。
【図４】既存のＩＰ電話機の内部構成例を示す概略図である。
【図５】実施形態にかかるＶｏＩＰ通信システムで使用する音源サーバの内部構成例を示す概略図である。
【図６】実施形態にかかるＶｏＩＰ通信システムの動作例を示すシーケンス図である。
【図７】実施形態にかかるＶｏＩＰ通信システムの動作例を示すシーケンス図である。
【図８】実施形態にかかるＶｏＩＰ通信システムの動作例を示すフローチャートである。
【符号の説明】
【００９５】
１０，２５…ＳＩＰサーバ、１１，１２，２２，２３…端末、２１…ネットワーク、２４…音源サーバ、３０，４０，５０…通信部、３１，４１，５１…制御部、３２，４２…操作部、３３，４３，５３…記憶部、３４，４４…呼制御部、３５…ローカル保留音発生部、３６…リモート保留音検出部、３７…音源選択部、３８、４５…リモート保留音発生部、３９，４６…送受話部、５２…保留音発生部、ＨＡ１…保留音。
【技術分野】
【０００１】
本発明はリアルタイム通信システム、リアルタイム通信方法、およびリアルタイム通信プログラムに関し、例えば、ＶｏＩＰ技術を利用したＩＰ電話機で保留音を出力させる場合など適用して好適なものである。
【背景技術】
【０００２】
従来のＩＰ電話機で保留を行う場合の動作の流れは、図２の動作シーケンスに示す通りである。図２の動作シーケンスは、ＩＰ網などのネットワークを経由して端末１１，１２，ＳＩＰ（セッション開始プロトコル）サーバ１０間で行われる信号のやり取りを示し、Ｓ１０〜Ｓ１９の各ステップを備えている。
【０００３】
ＩＰ電話機である端末１１と１２のあいだで、すでに呼（セッション）が確立されて、各端末１１，１２のユーザＵ１，Ｕ２が双方向で音声通話を行っている（Ｓ１０）。
【０００４】
このとき、例えば第３の端末（図示せず）から端末１２に着信すると、それを契機として、ユーザＵ２が端末１２の保留ボタン（自己保留ボタン）を押下し、当該端末１２からｒｅ−ＩＮＶＩＴＥメッセージが送信される（Ｓ１１）。以降のステップＳ１２〜Ｓ１８では、ＳＩＰプロトコルで定められた保留時の呼制御メッセージがやり取りされ、端末１１が正常に保留を受付けたことを確認したあとで、端末１２から保留音が送信される（Ｓ１９）。
【０００５】
この保留音は、前記ステップＳ１０における双方向の音声通話のうち、ユーザＵ２の発話した音声の内容をユーザＵ１に伝えるための音声通話と同様、端末１２からＩＰパケットで送信され、前記ネットワークを経由して端末１１まで届けられる。当該保留音を聴取したユーザＵ１は、保留状態になったことを認識し、保留解除によってユーザＵ２との音声通話が再開されるのを待つことができる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ところが、図２のような動作を行う従来の通信システムの場合、保留音まで、ユーザＵ２が発話した音声と同様にＩＰパケットに収容してネットワーク経由で伝送させることになるため、ネットワークの帯域を無駄に消費してしまう。
【０００７】
また、保留音の送信元が端末１２であるため、保留音の内容に、聴取するユーザＵ１の好みを反映することが困難で、ネットワークの帯域が十分に広くない場合などにはユーザＵ１が聴取する保留音の音質を高めることも難しいから、柔軟性が低いといえる。
【課題を解決するための手段】
【０００８】
かかる課題を解決するために、第１の本発明では、第１の通信端末と第２の通信端末のあいだで呼を設定してリアルタイム通信を行っている状態で、第２の通信端末のほうから保留を指示して当該リアルタイム通信を一時中断し、保留解除するまでのあいだに、保留されたほうの第１の通信端末のユーザインタフェースを介して、前記リアルタイム通信による信号の替わりに所定の保留信号を出力するリアルタイム通信システムにおいて、（１）前記第２の通信端末以外の保留信号源通信端末、または前記第１の通信端末は、（２）前記第２の通信端末から保留の指示が出されたことを検出する保留指示検出部と、（３）当該保留指示検出部が前記第２の通信端末から保留の指示が出されたことを検出すると、前記保留信号を供給する保留信号供給部とを備えたことを特徴とする。
【０００９】
また、第２の本発明では、第１の通信端末と第２の通信端末のあいだで呼を設定してリアルタイム通信を行っている状態で、第２の通信端末のほうから保留を指示して当該リアルタイム通信を一時中断し、保留解除するまでのあいだに、保留されたほうの第１の通信端末のユーザインタフェースを介して、前記リアルタイム通信による信号の替わりに所定の保留信号を出力するリアルタイム通信方法において、（１）前記第２の通信端末以外の保留信号源通信端末、または前記第１の通信端末では、（２）保留指示検出部が、前記第２の通信端末から保留の指示が出されたことを検出し、（３）当該保留指示検出部が前記第２の通信端末から保留の指示が出されたことを検出すると、保留信号供給部が、前記保留信号を供給することを特徴とする。
【００１０】
さらに、第３の本発明では、第１の通信端末と第２の通信端末のあいだで呼を設定してリアルタイム通信を行っている状態で、第２の通信端末のほうから保留を指示して当該リアルタイム通信を一時中断し、保留解除するまでのあいだに、保留されたほうの第１の通信端末のユーザインタフェースを介して、前記リアルタイム通信による信号の替わりに所定の保留信号を出力するリアルタイム通信プログラムにおいて、（１）前記第２の通信端末以外の保留信号源通信端末、または前記第１の通信端末では、コンピュータに、（２）前記第２の通信端末から保留の指示が出されたことを検出する保留指示検出機能と、（３）当該保留指示検出機能が前記第２の通信端末から保留の指示が出されたことを検出すると、前記保留信号を供給する保留信号供給機能とを実現させることを特徴とする。
【発明の効果】
【００１１】
本発明によれば、帯域を節約し、柔軟性を高めることができる。
【発明を実施するための最良の形態】
【００１２】
（Ａ）実施形態
以下、本発明にかかるリアルタイム通信システム、リアルタイム通信方法、およびリアルタイム通信プログラムを、ＶｏＩＰ通信システムに適用した場合を例に、実施形態について説明する。
【００１３】
（Ａ−１）実施形態の構成
本実施形態にかかるＶｏＩＰ通信システム２０の全体構成例を図１に示す。
【００１４】
図１において、当該ＶｏＩＰ通信システム２０は、ネットワーク２１と、端末２２，２３と、音源サーバ２４と、ＳＩＰサーバ２５とを備えている。
【００１５】
このうちネットワーク２１は、インターネットなどであってもよいが、ここではＩＰ網であるものとする。ＩＰ網はＯＳＩ参照モデルのネットワーク層でＩＰプロトコルを用いるネットワークである点でインターネットと同じであるが、１つの通信事業者が管理運営するネットワークであるので、インターネットに比べて、高い通信品質を保証しやすい。
【００１６】
端末２２，２３はともにＩＰ電話機である。端末２２，２３のうち少なくとも端末２２は、本実施形態で特徴的な端末である。端末２３のほうは、端末２２と同じ構成を持つ端末である場合と、端末２２と異なり、既存のＩＰ電話機である場合があるものとする。また、以下の説明では、主として、ユーザＵ１１とＵ１２がＶｏＩＰ通信による音声通話を行っている途中で、端末２３側から保留を指示して、当該音声通話を一時中断するケースを想定する。
【００１７】
端末２２はユーザＵ１１によって利用され、端末２３はユーザＵ１２によって利用される。
【００１８】
ＳＩＰサーバ２５は、呼制御用のサーバである。呼制御プロトコルとしてはＳＩＰプロトコル以外のプロトコルを使用することも可能であるが、ここでは、ＳＩＰプロトコルを想定する。
【００１９】
ユーザＵ１１とＵ１２がＶｏＩＰ通信による音声通話を開始する前の呼設定のための呼制御の過程では、端末２２，２３間の呼制御メッセージのやり取りにＳＩＰサーバ２５が介在するが、保留の場合にも端末２２，２３間で呼制御メッセージのやり取りが行われ、そのやり取りにＳＩＰサーバ２５が介在することになる。
【００２０】
ＳＩＰサーバ２５の機能は基本的に既存のＳＩＰサーバと同じであってよい。
【００２１】
音源サーバ２４は、端末（ここでは、２２）とセッションを確立したとき、その端末に保留音情報（ユーザＵ１１が聴取する保留音ＨＡ１に対応）を届けるためのサーバである。
【００２２】
次に、本実施形態で特徴的な前記端末２２は、例えば、図３に示すような内部構成を備える。
【００２３】
（Ａ−１−１）端末２２の内部構成例
図３において、当該端末２２は、通信部３０と、制御部３１と、操作部３２と、記憶部３３と、呼制御部３４と、ローカル保留音発生部３５と、リモート保留音検出部３６と、音源選択部３７と、リモート保留音発生部３８と、送受話部３９とを備えている。
【００２４】
このうち通信部３０は端末２２が通信を行う際に機能する部分である。具体的には、呼制御メッセージの通信、音声情報の通信、前記保留音情報の通信などにおいて、当該通信部３０が機能する。ただし、当該端末２２は、ユーザＵ１１に聴取させる保留音ＨＡ１に対応する保留音情報の発生源を端末２３，音源サーバ２４，端末２２自身が備える前記ローカル保留音発生部３５の３つのうちから選ぶことができるので、保留音情報の通信で当該通信部３０が機能するのは、端末２３または音源サーバ２４を選んだケースである。
【００２５】
制御部３１は、ハードウエア的には当該端末２２のＣＰＵ（中央処理装置）に相当し、ソフトウエア的にはＯＳ（オペレーティングシステム）などの各種プログラムに相当し得る部分である。当該制御部３１はＶｏＩＰに対応する処理を実行するＶｏＩＰ対応機能を備える。制御部３１の当該ＶｏＩＰ対応機能は、ユーザＵ１１が発話した音声に対応する音声情報を処理するときには音声情報の符号化、符号化された音声情報をＩＰパケットに収容する処理などを実行し、反対に、ユーザＵ１２が発話した音声に対応する音声情報を収容したＩＰパケットを受信したときには、符号化されている当該音声情報をＩＰパケットから取り出して復号する処理などを実行する。
【００２６】
保留音ＨＡ１に対応する保留音情報が、端末２３または音源サーバ２４から供給される場合、当該保留音情報も、前記ユーザＵ１２が発話した音声に対応する音声情報と同様、符号化された状態でＩＰパケットに収容されて伝送されてくるので、制御部３１はこれをＩＰパケットから取り出して復号することになる。
【００２７】
なお、構成要素３４〜３７などの機能の大部分は、ソフトウエア的に実現されるのが普通であると考えられるが、図３ではこれらを当該制御部３１とは別個な構成要素として示している。
【００２８】
記憶部３３はハードウエア的には、揮発性記憶手段（ＲＡＭなど）や、不揮発性記憶手段（ＥＥＰＲＯＭなど）によって構成される記憶資源であり、ソフトウエア的には、各種のファイルがこの部分に含まれ得る。前記ＯＳなどのプログラムファイルもこのようなファイルの一つであってよいから、ＯＳなども、その物理的な実体は、この記憶部３３に位置する。
【００２９】
操作部３２は、電話をかける場合などにユーザＵ１１が操作する部分で、通常、複数のボタンなどによって構成される。ＩＰ電話機の外形的な構成には様々なものがあり、例えば、通常のパーソナルコンピュータにＩＰ電話用のソフトウエアをインストールし、ヘッドセットなどを装着することによって実現されたＩＰ電話機の場合、外形的な構成は、ほとんど通常のパーソナルコンピュータと同じであり、その場合には、キーボードやマウスなどが、当該操作部３２に該当するが、一般電話機（ＶｏＩＰ非対応の通常の電話機）と同様な外形的構成を持つ場合には、例えば１０個程度のボタンによって当該操作部３２が構成されることになる。
【００３０】
呼制御部３４は、呼制御メッセージを処理する部分である。当該端末２２も、上述した端末１１と同様に、ｒｅ−ＩＮＶＩＴＥメッセージの受信やＴｒｙｉｎｇメッセージの送信などを行う必要があるが、これらの呼制御メッセージは当該呼制御部３４によって処理される。したがって、通話相手の端末２３から保留の指示が届き、当該端末２２で保留音ＨＡ１をユーザＵ１１に聴取させる必要が生じたことを端末２２内で最初に検出するのは、この呼制御部３４である。
【００３１】
送受話部３９は、ユーザＵ１１が発話した音声を集音するマイクや、通話相手であるユーザＵ１２が発話した音声を出力するスピーカを備えた部分である。前記保留音ＨＡ１は、その発生源がいずれであるかにかかわらず、当該スピーカから出力されて、ユーザＵ１１に聴取される。
【００３２】
残りの構成要素３５〜３８は本実施形態に特徴的な構成要素である。
【００３３】
このうちローカル保留音発生部３５は、当該端末２２を利用するユーザＵ１１に聴取させるための保留音ＨＡ１に対応する保留音情報を発生する部分である。従来、保留音情報は、必ず通話相手の端末２３から届くものであったが、本実施形態では、当該ローカル保留音発生部３５が供給することがある。
【００３４】
当該ローカル保留音発生部３５から符号化された状態の保留音情報を出力するようにすれば、制御部３１が備える前記ＶｏＩＰ対応機能を活用することができるが、必ずしもその必要はない。目的の保留音ＨＡ１さえユーザＵ１１に聴取させることができれば、ローカル保留音発生部３５が発生した情報をどのように処理するかは、完全に、端末２２内部の問題であるので、様々な構成が可能である。
【００３５】
いずれにしても、当該ローカル保留音発生部３５を用いれば、ネットワーク２１の帯域の広さや、輻輳度合いなどの影響を受けることなく保留音ＨＡ１を出力することができる。これにより、例えば、ＩＴＵ−Ｔ勧告Ｇ．７２２程度の高い音質を実現することは容易である。また、必ずしも、制御部３１が復号のために実装している機能による復号処理を経る必要もないため、さらに高い音質の保留音ＨＡ１を出力できる可能性もある。
【００３６】
なお、端末２２内のローカル保留音発生部３５が出力する保留音情報に対応する保留音ＨＡ１の場合、端末２２の設定変更などにより、ユーザＵ１１が保留音ＨＡ１の内容を自由に選べるように構成することは容易である。
【００３７】
さらに、当該ローカル保留音発生部３５を用いれば、保留音情報の伝送のためにネットワーク２１の帯域が消費されることがないため、帯域の節約にも寄与する。
【００３８】
リモート保留音検出部３６は、保留を指示してきた相手の端末（ここでは、２３）が、その指示につづいて保留音情報を送信した場合に、その保留音情報を検出する部分である。本実施形態では、相手の端末２３が上述したように端末２２と同じ構成を持つ場合には、保留を指示しても保留音情報は送信しない可能性がある。ただし、相手の端末２３が既存のＩＰ電話機である場合には、保留を指示してきたら必ず、保留音情報も送信してくる。
【００３９】
相手の端末２３が送信してきた保留音情報を無視して、ローカル保留音発生部３５が発生する保留音情報に対応する保留音をユーザＵ１１に聴取させる構成とすることも可能であるが、ここでは、端末２３が保留音情報を送信してきた場合には、その保留音情報に対応する保留音ＨＡ１をユーザＵ１１に聴取させるものとする。この端末２３が送信してきた保留音情報に対応する保留音ＨＡ１の内容は端末２３側で決まるものなので、ユーザＵ１１の好みに応じて変更することは難しい。
【００４０】
音源選択部３７は、前記リモート保留音検出部３６が、保留を指示してきた相手の端末２３が送信した保留音情報を検出しなかった場合（すなわち、相手の端末２３が保留音情報を送信しなかった場合）に機能する部分で、前記ローカル保留音発生部３５または前記音源サーバ２４のいずれかを選択し、選択したほうの保留音情報に対応した保留音ＨＡ１を、前記送受話部３９から出力させる。ただし、音源サーバ２４を選択した場合には、保留音情報を受信するため、当該端末２２が音源サーバ２４とのあいだでセッションを確立する必要がある。
【００４１】
当該音源選択部３７がいずれを選択するかは、例えば、予めユーザＵ１１などが、当該端末２２に設定した内容によって決めるようにするとよい。
【００４２】
ネットワーク２１の帯域を節約できる点などでは、ネットワーク２１経由の通信が必要ないローカル保留音発生部３５を選択するほうが有利であるが、音源サーバ２４を用いると、音源サーバ２４側に用意された豊富な保留音のなかから好みの保留音を選択できる点などで有利となる可能性がある。
【００４３】
なお、端末２２へ供給される保留音情報が、相手の端末２３から届けられるケースと、音源サーバ２４から届けられるケースを比べた場合、音源サーバ２４と端末２２のあいだのホップ数（ルータ（図示せず）の数）が、端末２３と端末２２のあいだのホップ数に比べて小さい場合などには、ネットワーク２１の帯域の節約の観点で音源サーバ２４のほうが有利であるといえる。また、この場合には、ネットワーク２１のボトルネックの部分の帯域の影響を排除して保留音の音質を高めることができる点などでも、音源サーバ２４のほうが有利であるといえる。
【００４４】
前記リモート保留音発生部３８は、当該端末２２側から保留を指示するケースに、保留音情報を発生する部分である。
【００４５】
音源サーバ２４が存在しない場合や、通話相手の端末が、既存のＩＰ電話機のように自身の内部で保留音を発生できない場合には、端末２２側から保留を指示するとき、端末２２内の当該リモート保留音発生部３８が出力する保留音情報で通話相手に保留音を聴取させることが必要になる。相手の端末が、自身の内部で保留音を発生する機能を持つか否かをその電話番号などに対応付けて管理しておけば、相手の電話番号などに応じて、当該リモート保留音発生部３８が発生した保留音情報を、相手の端末へ送信するか否かを制御することができる。
【００４６】
すなわち、相手の端末が自身の内部で保留音を発生する機能を持つ場合や、音源サーバ２４が存在し、相手の端末が音源サーバ２４が送信する保留音情報を利用する機能を持つ場合には、端末２２内の当該リモート保留音発生部３８が発生する保留音情報を相手の端末に送信せず、そうでない場合には、送信するように制御することができる。
【００４７】
また、本来、保留音情報を送信すべきタイミングで送信しないということは、ＳＩＰプロトコルの拡張とみることができるので、相手の端末（例えば、２３）がこの拡張をサポートしているか否か（自身の内部で保留音を発生する機能などを持つか否か）を、ＩＮＶＩＴＥメッセージ（ｒｅ−ＩＮＶＩＴＥメッセージ）に含まれるＲｅｑｕｉｒｅヘッダやＳｕｐｐｏｒｔｅｄヘッダを使用して、その都度、確認し、確認の結果に応じて、当該リモート保留音発生部３８が発生した保留音情報を相手の端末に送信するか否かを決めるようにしてもよい。
【００４８】
ここで、当該Ｒｅｑｕｉｒｅヘッダは、これから使用するＳＩＰの拡張機能を記述して相手の端末に伝えるためのヘッダで、Ｓｕｐｐｏｒｔｅｄヘッダは自端末がサポートしているすべての機能を記述して相手の端末に伝えるヘッダである。
【００４９】
既存のＩＰ電話機の内部構成例を図４に示す。前記端末２３が既存のＩＰ電話機である場合、図４に示した構成を持つことになる。
【００５０】
（Ａ−１−２）既存のＩＰ電話機の内部構成例
図４において、当該ＩＰ電話機（例えば、端末２３）は、通信部４０と、制御部４１と、操作部４２と、記憶部４３と、呼制御部４４と、リモート保留音発生部４５と、送受話部４６とを備えている。
【００５１】
このうち通信部４０は前記通信部３０に対応し、制御部４１は前記制御部３１に対応し、操作部４２は前記操作部３２に対応し、記憶部４３は前記記憶部３３に対応し、呼制御部４４は前記呼制御部３４に対応し、リモート保留音発生部４５は前記リモート保留音発生部３８に対応し、送受話部４６は前記送受話部３９に対応するので、その詳しい説明は省略する。
【００５２】
ただし、前記リモート保留音発生部４５は、相手の端末（例えば、端末２２）が、端末２２と同じ構成を持つＩＰ電話機であるか、既存のＩＰ電話機であるかと無関係に、当該端末２３側から保留を指示した場合には保留音情報を送信する。
【００５３】
前記音源サーバ２４の内部構成は、例えば、図５に示す通りであってよい。
【００５４】
（Ａ−１−３）音源サーバの内部構成例
図５において、当該音源サーバ２４は、通信部５０と、制御部５１と、保留音発生部５２と、記憶部５３とを備えている。
【００５５】
このうち通信部５０は前記通信部３０に対応し、制御部５１は前記制御部３１に対応し、保留音発生部５２は前記リモート保留音発生部３８に対応し、記憶部５３は前記記憶部３３に対応するので、その詳しい説明は省略する。
【００５６】
ただし通信部５０は、前記ＳＩＰサーバ２５または保留音情報を届ける先の端末（例えば、２２）と通信するだけである。
【００５７】
保留音発生部５２は、基本的に前記リモート保留音発生部３５と同じであるが、多くのユーザ（その一人が、Ｕ１１）の好みに合わせて、多種多様な保留音をデータベースに蓄積しておき、予めユーザが選択した保留音をそのユーザに対応付けておく。そして、そのユーザの端末へ保留音情報を送信するときには、対応付けてある保留音の保留音情報を送信する。
【００５８】
以下、上記のような構成を有する本実施形態の動作について、図８のフローチャートと、図６、図７の動作シーケンスを用いて説明する。
【００５９】
図８は、保留の指示を受ける端末の動作を示すフローチャートで、Ｓ３０〜Ｓ３６の各ステップを備えている。
【００６０】
図６と図７は、ＶｏＩＰ通信システム１０全体の動作を示す。図６は、保留の指示を受ける端末が自身で保留音を発生する場合の動作シーケンスで、Ｓ４０〜Ｓ４８の各ステップを備えている。また、図７は、音源サーバ２４が保留音を発生する場合の動作シーケンスで、Ｓ５０〜Ｓ６７の各ステップを備えている。
【００６１】
ここでも、ユーザＵ１１とＵ１２がＶｏＩＰ通信による音声通話を行っている途中で、端末２３側から保留を指示して、当該音声通話を一時中断するケースを想定する。
【００６２】
（Ａ−２）実施形態の動作
図６に示すように、端末２２，２３間ですでにセッションが確立され、端末２２を利用するユーザＵ１１と端末２３を利用するユーザＵ１２がＶｏＩＰ通信で音声通話を行っている（Ｓ４０）。このとき、例えば、第３の端末（図示せず）から呼設定を要求する呼制御メッセージが端末２３に着信すると、それを契機として、ユーザＵ１２が端末２３の保留ボタン（自己保留ボタン）を押下し、当該端末２３の呼制御部（例えば、４４）からｒｅ−ＩＮＶＩＴＥメッセージが送信される（Ｓ４１）。ｒｅ−ＩＮＶＩＴＥメッセージは、セッションの内容の修正を要求する呼制御メッセージである。
【００６３】
また、当該「ｒｅ−ＩＮＶＩＴＥ」のあとの「ＳＤＰ：ａ＝ｓｅｎｄｏｎｌｙ」は、このｒｅ−ＩＮＶＩＴＥメッセージのメッセージボディ中にＳＤＰ（セッション記述プロトコル）でａ（すなわち、メディア属性）として、ｓｅｎｄｏｎｌｙ（送信専用）であることが記述されていることを意味する。このｒｅ−ＩＮＶＩＴＥメッセージの送信元である端末２３側からみて送信専用であるから、当該ｒｅ−ＩＮＶＩＴＥメッセージを受信する端末２２側からみると受信専用のセッションとなる。
【００６４】
このｒｅ−ＩＮＶＩＴＥメッセージがＳＩＰサーバ２５に受信されると、ＳＩＰサーバ２５は、端末２３へＴｒｙｉｎｇメッセージを送信し（Ｓ４２）、端末２２へｒｅ−ＩＮＶＩＴＥメッセージを送信する（Ｓ４３）。Ｔｒｙｉｎｇメッセージは、試行中であることを伝えるメッセージである。「Ｔｒｙｉｎｇ」の前の「１００」は応答コードの一種であり、やはり試行中であることを意味する。
【００６５】
当該ｒｅ−ＩＮＶＩＴＥメッセージを受信した端末２２の呼制御部３４は、ＳＩＰサーバ２５へ、Ｔｒｙｉｎｇメッセージを送信し（Ｓ４４）、つづいてＯＫメッセージを送信する（Ｓ４５）。ＯＫメッセージは、要求（この場合、保留によるセッションの内容の修正）を受け入れたこと（要求が成功したこと）を伝えるメッセージである。「ＯＫ」の前の「２００」は応答コードの一種で、やはり、ＯＫ（要求が成功したこと）を意味する。
【００６６】
当該ＯＫメッセージを受信したＳＩＰサーバ２５は、ＯＫメッセージを前記端末２３に送信する（Ｓ４６）。
【００６７】
当該ＯＫメッセージを受信した端末２３の呼制御部は、ＳＩＰサーバ２５へＡＣＫメッセージを送信する（Ｓ４７）。このＡＣＫメッセージは、前記ステップＳ４６のＯＫメッセージが正常に端末２３まで届いたことの確認のためのメッセージである。
【００６８】
当該ＡＣＫメッセージを受信したＳＩＰサーバ２５は、ＡＣＫメッセージを端末２２に送信する（Ｓ４８）。
【００６９】
このＡＣＫメッセージを端末２２内の前記呼制御部３４が受信したことをもって、図８上では、被保留指示の受信（Ｓ３０）が完了する。
【００７０】
これにつづき、図８では、端末２２内のリモート保留音検出部３６がＲＴＰ（Real-time Transport Protocol）パケットの受信の有無を検出する状態となる（Ｓ３１）。ＲＴＰパケットは、前記端末２３が送信する可能性のある保留音情報を収容したパケットである。ＲＴＰパケットは、前記ＩＰパケットに収容されてネットワーク２１上を送信されるものである。当該ＲＴＰパケットは、ユーザＵ１２の発話した内容を示す音声情報を収容するためにも用いられるが、前記ステップＳ４８でＡＣＫメッセージを受信した直後に、端末２２にＲＴＰパケットが受信された場合、そのＲＴＰパケットは保留音情報を収容したものであるとみなすことができる。
【００７１】
必要ならば、所定の閾値（タイマ）ＴＨ１を設定し、ステップＳ４８でＡＣＫメッセージを受信してから当該閾値ＴＨ１で指定される時間が経過するまでにＲＴＰパケットが受信できなければ、端末２３から保留音情報が送信されなかったものと判定するようにしてもよい。
【００７２】
いずれにしても、このタイミングでＲＴＰパケットが届いた場合には、ステップＳ３１はＹｅｓ側に分岐し、端末２３から保留音情報が届いたものとみなす（Ｓ３２）。この場合、その保留音情報に、復号などの処理を施し、その処理の結果を前記保留音ＨＡ１として送受話部３９から出力するので、ユーザＵ１１は、端末２３から供給された保留音情報に対応する保留音ＨＡ１を聴取することになる。
【００７３】
これに対し、このタイミングでＲＴＰパケットが届かなかった場合、ステップＳ３１はＮｏ側に分岐して、ステップＳ３３の検査が実行される。
【００７４】
ステップＳ３３では、前記音源選択部３７が、保留音ＨＡ１の音源として、自音源（すなわち、ローカル保留音発生部３５）または、サーバ音源（すなわち、音源サーバ２４の保留音発生部５２）のいずれかを選択する。この選択は、予めユーザＵ１１などが、当該端末２２に設定した内容を検査することによって行うものであってよい。
【００７５】
検査の結果、自音源を選択したものであった場合には、処理はステップＳ３４に進み、前記ローカル保留音発生部３５に発生させた保留音情報に応じた保留音ＨＡ１を、送受話部３９から出力する。この場合、ユーザＵ１１は端末２２内部で発生された保留音情報に応じた保留音ＨＡ１を聴取することになる。したがって当該保留音情報は、ネットワーク２１を伝送する必要はない。また、どのような内容の保留音ＨＡ１を聴取するかは、ユーザＵ１１が決めることができる。
【００７６】
なお、当該保留を解除するときには、ＳＩＰサーバ２５経由で相手の端末２３から呼制御メッセージが届くため、保留音情報が相手の端末２３から送信されたものでなくても、端末２２では保留解除のタイミングを認識し、そのタイミングで保留音ＨＡ１の出力を停止すること等ができるから、端末２２を利用するユーザＵ１１は、保留解除後に端末２３を利用するユーザＵ１２と通話を再開することができる。
【００７７】
一方、検査の結果、サーバ音源を選択したものであった場合には、処理はステップＳ３５に進み、端末２２の呼制御部３４は、音源サーバ２４と端末２２とのあいだでセッションを確立し、音源サーバ２４から保留音情報を受信する。
【００７８】
このとき、端末２２，ＳＩＰサーバ２５、音源サーバ２４のあいだでやり取りされる呼制御メッセージは、図７のステップＳ５９〜Ｓ６４に示す通りである。
【００７９】
なお、図７のステップＳ５０〜Ｓ５８は、図６のステップＳ４０〜Ｓ４８に対応する。すなわち、ステップＳ５０は前記ステップＳ４０に対応し、ステップＳ５１は前記ステップＳ４１に対応し、ステップＳ５２は前記ステップＳ４２に対応し、ステップＳ５３は前記ステップＳ４３に対応し、ステップＳ５４は前記ステップＳ４４に対応し、ステップＳ５５は前記ステップＳ４５に対応し、ステップＳ５６は前記ステップＳ４６に対応し、ステップＳ５７は前記ステップＳ４７に対応し、ステップＳ５８は前記ステップＳ４８に対応するので、その詳しい説明は省略する。
【００８０】
このステップＳ５８につづくステップＳ５９では、端末２２が、音源サーバ２４とのセッションの確立を要求するＩＮＶＩＴＥメッセージを、ＳＩＰサーバ２５へ送信している。
【００８１】
以降の処理は前記ステップＳ４２〜Ｓ４８と基本的に同じである。ただし、前記ステップＳ４２〜Ｓ４８がすでに確立されているセッションの内容を修正するためのものであったのに対し、ステップＳ５９〜Ｓ６４、Ｓ６６，Ｓ６７は、まったく新たにセッションを確立するためのものである点が相違するだけである。
【００８２】
ステップＳ６０〜Ｓ６４、Ｓ６６，Ｓ６７のうち、ステップＳ６０は前記ステップＳ４３に対応し、ステップＳ６１は前記ステップＳ４４に対応し、ステップＳ６２は前記ステップＳ４２に対応し、ステップＳ６３は前記ステップＳ４５に対応し、ステップＳ６４は前記ステップＳ４６に対応し、ステップＳ６６は前記ステップＳ４７に対応し、ステップＳ６７は前記ステップＳ４８に対応する。
【００８３】
セッションが確立され、保留音情報を送信してもよい状態になると、前記音源サーバ２４は、端末２２へ保留音情報を送信する（Ｓ６５）。これを受信した端末２２は、相手の端末２３から保留音情報を受信する場合と同様の処理で、当該保留音情報を処理し、前記送受話部３９から当該保留音情報に対応する保留音ＨＡ１を出力する。
【００８４】
このように音源サーバ２４が送信した保留音情報を用いる場合には、ネットワーク２１の帯域は消費されるが、上述したように、端末２３と端末２２のあいだのホップ数に比べて音源サーバ２４と端末２２のあいだのホップ数が小さい場合などには、ネットワーク２１の帯域の節約の観点でも音源サーバ２４を用いるほうが有利であるといえる。また、この場合には、ネットワーク２１のボトルネックの部分の帯域の影響を排除して保留音の音質を高めることができる可能性も高い。
【００８５】
（Ａ−３）実施形態の効果
本実施形態によれば、端末（２２）自身のローカル保留音発生部（３５）を用いる場合には、ネットワーク（２１）の帯域を節約することができる。また、音源サーバ（２４）を用いる場合にも、ネットワークの帯域を節約できる可能性がある。
【００８６】
また、本実施形態では、ローカル保留音発生部を用いる場合でも、音源サーバを用いる場合でも、保留音（ＨＡ１）の内容に、聴取するユーザ（Ｕ１１）の好みを反映することができ、音質を高めることも可能であるから、柔軟性が向上する。
【００８７】
（Ｂ）他の実施形態
上記実施形態にかかわらず、端末２２のローカル保留音発生部３５と、音源サーバ２４は、いずれか一方を省略することもできる。
【００８８】
なお、上記実施形態では、１対１の通信に本発明を適用したが、本発明は、１対多の通信にも適用できる。
【００８９】
また、上記実施形態では、音を前提としたが、本発明は、音以外のマルチメディア情報に適用できる可能性がある。例えば、テレビ電話システムなどでは、保留音とともに、または、保留音に替えて、保留用の画像を相手に目視させる構成もあり得、そのようなケースに本発明を適用することは効果的である。
【００９０】
さらに、通常、リアルタイム性の高い通信にしか保留を実施する必要はないものと考えられるが、リアルタイム性の低い通信であっても、保留を実施する可能性のある場合には、本発明を適用することができる。
【００９１】
なお、上記実施形態で用いた通信プロトコルは必要に応じてその他の通信プロトコルに置き換えてもよい。
【００９２】
例えば、ＩＰプロトコルの替わりに、ＩＰＸプロトコルなどを用いることができる可能性がある。
【００９３】
以上の説明でハードウエア的に実現した機能の大部分はソフトウエア的に実現することが可能であり、ソフトウエア的に実現した機能のほとんど全ては、ハードウエア的に実現することが可能である。
【図面の簡単な説明】
【００９４】
【図１】実施形態にかかるＶｏＩＰ通信システムの全体構成例を示す概略図である。
【図２】従来の保留音送出時の動作を示すシーケンス図である。
【図３】実施形態にかかるＶｏＩＰ通信システムで使用する端末の内部構成例を示す概略図である。
【図４】既存のＩＰ電話機の内部構成例を示す概略図である。
【図５】実施形態にかかるＶｏＩＰ通信システムで使用する音源サーバの内部構成例を示す概略図である。
【図６】実施形態にかかるＶｏＩＰ通信システムの動作例を示すシーケンス図である。
【図７】実施形態にかかるＶｏＩＰ通信システムの動作例を示すシーケンス図である。
【図８】実施形態にかかるＶｏＩＰ通信システムの動作例を示すフローチャートである。
【符号の説明】
【００９５】
１０，２５…ＳＩＰサーバ、１１，１２，２２，２３…端末、２１…ネットワーク、２４…音源サーバ、３０，４０，５０…通信部、３１，４１，５１…制御部、３２，４２…操作部、３３，４３，５３…記憶部、３４，４４…呼制御部、３５…ローカル保留音発生部、３６…リモート保留音検出部、３７…音源選択部、３８、４５…リモート保留音発生部、３９，４６…送受話部、５２…保留音発生部、ＨＡ１…保留音。
【特許請求の範囲】
【請求項１】
第１の通信端末と第２の通信端末のあいだで呼を設定してリアルタイム通信を行っている状態で、第２の通信端末のほうから保留を指示して当該リアルタイム通信を一時中断し、保留解除するまでのあいだに、保留されたほうの第１の通信端末のユーザインタフェースを介して、前記リアルタイム通信による信号の替わりに所定の保留信号を出力するリアルタイム通信システムにおいて、
前記第２の通信端末以外の保留信号源通信端末、または前記第１の通信端末は、
前記第２の通信端末から保留の指示が出されたことを検出する保留指示検出部と、
当該保留指示検出部が前記第２の通信端末から保留の指示が出されたことを検出すると、前記保留信号を供給する保留信号供給部とを備えたことを特徴とするリアルタイム通信システム。
【請求項２】
請求項１のリアルタイム通信システムにおいて、
前記保留信号源通信端末または第１の通信端末は、
前記第２の通信端末から保留の指示が出されたことを検出したあと、前記第２の通信端末から保留信号が送信されたか否かを判定する保留信号送信判定部と、
当該保留信号送信判定部が、前記第２の通信端末から保留信号が送信されたと判定した場合にはその保留信号を、前記ユーザインタフェースから出力させ、送信されなかったと判定した場合には、前記保留信号供給部が供給する保留信号を、前記ユーザインタフェースから出力させる保留信号出力制御部とを備えたことを特徴とするリアルタイム通信システム。
【請求項３】
請求項２のリアルタイム通信システムにおいて、
前記第１の通信端末は、
前記保留信号送信判定部が、前記第２の通信端末から保留信号が送信されなかったと判定した場合、第１の通信端末自身が備える前記保留信号供給部から供給される保留信号、または前記保留信号源通信端末が備える保留信号供給部から供給される保留信号のいずれかを選択する供給源選択部を備え、
当該供給源選択部が選択したほうの保留信号を前記ユーザインタフェースから出力することを特徴とするリアルタイム通信システム。
【請求項４】
第１の通信端末と第２の通信端末のあいだで呼を設定してリアルタイム通信を行っている状態で、第２の通信端末のほうから保留を指示して当該リアルタイム通信を一時中断し、保留解除するまでのあいだに、保留されたほうの第１の通信端末のユーザインタフェースを介して、前記リアルタイム通信による信号の替わりに所定の保留信号を出力するリアルタイム通信方法において、
前記第２の通信端末以外の保留信号源通信端末、または前記第１の通信端末では、
保留指示検出部が、前記第２の通信端末から保留の指示が出されたことを検出し、
当該保留指示検出部が前記第２の通信端末から保留の指示が出されたことを検出すると、保留信号供給部が、前記保留信号を供給することを特徴とするリアルタイム通信方法。
【請求項５】
第１の通信端末と第２の通信端末のあいだで呼を設定してリアルタイム通信を行っている状態で、第２の通信端末のほうから保留を指示して当該リアルタイム通信を一時中断し、保留解除するまでのあいだに、保留されたほうの第１の通信端末のユーザインタフェースを介して、前記リアルタイム通信による信号の替わりに所定の保留信号を出力するリアルタイム通信プログラムにおいて、前記第２の通信端末以外の保留信号源通信端末、または前記第１の通信端末では、コンピュータに、
前記第２の通信端末から保留の指示が出されたことを検出する保留指示検出機能と、
当該保留指示検出機能が前記第２の通信端末から保留の指示が出されたことを検出すると、前記保留信号を供給する保留信号供給機能とを実現させることを特徴とするリアルタイム通信プログラム。
【請求項１】
第１の通信端末と第２の通信端末のあいだで呼を設定してリアルタイム通信を行っている状態で、第２の通信端末のほうから保留を指示して当該リアルタイム通信を一時中断し、保留解除するまでのあいだに、保留されたほうの第１の通信端末のユーザインタフェースを介して、前記リアルタイム通信による信号の替わりに所定の保留信号を出力するリアルタイム通信システムにおいて、
前記第２の通信端末以外の保留信号源通信端末、または前記第１の通信端末は、
前記第２の通信端末から保留の指示が出されたことを検出する保留指示検出部と、
当該保留指示検出部が前記第２の通信端末から保留の指示が出されたことを検出すると、前記保留信号を供給する保留信号供給部とを備えたことを特徴とするリアルタイム通信システム。
【請求項２】
請求項１のリアルタイム通信システムにおいて、
前記保留信号源通信端末または第１の通信端末は、
前記第２の通信端末から保留の指示が出されたことを検出したあと、前記第２の通信端末から保留信号が送信されたか否かを判定する保留信号送信判定部と、
当該保留信号送信判定部が、前記第２の通信端末から保留信号が送信されたと判定した場合にはその保留信号を、前記ユーザインタフェースから出力させ、送信されなかったと判定した場合には、前記保留信号供給部が供給する保留信号を、前記ユーザインタフェースから出力させる保留信号出力制御部とを備えたことを特徴とするリアルタイム通信システム。
【請求項３】
請求項２のリアルタイム通信システムにおいて、
前記第１の通信端末は、
前記保留信号送信判定部が、前記第２の通信端末から保留信号が送信されなかったと判定した場合、第１の通信端末自身が備える前記保留信号供給部から供給される保留信号、または前記保留信号源通信端末が備える保留信号供給部から供給される保留信号のいずれかを選択する供給源選択部を備え、
当該供給源選択部が選択したほうの保留信号を前記ユーザインタフェースから出力することを特徴とするリアルタイム通信システム。
【請求項４】
第１の通信端末と第２の通信端末のあいだで呼を設定してリアルタイム通信を行っている状態で、第２の通信端末のほうから保留を指示して当該リアルタイム通信を一時中断し、保留解除するまでのあいだに、保留されたほうの第１の通信端末のユーザインタフェースを介して、前記リアルタイム通信による信号の替わりに所定の保留信号を出力するリアルタイム通信方法において、
前記第２の通信端末以外の保留信号源通信端末、または前記第１の通信端末では、
保留指示検出部が、前記第２の通信端末から保留の指示が出されたことを検出し、
当該保留指示検出部が前記第２の通信端末から保留の指示が出されたことを検出すると、保留信号供給部が、前記保留信号を供給することを特徴とするリアルタイム通信方法。
【請求項５】
第１の通信端末と第２の通信端末のあいだで呼を設定してリアルタイム通信を行っている状態で、第２の通信端末のほうから保留を指示して当該リアルタイム通信を一時中断し、保留解除するまでのあいだに、保留されたほうの第１の通信端末のユーザインタフェースを介して、前記リアルタイム通信による信号の替わりに所定の保留信号を出力するリアルタイム通信プログラムにおいて、前記第２の通信端末以外の保留信号源通信端末、または前記第１の通信端末では、コンピュータに、
前記第２の通信端末から保留の指示が出されたことを検出する保留指示検出機能と、
当該保留指示検出機能が前記第２の通信端末から保留の指示が出されたことを検出すると、前記保留信号を供給する保留信号供給機能とを実現させることを特徴とするリアルタイム通信プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００６−１３９１６（Ｐ２００６−１３９１６Ａ）
【公開日】平成１８年１月１２日（２００６．１．１２）
【国際特許分類】
【出願番号】特願２００４−１８８４５６（Ｐ２００４−１８８４５６）
【出願日】平成１６年６月２５日（２００４．６．２５）
【出願人】（５０３３３４１５０）株式会社沖テクノクリエーション (52)
【Ｆターム（参考）】
【公開日】平成１８年１月１２日（２００６．１．１２）
【国際特許分類】
【出願日】平成１６年６月２５日（２００４．６．２５）
【出願人】（５０３３３４１５０）株式会社沖テクノクリエーション (52)
【Ｆターム（参考）】
[ Back to top ]