(57)【要約】【課題】  融通性および利便性を高める。【解決手段】  第１の通信プロトコルに対応するネットワークと、音声通信用の第２の通信プロトコルに対応する音声通信対応端末とのあいだでプロトコル変換を行うゲートウエイ装置を用い、音声通信のための呼制御機能を持たない音声通信非対応端末による音声通信を実現する通信システムであって、ゲートウエイ装置は、音声通信対応端末への着信につづく呼び出しを契機として、音声通信非対応端末のユーザが応答したとき、その応答を検出するピックアップ対応処理部と、ピックアップ対応処理部が音声通信非対応端末のユーザからの応答を検出すると、本来、音声通信対応端末へ転送するべき音声通信用のデータを、音声通信非対応端末へ転送する音声転送処理部とを備える。【選択図】  図１
2005244772.tif 000002
【特許請求の範囲】
【請求項１】
第１の通信プロトコルに対応するネットワークと、音声通信用の第２の通信プロトコルに対応する音声通信対応端末とのあいだでプロトコル変換を行うゲートウエイ装置を用い、前記音声通信のための呼制御機能を持たない音声通信非対応端末による音声通信を実現する通信システムであって、
前記ゲートウエイ装置は、
前記音声通信対応端末への着信につづく呼び出しを契機として、前記音声通信非対応端末のユーザが応答したとき、その応答を検出するピックアップ対応処理部と、
当該ピックアップ対応処理部が前記音声通信非対応端末のユーザからの応答を検出すると、本来、前記音声通信対応端末へ転送するべき音声通信用のデータを、当該音声通信非対応端末へ転送する音声転送処理部とを備えたことを特徴とする通信システム。
【請求項２】
音声通信のための呼制御機能を持たない音声通信非対応端末による音声通信を実現する通信システムの構成要素としてのゲートウエイ装置において、
第１の通信プロトコルに対応するネットワークと、音声通信用の第２の通信プロトコルに対応する音声通信対応端末とのあいだでプロトコル変換を行うプロトコル変換部と、
前記音声通信対応端末への着信につづく呼び出しを契機として、前記音声通信非対応端末のユーザが応答したとき、その応答を検出するピックアップ対応処理部と、
当該ピックアップ対応処理部が前記音声通信非対応端末のユーザからの応答を検出すると、本来、前記音声通信対応端末へ転送するべき音声通信用のデータを、当該音声通信非対応端末へ転送する音声転送処理部とを備えたことを特徴とするゲートウエイ装置。
【請求項３】
第１の通信プロトコルに対応するネットワークと、音声通信用の第２の通信プロトコルに対応する音声通信対応端末とのあいだでプロトコル変換を行うゲートウエイ装置を用い、前記音声通信のための呼制御機能を持たない音声通信非対応端末による音声通信を実現する通信方法であって、
前記ゲートウエイ装置内のピックアップ対応処理部が、前記音声通信対応端末への着信につづく呼び出しを契機として、前記音声通信非対応端末のユーザが応答したとき、その応答を検出し、
当該ゲートウエイ装置内の音声転送処理部が、当該ピックアップ対応処理部が前記音声通信非対応端末のユーザからの応答を検出すると、本来、前記音声通信対応端末へ転送するべき音声通信用のデータを、当該音声通信非対応端末へ転送することを特徴とする通信方法。
【請求項４】
音声通信のための呼制御機能を持たない音声通信非対応端末による音声通信を実現する通信システムの構成要素としてのゲートウエイプログラムにおいて、コンピュータに、
第１の通信プロトコルに対応するネットワークと、音声通信用の第２の通信プロトコルに対応する音声通信対応端末とのあいだでプロトコル変換を行うプロトコル変換機能と、
前記音声通信対応端末への着信につづく呼び出しを契機として、前記音声通信非対応端末のユーザが応答したとき、その応答を検出するピックアップ対応処理機能と、
当該ピックアップ対応処理機能が前記音声通信非対応端末のユーザからの応答を検出すると、本来、前記音声通信対応端末へ転送するべき音声通信用のデータを、当該音声通信非対応端末へ転送する音声転送処理機能とを実現させることを特徴とするゲートウエイプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信システム、ゲートウエイ装置、通信方法、およびゲートウエイプログラムに関し、例えば、電話機を収容し、なおかつパソコンと接続できるインタフェースを持つＶｏＩＰ端末（ＲＧＷ（Ｒｅｓｉｄｅｎｔｉａｌ  Ｇａｔｅ−Ｗａｙ））などに適用して好適なものである。
【背景技術】
【０００２】
交換機に収容される端末は同一グループ内であれば他の端末の着信を受けることができる。この機能はピックアップと呼ばれる。
【０００３】
例えば、図２に示す構成の場合、電話機１２のユーザＵ１２は、電話機１１への着信につづく呼び出しに電話機１１のユーザＵ１１が応答しない場合など、電話機１２をオフフックしてその着信を電話機１１で受けることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、図３に示すような構成において、上述したピックアップをＶｏＩＰのもとで実現することが考えられる。
【０００５】
図３において、上述したＲＧＷの一種であるＲＧＷ２１は、ＷＡＮ２０を接続するインタフェースＰ１と、電話機２３，２４を接続するインタフェースＰ２，Ｐ３と、ＬＡＮ２２すなわちパソコン２５を接続するインタフェースＰ４とを備えている。
【０００６】
外形的にみて、このような接続関係自体はパソコン２５をＲＧＷ２１に設定を行うためのコンソール端末として利用する場合によく用いられるものである。
【０００７】
当該パソコン２５にマイクやスピーカなども含め通常のＩＰ電話機に必要な全機能が搭載されている場合には、当該パソコン２５はＩＰ電話機にもなるが、ここでは、当該パソコン２５にマイクやスピーカなどは搭載されているもののＶｏＩＰの呼制御機能は搭載されていないケースを想定する。
【０００８】
このケースでは、電話機２３のユーザＵ２３が電話機２３に対する着信につづく呼び出しに応答しない場合や、電話機２４のユーザＵ２４が電話機２４に対する着信につづく呼び出しに応答しない場合に、パソコン２５のユーザＵ２５がパソコン２５を用いてその着信を受けることができないという問題があり、融通性や利便性が低い。
【課題を解決するための手段】
【０００９】
かかる課題を解決するために、第１の本発明では、第１の通信プロトコルに対応するネットワークと、音声通信用の第２の通信プロトコルに対応する音声通信対応端末とのあいだでプロトコル変換を行うゲートウエイ装置を用い、前記音声通信のための呼制御機能を持たない音声通信非対応端末による音声通信を実現する通信システムであって、前記ゲートウエイ装置は、前記音声通信対応端末への着信につづく呼び出しを契機として、前記音声通信非対応端末のユーザが応答したとき、その応答を検出するピックアップ対応処理部と、当該ピックアップ対応処理部が前記音声通信非対応端末のユーザからの応答を検出すると、本来、前記音声通信対応端末へ転送するべき音声通信用のデータを、当該音声通信非対応端末へ転送する音声転送処理部とを備えたことを特徴とする。
【００１０】
また、第２の本発明では、音声通信のための呼制御機能を持たない音声通信非対応端末による音声通信を実現する通信システムの構成要素としてのゲートウエイ装置において、（１）第１の通信プロトコルに対応するネットワークと、音声通信用の第２の通信プロトコルに対応する音声通信対応端末とのあいだでプロトコル変換を行うプロトコル変換部と、（２）前記音声通信対応端末への着信につづく呼び出しを契機として、前記音声通信非対応端末のユーザが応答したとき、その応答を検出するピックアップ対応処理部と、（３）当該ピックアップ対応処理部が前記音声通信非対応端末のユーザからの応答を検出すると、本来、前記音声通信対応端末へ転送するべき音声通信用のデータを、当該音声通信非対応端末へ転送する音声転送処理部とを備えたことを特徴とする。
【００１１】
さらに、第３の本発明では、第１の通信プロトコルに対応するネットワークと、音声通信用の第２の通信プロトコルに対応する音声通信対応端末とのあいだでプロトコル変換を行うゲートウエイ装置を用い、前記音声通信のための呼制御機能を持たない音声通信非対応端末による音声通信を実現する通信方法であって、前記ゲートウエイ装置内のピックアップ対応処理部が、前記音声通信対応端末への着信につづく呼び出しを契機として、前記音声通信非対応端末のユーザが応答したとき、その応答を検出し、当該ゲートウエイ装置内の音声転送処理部が、当該ピックアップ対応処理部が前記音声通信非対応端末のユーザからの応答を検出すると、本来、前記音声通信対応端末へ転送するべき音声通信用のデータを、当該音声通信非対応端末へ転送することを特徴とする。
【００１２】
さらにまた、音声通信のための呼制御機能を持たない音声通信非対応端末による音声通信を実現する通信システムの構成要素としてのゲートウエイプログラムにおいて、コンピュータに、（１）第１の通信プロトコルに対応するネットワークと、音声通信用の第２の通信プロトコルに対応する音声通信対応端末とのあいだでプロトコル変換を行うプロトコル変換機能と、（２）前記音声通信対応端末への着信につづく呼び出しを契機として、前記音声通信非対応端末のユーザが応答したとき、その応答を検出するピックアップ対応処理機能と、（３）当該ピックアップ対応処理機能が前記音声通信非対応端末のユーザからの応答を検出すると、本来、前記音声通信対応端末へ転送するべき音声通信用のデータを、当該音声通信非対応端末へ転送する音声転送処理機能とを実現させることを特徴とする。
【発明の効果】
【００１３】
本発明によれば、融通性および利便性を高める。
【発明を実施するための最良の形態】
【００１４】
（Ａ）実施形態
以下、本発明にかかる通信システム、ゲートウエイ装置、通信方法、およびゲートウエイプログラムをＶｏＩＰに適用した場合を例に、実施形態について説明する。
【００１５】
（Ａ−１）実施形態の構成
本実施形態にかかるＶｏＩＰシステム９の全体構成例を図１に示す。この接続関係自体は、図３に示したものと同じである。
【００１６】
図１において、当該ＶｏＩＰシステム９は、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）３０と、ＲＧＷ３１と、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）３２と、電話機３３，３４と、パソコン３５とを備えている。
【００１７】
このうちＷＡＮ３０には、インターネットや特定の通信事業者が運営するＩＰ網などが該当し得る。このＷＡＮ３０上では、ＯＳＩ参照モデルのネットワーク層のプロトコルとして、ＩＰプロトコルが用いられている。
【００１８】
ＲＧＷ３１は４つのインタフェースＰ１１〜Ｐ１４を備えている。各インタフェースには独立した物理ポートを含む。
【００１９】
４つのインタフェースＰ１１〜Ｐ１４のうちインタフェースＰ１１は、前記ＷＡＮ３０に接続される。同様に、インタフェースＰ１２は電話機３３に接続され、インタフェースＰ１３は電話機３４に接続され、インタフェースＰ１４はＬＡＮ３２に接続されている。
【００２０】
図示の例では、ＲＧＷ３１に２つの電話機３３，３４が接続されているが、ＲＧＷ３１に接続される電話機の数は１つであってもよく、３つ以上であってもよいことは当然である。
【００２１】
また、図示の例では、ＲＧＷ３１に１つのパソコン３５が接続されているが、ＲＧＷ３１に接続されるパソコン３５の数は複数であってもよいことは当然である。さらに、図示した通り、ＲＧＷ３１に接続されるパソコンが１つである場合、ＬＡＮ３２はいわゆるネットワークでなく、インタフェースＰ１４とパソコンＰ３５を１対１で接続する伝送路（ケーブルのような有線伝送路でもよく、電波や赤外線を用いる無線伝送路でもよい）に置換可能である。
【００２２】
前記電話機３３は、ＶｏＩＰ対応機能を持たない一般電話機である。この点は、電話機３４も同じである。電話機３３はユーザＵ３３によって利用され、電話機３４はユーザＵ３４によって利用されるものとする。
【００２３】
また、パソコン３５は、ＩＰプロトコルを処理するためのＩＰモジュールやＬＡＮカードを備えた通常のパソコンの機能に加え、ＶｏＩＰに対応した電話機（ＩＰ電話機）に近い機能を備えている。ただし、呼制御機能を持たない点で、通常のＩＰ電話機と相違する。
【００２４】
したがって当該パソコン３５の内部構成は例えば図１１に示すものとなる。当該パソコン３５は、ユーザＵ３５によって利用される。
【００２５】
（Ａ−１−１）パソコンの内部構成例
図１１において、当該パソコン３５は、通信部４０と、制御部４１と、操作部４２と、表示部４３と、記憶部４４と、接続処理部４５と、音声パス処理部４６と、音声コーデック部４７と、通話用ＵＩ部（通話用ユーザインタフェース部）４８とを備えている。
【００２６】
このうち構成要素４０〜４４は、基本的に通常のパソコンが備える構成要素である。
【００２７】
すなわち、通信部４０はＬＡＮ３２を経由した通信のために機能する部分である。例えば、前記ＬＡＮカードやＩＰモジュールなどもこの部分に該当し得る。
【００２８】
制御部４１は、ハードウエア的には当該パソコン３５のＣＰＵ（中央処理装置）に相当し、ソフトウエア的にはＯＳ（オペレーティングシステム）などの各種プログラムに相当する部分である。
【００２９】
操作部４２は、ユーザＵ３５が操作してパソコン３５に指示を伝える部分で、例えば、マウスなどのポインティングデバイスやキーボードなどを有する。
【００３０】
表示部４３は、パソコン３５が搭載するアプリケーションソフトやＯＳなどの機能に応じて画面表示を行うディスプレイ装置に対応する部分である。
【００３１】
記憶部４４はハードウエア的には、ＲＡＭ（ランダムアクセスメモリ）や、ハードディスクなどによって構成される記憶資源であり、ソフトウエア的には、各種のファイルがこの部分に含まれ得る。ＯＳなどのプログラムファイルもこのようなファイルの一つであるから、その物理的な実体は、この記憶部４４に位置する。
【００３２】
一方、構成要素４５〜４８はＩＰ電話特有の機能に対応する構成要素である。
【００３３】
すなわち、接続処理部４５は、パソコン３５から前記ＲＧＷ３１にＶｏＩＰによる音声通話のための接続を要求したり、切断を要求したりする場合に機能する部分である。具体的には、パソコン３５に対し、ユーザＵ３５がオフフック操作を行ったことを検知したとき、当該接続処理部４５は接続を要求し、オンフック操作を行ったことを検知したときには、切断を要求する。
【００３４】
音声パス処理部４６は、パソコン３５とＲＧＷ３１のあいだに音声の論理パスを構築する部分である。
【００３５】
音声コーデック部４７は、ユーザＵ３５が発話した音声に応じた音声データをエンコードする場合や、通話相手側が発話した音声に応じた音声データをデコードする場合に機能する部分である。エンコードによって得られた符号化音声データは、音声パケット（ペイロード部分にＲＴＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）ヘッダを含むＩＰパケット）に収容されて当該パソコン３５から送信される。また、デコードの対象となる符号化音声データは、図示しない通話相手側の通信装置（例えば、ＩＰ電話機など）が送信し、前記ＲＧＷ３１経由で当該パソコン３５に受信された音声パケットから取り出したものである。
【００３６】
通話用ＵＩ部４８は、ユーザＵ３５が発話した音声を集音するためのマイクや、通話相手が発話した音声を出力してユーザＵ３５に聴取させるためのスピーカなどを含む部分で、ＩＰ電話に特有なユーザインタフェースである。ユーザＵ３５によるオンフックやオフフックを検知するためのユーザインタフェースは、前記操作部４２に設けるようにしてもよいが、当該通話用ＵＩ部４８に設けるようにしてもよい。
【００３７】
なお、必要に応じて、当該パソコン３５が、ＲＧＷ３５に各種の設定を行うためのコンソール端末としての機能を搭載していてもよいことは当然である。
【００３８】
次に、前記ＲＧＷ３１の内部構成は例えば図４に示す通りである。
【００３９】
（Ａ−１−２）ＲＧＷの内部構成例
図４において、当該ＲＧＷ３１は、状態制御部５０と、ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）プロトコル処理部５１と、音声パケット送受信部５２と、ＳＬＩＣ（Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ  Ｉｎｔｅｒｆａｃｅ  Ｃｉｒｃｕｉｔ）制御部５３と、ピックアップ制御部５４と、音声転送部５５とを備えている。
【００４０】
このうちＳＩＰプロトコル処理部５１は、呼制御プロトコルの１つであるＳＩＰプロトコルを処理する機能を有する部分で、ＶｏＩＰの着信を受けたり、発信を行うのは、このＳＩＰプロトコル処理部５１である。本発明は、ＳＩＰ以外の呼制御プロトコル（ＩＴＵ−Ｔ勧告Ｈ．３２３、ＭＧＣＰなど）を用いることも可能であるが、ここでは、ＳＩＰを想定する。
【００４１】
状態制御部５０は、当該ＲＧＷ３１の配下にある各端末（図１の例では、３３，３４，３５）の通信状態を制御する部分である。
【００４２】
ＳＬＩＣ制御部５３は、公衆電話網（ＰＳＴＮ）における加入者回路に対応する機能を持つ部分で、電話機（３３，３４）への呼び出しを行ったり、電話機のダイヤル、オンフック、オフフックを検出する。
【００４３】
音声パケット送受信部５２は、ＷＡＮ３０とのあいだで音声パケットの送受信を行う部分である。例えば、ＷＡＮ３０側のＩＰ電話機を操作する通話相手と電話機３３のユーザＵ３３が通話する場合、ＷＡＮ３０側から届いた音声パケットから符号化音声データを取り出したり、ＷＡＮ３０側へ届けるために、電話機３３側から届いた音声信号のエンコード結果を符号化音声データとして音声パケットに収容するのが、当該音声パケット送受信部５２である。この際、必要に応じて、前記ＲＴＰヘッダに関する処理を実行する。
【００４４】
ＲＴＰヘッダに関する処理としてどのような処理を実行するかは、実装に依存するが、例えば、ＲＴＰヘッダに含まれるタイムスタンプをもとに、遅延の大きな音声パケットを廃棄すること等がこの処理の内容となり得る。ただし、このようにＲＴＰヘッダ中の制御情報を用いた処理のほかに、ＲＴＰヘッダ自体の付加や削除なども、この処理に含まれ得る。ＲＴＰヘッダの付加はＷＡＮ３０側へ送信する場合に行われ、ＲＴＰヘッダの削除は、ＷＡＮ３０側から受信した場合に行われる。
【００４５】
前記パソコン３５がこのようなＲＴＰヘッダに関する処理を実行する機能を搭載していない場合、パソコン３５による後述のピックアップが行われ、ＷＡＮ３０側の通話相手とパソコン３５のユーザＵ３５が通話するときには、ＲＴＰヘッダに関する処理をＲＧＷ３１が行う必要があるが、ここでは、搭載しているものとする。パソコン３５がＲＴＰヘッダに関する処理を実行する機能を搭載している場合には、ＶｏＩＰ通信に必要な機能は、前記呼制御機能以外、すべて当該パソコン３５に搭載されていることになるため、呼の設定が行われたあと、通話がはじまると、ＲＧＷ３１は前記音声パケットをＷＡＮ３０とパソコン３５のあいだで中継するだけでよい。
【００４６】
これらの構成要素５０〜５３は通常のＲＧＷも搭載するが、残りの構成要素５４，５５は本実施形態のＲＧＷ３１に特有なものである。
【００４７】
ピックアップ制御部５４は、パソコン３５のユーザＵ３５による上述したピックアップを実現する部分である。具体的には、ユーザＵ３５が上述したピックアップを行うためにパソコン３５をオフフックし、前記接続処理部４５から接続要求が届いた場合、その接続要求に応えてピックアップを可能にする。
【００４８】
音声転送部５５は、当該ピックアップが行われたとき、ＲＧＷ３１とパソコン３５のあいだで、前記音声パケットの送受を行う部分である。このピックアップが行われたときには、ＲＧＷ３１が、ＷＡＮ３０とパソコン３５のあいだで音声パケットの中継を行う必要があるが、その中継のうちパソコン３５に対する部分は当該音声転送部５５が分担し、ＷＡＮ３０に対する部分は、前記音声パケット送受部５２が分担する。この中継には、ＷＡＮ３０側から届いた音声パケットをＬＡＮ３２経由でパソコン３５へ転送する処理と、パソコン３５からＬＡＮ３２経由で届いた音声パケットをＷＡＮ３０側へ転送する処理が含まれる。
【００４９】
以下、上記のような構成を有する本実施形態の動作について、図５〜図１０のシーケンス図を参照しながら説明する。
【００５０】
図５は、ＷＡＮ３０側からＲＧＷ３１へ着信した場合の一般的な処理（パソコン３５によるピックアップは行われないケース）の手順を示すシーケンス図で、Ｓ１０〜Ｓ１８の各ステップを備えている。
【００５１】
これに対し図６は、ＷＡＮ３０側からＲＧＷ３１へ着信した場合に、パソコン３５によるピックアップが行われるケースの手順を示すシーケンス図である。図６のシーケンス図は、Ｓ１０〜Ｓ２５の各ステップを備えている。
【００５２】
図７は、ピックアップを行うためにパソコン３５から前記接続を要求する場合の処理の手順を示すシーケンス図で、Ｓ３０〜Ｓ３７の各ステップを備えている。図８は、当該ピックアップが行われ、呼が設定され通話が行われたあとで、パソコン３５側から前記切断を要求する場合の処理の手順を示すシーケンスで、Ｓ４０〜Ｓ４５の各ステップを備えている。図９は、当該ピックアップが行われ、呼が設定され通話が行われたあとで、ＷＡＮ３０側（通話相手側）から前記切断を要求する場合の処理の手順を示すシーケンスで、Ｓ５０〜Ｓ５５の各ステップを備えている。
【００５３】
図１０は、パソコン３５による前記ピックアップが行われた場合の、パケットの流れや、ポート番号などを示すシーケンス図で、Ｓ３４〜Ｓ６４の各ステップを備えている。
【００５４】
（Ａ−２）実施形態の動作
図５において、ＷＡＮ３０側のＩＰ電話機から、図示しないＳＩＰサーバを経由して電話機３３，３４を着信先とする呼設定要求メッセージがＲＧＷ３１に着信すると、その着信をＲＧＷ３１内の前記ＳＩＰプロトコル処理部５１が受け（Ｓ１０）、当該ＳＩＰプロトコル処理部５１が前記状態制御部５０に着信を通知する（Ｓ１１）。
【００５５】
これにより、当該状態制御部５０がＳＬＩＣ制御部５３に呼び出し指示を出すので（Ｓ１２）、ＳＬＩＣ制御部５３が該当する電話機３３（および／または３４）を呼び出す（Ｓ１３）。
【００５６】
なお、前記ステップＳ１０の着信は、電話機３３，３４の双方（双方が属するグループ）を着信先とするものであってもよく、いずれか一方を着信先とするものであってもよい。双方を着信先とする場合には、呼び出しは電話機３３と３４の双方で行われ得るが、いずれか一方を着信先とする場合には、該当する電話機のみで行われる。ただし以下では、少なくとも電話機３３で呼び出しが行われているものとする。
【００５７】
前記ステップＳ１３の呼び出しに対し、電話機３３のユーザＵ３３が電話機３３をオフフックして応答すると（Ｓ１４）、ＳＬＩＣ制御部５３から状態制御部５０へ応答通知が供給され（Ｓ１５）、状態制御部５０からＳＩＰプロトコル処理部５１に応答通知が供給される（Ｓ１６）。
【００５８】
前記ステップＳ１６の応答通知を受けると、ＳＩＰプロトコル処理部５１は、前記呼設定要求メッセージに応える応答メッセージを返送する（Ｓ１７）。この応答メッセージがＳＩＰサーバを経由して、ＷＡＮ３０側のＩＰ電話機に届けられることで、エンド−エンドの電話機間に呼が設定され、ＩＰ電話機側の通話相手と電話機３３のユーザＵ３３の通話が可能となる。
【００５９】
電話機３３はＶｏＩＰ対応機能をいっさい持たないため、前記音声パケットを送受してこの通話を成立させるためには、ＲＧＷ３３内の前記音声パケット送受信部５２の機能が必要となるから、状態制御部５０は、当該音声パケット送受信部５２に動作の開始を指示する（Ｓ１８）。
【００６０】
これにより、ＷＡＮ３０側の通話相手とユーザＵ３３のあいだの通話が可能となる。
【００６１】
一方、前記パソコン３５を操作してユーザＵ３５がピックアップを行う場合には、図６に示すような処理手順となる。図６中のステップＳ１０〜Ｓ１３の処理は、同じ符号Ｓ１０〜Ｓ１３を付与した図５中の各ステップと同じであるので、その詳しい説明は省略する。
【００６２】
前記ステップＳ１３により電話機３３は呼び出し音などを発するようになるため、ユーザＵ３５はこの呼び出し音などをもとに、呼び出しを認識して、パソコン３５に対してオフフックの操作を行う。このオフフックを検知すると、図６に示すように、パソコン３５が前記ＲＧＷ３１の状態制御部５０に応答通知を行う（Ｓ２０）。この応答通知の意味は、前記ステップＳ１５の応答通知に等しいが、ＬＡＮ３２経由でＩＰパケットを用いて通知される点は相違する。
【００６３】
ステップＳ２０の応答通知を受けた状態制御部５０は、ＳＩＰプロトコル処理部５１に応答通知を供給し（Ｓ２１）、ＳＩＰプロトコル処理部５１がＷＡＮ３０側の前記ＳＩＰサーバへ応答メッセージを返送する（Ｓ２２）。ここで、当該ステップＳ２１は前記ステップＳ１６に対応し、当該ステップＳ２２は前記ステップＳ１７に対応するので、その詳しい説明は省略する。
【００６４】
前記ステップＳ２０の応答通知を受けた状態制御部５０は、前記ステップＳ２１を実行するとともに、呼び出し停止指示をＳＬＩＣ制御部５３に供給する（Ｓ２３）。これによりＳＬＩＣ制御部５３は、前記ステップＳ１３の呼び出しを停止するので、電話機３３は呼び出し音の出力を停止する。
【００６５】
次に、当該状態制御部５０は、前記音声パケット送受信部５２と音声転送部５５に動作の開始を指示する（Ｓ２４，Ｓ２５）。前記音声パケットが、ＷＡＮ３０とパソコン３５のあいだで中継されるようになって、ＷＡＮ３０側の通話相手とユーザＵ３５のあいだの通話が可能となる。これは、図１０のステップＳ６１〜Ｓ６４に対応するものである。ただし図１０の場合、ＲＧＷ３１で上述したＲＴＰヘッダに関する処理を行って、ＷＡＮ３０側から届いた音声パケット（ＲＴＰパケット）は、ＲＴＰヘッダを削除した上でパソコン３５へ届けられている。反対に、パソコン３５から送信されたＩＰパケットにはＲＴＰヘッダが含まれていないため（Ｓ６３）、ＲＧＷ３１内でＲＴＰヘッダを付加する処理を行った上で、ＷＡＮ３０へ送信している。
【００６６】
図６で行われた一連の処理を、メソッド名や応答コードなどに着目して表現したものが図７のシーケンス図である。
【００６７】
図７において、ステップＳ３０でＷＡＮ３０側から届いた呼設定要求メッセージ中のＩＮＶＩＴＥは、接続（セッション）の開始を要求するメソッドであり、前記ステップＳ１０に対応する。
【００６８】
「１００  ｔｒｙｉｎｇ」などは、（応答コード  理由文）の書式となっている。理由文はその応答コード（ここでは、１００）の意味を示す文字列であり、ここでは、ｔｒｙｉｎｇ（すなわち、試行中）であることを示している。
【００６９】
ＲＧＷ３１から「１００  ｔｒｙｉｎｇ」を返すステップＳ３１に対応するステップは、図６では図示を省略していたものである。
【００７０】
前記ＩＮＶＩＴＥを含む呼設定要求メッセージには、着信先を指定する識別子（着信先電話番号に対応するＩＰアドレス）も含まれているため、その識別子に該当する端末が配下に存在する場合、ＲＧＷ３１は、該当端末（例えば、電話機３３）を呼び出すとともに、「１８０  ｒｉｎｇｉｎｇ」を返送して呼び出し中であること発呼側に伝える（Ｓ３２，Ｓ３３）。
【００７１】
ここで、前記ユーザＵ３５が、前記ユーザＵ３３が電話機３３をオフフックするより前に、ピックアップのためパソコン３５をオフフックすると、当該パソコン３５の接続処理部４５が、前記接続要求を送信するので（Ｓ３４）、その接続要求に応えて、ＲＧＷ３１（のピックアップ制御部５４）が、前記状態制御部５０に、電話機３３に対する呼び出しを停止させるとともに、発呼側に「２００  ＯＫ」（呼設定の要求が受け入れられたことを示す応答コードと理由文）を含む応答メッセージを返送する（Ｓ３６，Ｓ３５）。
【００７２】
ステップＳ３４の接続要求には、通話相手のＩＰ電話機に伝えるため、図１０に示すように、パソコン３５側のポート番号（ここでは、１５００４）が含まれている。ＶｏＩＰではポート番号は動的に変更される。また、図７などでは省略しているが、図１０に示すように、ステップＳ３４の接続要求を受信すると、ＲＧＷ３１から、その接続要求を受け入れるとともに通話相手のＩＰ電話機のポート番号（ここでは、１５０１０）を伝えるメッセージがパソコン３５まで届く（Ｓ６０）。このポート番号は、前記ステップＳ３０でＲＧＷ３１に届いた呼設定要求メッセージなどに収容されて、通話相手のＩＰ電話機からＲＧＷ３１に伝えられていたものである。
【００７３】
上述したようにＶｏＩＰではポート番号が動的に変更されるため、もしも、パソコン３５のようなパソコンがＬＡＮ３２内に複数存在する場合などには、ＲＧＷ３１は、（ＩＰアドレスなどとともに、）このポート番号を利用してセッションを識別することもできる。
【００７４】
また、前記ステップＳ３４とＳ６０でポート番号を伝え合うため、これらのポート番号を宛先ポート番号および送信元ポート番号として含むＵＤＰヘッダは、ＲＧＷ３１側で生成することもパソコン３５側で生成することも可能である。このＵＤＰヘッダは、前記音声パケットをＲＧＷ３１からＷＡＮ３０側へ送出するときまでには、音声パケット（ＩＰパケット）内に付加されている必要がある。通常、ＲＴＰヘッダを用いるリアルタイム通信では、ＯＳＩ参照モデルのトランスポート層プロトコルとして、ＵＤＰプロトコルを使用するため、当該ＵＤＰヘッダが必要となる。
【００７５】
さらに当該ピックアップ制御部５４は、ＲＧＷ３１内の音声転送部５５や音声パケット送受信部５２を、ＷＡＮ３０とパソコン３５のあいだで音声パケットの中継が可能な状態にして、接続要求の送信元であるパソコン３５に、ＯＫを返送してその接続要求が受け入れられたことを伝える（Ｓ３７）。
【００７６】
このあと、前記音声パケットが、ＷＡＮ３０とパソコン３５のあいだで中継されるようになって、ＷＡＮ３０側の通話相手とユーザＵ３５のあいだの通話が可能となることはすでに説明した通りである。
【００７７】
ピックアップ後の通話が終わると、ユーザＵ３５または通話相手が切断することになるが、ユーザＵ３５から先に切断した場合の処理手順を示す図８において、パソコン３５がユーザＵ３５のオンフックを検知すると、前記パソコン３５の接続処理部４５から切断要求が出されるため（Ｓ４０）、これを受けたＲＧＷ３１では、ＷＡＮ３０側に「ＢＹＥ」（セッションの終了を要求するメソッド）を含むメッセージを送信するとともに、パソコン３５にはその切断要求が受け入れられたことを伝えるメッセージ（ＯＫ）を返送する（Ｓ４１，Ｓ４２）。
【００７８】
つづいて、ＷＡＮ３０側からセッションの終了要求を受け入れる旨のメッセージが届き（Ｓ４３）、ＲＧＷ３１がそのメッセージを受け取ったことを伝えるメッセージ（「ＡＣＫ」）を返送して一連の処理が終了する（Ｓ４３）。
【００７９】
ＷＡＮ３０側の通話相手が先に切断を要求した場合の処理手順を示す図９の各ステップは、図８の各ステップと対称な関係にある。
【００８０】
すなわち図９では、図８と反対に、ＷＡＮ３０側からＲＧＷ３１に「ＢＹＥ」を含むメッセージが届き（Ｓ５０）、以降は、ＲＧＷ３１から「２００  ＯＫ」を返送し（Ｓ５２）、ＷＡＮ２０側から「ＡＣＫ」を受け取ることになる（Ｓ５３）。
【００８１】
ただし、ステップＳ５０とＳ５２のあいだには、ＲＧＷ３１から、まだオンフックしていないパソコン３５のユーザＵ３５に終了トーンを伝えるためのステップＳ５１が実行される。
【００８２】
また、前記ステップＳ５３につづくステップＳ５４では、前記終了トーンを聴取したユーザＵ３５がオンフックしたことによりパソコン３５から切断要求が送信され、次のステップＳ５５ではＲＧＷ３１がその要求を受け入れて一連の処理が終了する。  
（Ａ−３）実施形態の効果
本実施形態によれば、直接、パソコンから発信したり、パソコンに着信したりすることはできないものの、呼制御機能を搭載していないパソコン（３５）であっても、ピックアップにより着信を受けることができる。
【００８３】
これにより、当該パソコン（３５）を、ピックアップ専用の電話機（擬似電話機）として利用することが可能となり、融通性および利便性が向上する。
【００８４】
（Ｂ）他の実施形態
上記実施形態にかかわらず、ＲＧＷ３１はＰＳＴＮを収容してもよい。
【００８５】
なお、上記実施形態で、パソコン３５に設けた構成要素のうち音声コーデック部４７の少なくとも一部は省略できる可能性がある。
【００８６】
サンプリングや量子化およびその逆変換にあたる処理などをパソコン３５側で行い、量子化結果などをエンコードして符号化音声データを生成する処理や、符号化音声データをデコードする処理などは、ＲＧＷ３１側で実行するようにしてもよい。
【００８７】
また、上記実施形態では、着信をピックアップによってパソコン３５で受けたが、例えば、着信後、すでに呼が設定され通話（ＷＡＮ３０側の通話相手と例えば電話機３３のユーザＵ３３による通話）が行われている途中であっても、その通話を、例えば、ユーザＵ３３が電話機３３側からパソコン３５側に移動し、パソコン３５を用いて通話のつづきを行うこと等も可能である。このとき電話機３３は、保留ボタンがある場合には保留ボタンを押し、ない場合には、オフフックしたままであってもよい。また、パソコン３５側で行う操作は、上記実施形態で接続要求を出した場合と同じであってよい。ＷＡＮ３０上のＳＩＰサーバには、ＲＧＷ３１の配下で、このような端末の切替えが行われたことを伝えず、パソコン３５をオンフックしたときにＷＡＮ３０側の通話相手とのセッションが切断されるものであってよい。
【００８８】
また、上記実施形態にかかわらず、ＲＧＷ３１にＳＩＰプロキシの機能を持たせること等により、音声だけでなく、映像も含んだリアルタイム通信を実現することも可能である。
【００８９】
さらに、上記実施形態で例示した通信プロトコルは他の通信プロトコルに置換可能である。
【００９０】
例えば、呼制御プロトコルをＳＩＰプロトコルに限定する必要がないことは、すでに述べた通りである。また、ＩＰプロトコルは、ＯＳＩ参照モデルのネットワーク層またはその他の階層に位置する他の通信プロトコルに置換可能である。一例として、ＩＰＸプロトコルなどを利用できる可能性もある。
【００９１】
以上の説明でハードウエア的に実現した機能の大部分はソフトウエア的に実現することが可能であり、ソフトウエア的に実現した機能のほとんど全ては、ハードウエア的に実現することが可能である。
【図面の簡単な説明】
【００９２】
【図１】実施形態にかかるＶｏＩＰシステムの全体構成例を示す概略図である。
【図２】従来のピックアップを説明するための構成を示す概略図である。
【図３】発明が解決しようとする課題を説明するための構成を示す概略図である。
【図４】実施形態にかかるＶｏＩＰシステムで使用するＲＧＷの主要部の構成例を示す概略図である。
【図５】実施形態の動作例を示すシーケンス図である。
【図６】実施形態の動作例を示すシーケンス図である。
【図７】実施形態の動作例を示すシーケンス図である。
【図８】実施形態の動作例を示すシーケンス図である。
【図９】実施形態の動作例を示すシーケンス図である。
【図１０】実施形態の動作例を示すシーケンス図である。
【図１１】実施形態にかかるＶｏＩＰシステムで使用するパソコンの構成例を示す概略図である。
【符号の説明】
【００９３】
９…ＶｏＩＰシステム、３０…ＷＡＮ、３１…ＲＧＷ、３２…ＬＡＮ、３３，３４…電話機、３５…パソコン、４５…接続処理部、４６…音声パス処理部、４７…音声コーデック部、４８…通話用ＵＩ部。
【図１】
2005244772.tif 000003
【図２】
2005244772.tif 000004
【図３】
2005244772.tif 000005
【図４】
2005244772.tif 000006
【図５】
2005244772.tif 000007
【図６】
2005244772.tif 000008
【図７】
2005244772.tif 000009
【図８】
2005244772.tif 000010
【図９】
2005244772.tif 000011
【図１０】
2005244772.tif 000012
【図１１】
2005244772.tif 000013