(57)【特許請求の範囲】
【請求項１】
通話サーバと、複数の通話端末とがネットワークで接続され、特定の通話端末の音声が、通話サーバとセッションを確立している各通話端末へ送信される多者間通話システムにおいて、
前記通話端末が、
音声が入力される音声入力手段と、
前記音声入力手段に入力された音声の大きさが、設定値よりも大きいか否かを判断する
入力音声判断手段と、
前記入力音声判断手段により入力された音声が設定値よりも大きい場合、前記通話サー
バへミキシング要求を行い、前記通話サーバから応答を受信してミキシング状態を確立す
るミキシング状態確立手段と、
前記ミキシング状態確立手段により前記通話サーバとのミキシング状態が確立した後、
前記音声入力手段で入力された音声をパケット化して前記通話サーバへ送信する第1の音
声パケット送信手段とを有し、
前記通話サーバが、
前記ミキシング要求を行った通話端末へ応答を送信し、ミキシング制御対象として記録
するミキシング制御対象記録手段と、
前記ミキシング制御対象記録手段により記録した当該通話端末から送信された音声パケ
ットを、セッションを確立している他の通話端末へ送信する第２ の音声パケット送信手段とを有する
ことを特徴とする多者間通話システム
【請求項２】
前記通話端末が、
前記入力音声判断手段により、入力された音声が設定値よりも小さい場合、設定値より
も小さい音声入力が何回連続しているかを記憶する回数記憶手段と、
前記回数記憶手段で記憶された、設定値よりも小さい音声入力回数が所定回数以上連続
していた場合、前記通話サーバへミキシング切断要求を行い、前記通話サーバからの応答
を受信してミキシング状態を切断するミキシング状態切断手段とを更に有し、
前記通話サーバが、
前記ミキシング状態切断手段によりミキシングの切断要求を行った通信端末へ応答を送
信し、ミキシング制御対象から削除するミキシング制御対象削除手段とを更に有する
ことを特徴とする請求項１ 記載の多者間通話システム。
【請求項３】
前記通話端末が、前記通話サーバへセッション開始要求メッセージを送信し、前記通話サーバが該セッション開始要求メッセージに対するセッション開始応答メッセージを送信することで、前記通話端末と前記通話サーバとのセッションを確立することを特徴とする請求項１ または２ 記載の多者間通話システム。
【請求項４】
前記通話端末が、前記通話サーバへセッション切断要求メッセージを送信し、前記通話サーバが該セッション切断要求メッセージに対するセッション切断応答メッセージを送信することで、前記通話端末と前記通話サーバとのセッションを切断することを特徴とする請求項１ または２ 記載の多者間通話システム。
【請求項５】
通話サーバと、複数の通話端末とがネットワークで接続され、特定の通話端末の音声が、通話サーバとセッションを確立している各通話端末へ送信される多者間通話システムにおける通話端末において、
音声が入力される音声入力手段と、
前記音声入力手段に入力された音声の大きさが、設定値よりも大きいか否かを判断する
入力音声判断手段と、
前記入力音声判断手段により入力された音声が設定値よりも大きい場合、前記通話サー
バへミキシング要求を行い、前記通話サーバからの応答を受信してミキシング状態を確立
するミキシング状態確立手段と、
前記ミキシング状態確立手段により前記通話サーバとのミキシング状態が確立した後、
前記音声入力手段で入力された音声をパケット化して前記通話サーバへ送信する第1の音
声パケット送信手段と
を有することを特徴とする通話端末。
【請求項６】
前記入力音声判断手段により、入力された音声が設定値よりも小さい場合、設定値よりも小さい音声入力が何回連続しているかを記憶する回数記憶手段と、
前記回数記憶手段で記憶された、設定値よりも小さい音声入力回数が所定回数以上連続
していた場合、前記通話サーバへミキシング切断要求を行い、前記通話サーバからの応答
を受信してミキシング状態を切断するミキシング状態切断手段とを更に有することを特徴とする請求項５ 記載の通話端末。
【請求項７】
通話サーバと、複数の通話端末とがネットワークで接続され、特定の通話端末の音声が、通話サーバとセッションを確立している各通話端末へ送信される多者間通話方法において、
前記通話端末が、
音声が入力されるステップと、
入力された音声の大きさが、設定値よりも大きいか否かを判断するステップと、
入力された音声が設定値よりも大きい場合、前記通話サーバへミキシング要求を行い、
前記通話サーバからの応答を受信してミキシング状態を確立するステップと、
前記通話サーバとのミキシング状態が確立した後、前記音声入力手段で入力された音声
をパケット化して前記通話サーバへ送信するステップとを有し、
前記通話サーバが、
ミキシング要求を行った通話端末へ応答を送信し、ミキシング制御対象として記録する
ステップと、
記録した当該通話端末から送信された音声パケットを、セッションを確立している他の
通話端末へ送信するステップとを有する
ことを特徴とする多者間通話方法。
【請求項８】
前記通話端末が、
入力された音声が設定値よりも小さい場合、設定値よりも小さい音声入力が何回連続し
ているかを記憶するステップと、
記憶された設定値よりも小さい音声入力回数が所定回数以上連続していた場合、前記通
話サーバへミキシング切断要求を行い前記通話サーバからの応答を受信してミキシング状
態を切断するステップとを更に有し、
前記通話サーバが、
ミキシングの切断要求に対する応答を送信した通話端末を、ミキシング制御対象から削
除するステップとを更に有する
ことを特徴とする請求項９ 記載の多者間通話方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の通話端末で多者間通話を行う多者間通話システム、多者間通話システムにおける通話端末および通話サーバ、多者間通話方法に関する。
【背景技術】
【０００２】
IP(Internet Protocol)電話における応用サービスの一つとして多者間通話がある。多者間通話とは、多人数が同時に通話を行うサービスである。回線交換網では以前からMultipoint Conference Unit(MCU)と呼ばれる専用の機器を用いて電話会議等の多者間通話を行うことは可能であったが、この機器は高価であり、かつ通信業者のサービスでは無いため機器を所有している特定のコミュニティ向けのサービスであった。これに対してIP電話では、ソフトウェアベースでサービスを提供する事が可能であるため、一般利用者に対してもサービスの提供を行うことが可能である。
【０００３】
IP電話における多者間通話サービスには、主に２種類のサービスの提供形態がある。
一つは、ユーザ端末に多者間通話用の機能を新規に追加し、ユーザ同士が連携することでサービスを受ける形態である。この形態は、機能を有する端末を所有するユーザのみがサービスを受けることができるため、汎用性に乏しい。
もう一つは、サーバでサービスを提供する形態である。この形態では、サーバに負荷が集中するものの、ユーザの使い勝手が向上し、サービス提供業者の課金管理などが容易になる。
【０００４】
多者間通話サービスにおいて、IP電話の場合、対象に対して電話をかける「シグナリング」機能と、シグナリングにより相手と通話できることが確定した後に音声を送信する「全２重音声伝送」機能が必要となる。これらの機能は通常1対1の通信用である。
【０００５】
シグナリング機能では、端末（Ａ、Ｂ、Ｃ）がそれぞれ多者間通話サーバに対して電話をかける。こうすることにより、見かけ上、Ａは多者間通話サーバと１対１セッションを張っているだけであるが、サーバは他のユーザ（Ｂ、Ｃ）ともセッションを張っているため、Ａ、Ｂ、Ｃはサーバを介して仮想的にマルチセッションを張っていることになる。
【０００６】
全２重音声伝送機能における「全２重」とは、自身の音声と相手の音声を同時に扱う事を意味する。全２重音声伝送機能では、ユーザから送信された音声を適切にミキシングし、複数の音声ストリームを一つのストリームに圧縮し、送出する。この全２重音声伝送機能を用いて複数の音声ストリームをやり取りすることが可能になる。
【０００７】
通話サーバを用いた従来のデジタル音声ミキシングシステムとして、「全参加者ミキシング」がある。これは複数の端末からの音声ストリームを通話サーバで受信して、各端末からの音声サンプルを重ね合わせるなどの手法により、ミキシングを行う。次に、ミキシング結果の音声ストリームをすべての端末に向けて送信することで多者間通話を実現する。このとき、通話サーバから全端末に送信される音声ストリームのうち、端末iから通話サーバへ送信された音声を端末iに返す場合については、音声がエコーとなって聞こえるのを防ぐため、自身の音声を差し引くことが知られている（非特許文献１参照）。
【０００８】
各端末ではマイクからの音声入力の有無によらず、通話サーバに音声ストリームを送り続ける。ただし、無音圧縮機能を有する端末の場合は、無音区間は音声パケットを送信しないで、クロックだけをカウントしておく。
【非特許文献１】Internet Telephony Workshop 2001「Centralized Conferencing using SIP」(2001.4)
【発明の開示】
【発明が解決しようとする課題】
【０００９】
多者間通話サーバを介するサービスでは、通話サーバにおける処理遅延が上乗せされる。ミキシングでは、波形の重ね合わせを行う場合、音声が8kHzサンプリングでは2つのストリームをミキシングする際に8000回/秒の処理を必要とする。また、ミキシングすべき端末の数に比例して処理量が大きくなる。
全参加者ミキシング方式は通話サーバに負荷が集中するため、通話サーバでミキシング可能な最大ストリーム数には限界がある。また通話サーバでは、端末からの音声データ送信があってもなくても、音声ストリームが来ているものとして、ミキシング処理をしていた。このため、端末数が多くなると、通話サーバの処理量が増大するという問題があった。また、無音区間があっても、次にいつ有音パケットが来るか予測できないので、上記無音圧縮機能を備えていても、通話サーバでミキシングすべき音声ストリーム数が減るわけではなかった。
【００１０】
本発明は、このような従来の手法が有している問題を解決しようとするものであり、複数の通話端末からの音声ストリームを高効率にミキシングを行う多者間通話システム、多者間通話システムにおける通話端末および通話サーバ、多者間通話方法を実現することを目的とする。
【課題を解決するための手段】
【００１１】
上記した目的を達成するために、請求項１記載の多者間通話システムは、通話サーバと、複数の通話端末とがネットワークで接続され、特定の通話端末の音声が、通話サーバとセッションを確立している各通話端末へ送信される多者間通話システムにおいて、前記通話端末が、音声が入力される音声入力手段と、前記音声入力手段に入力された音声の大きさが、設定値よりも大きいか否かを判断する入力音声判断手段と、前記入力音声判断手段により入力された音声が設定値よりも大きい場合、前記通話サーバへミキシング要求を行い、前記通話サーバから応答を受信してミキシング状態を確立するミキシング状態確立手段と、前記ミキシング状態確立手段により前記通話サーバとのミキシング状態が確立した後、前記音声入力手段で入力された音声をパケット化して前記通話サーバへ送信する第1の音声パケット送信手段とを有し、前記通話サーバが、前記ミキシング要求を行った通話端末へ応答を送信し、ミキシング制御対象として記録するミキシング制御対象記録手段と、前記ミキシング制御対象記録手段により記録した当該通話端末から送信された音声パケットを、セッションを確立している他の通話端末へ送信する第２の音声パケット送信手段とを有することを特徴とする。
【００１２】
請求項２記載の発明は、請求項１記載の多者間通話システムにおいて、前記通話端末が、前記入力音声判断手段により、入力された音声が設定値よりも小さい場合、設定値よりも小さい音声入力が何回連続しているかを記憶する回数記憶手段と、前記回数記憶手段で記憶された、設定値よりも小さい音声入力回数が所定回数以上連続していた場合、前記通話サーバへミキシング切断要求を行い、前記通話サーバからの応答を受信してミキシング状態を切断するミキシング状態切断手段とを更に有し、前記通話サーバが、前記ミキシング状態切断手段によりミキシングの切断要求を行った通信端末へ応答を送信し、ミキシング制御対象から削除するミキシング制御対象削除手段とを更に有することを特徴とする。
【００１３】
請求項３記載の発明は、請求項１または２記載の多者間通話システムにおいて、前記通話端末が、前記通話サーバへセッション開始要求メッセージを送信し、前記通話サーバが該セッション開始要求メッセージに対するセッション開始応答メッセージを送信することで、前記通話端末と前記通話サーバとのセッションを確立することを特徴とする。
【００１４】
請求項４記載の発明は、請求項１または２記載の多者間通話システムにおいて、前記通話端末が、前記通話サーバへセッション切断要求メッセージを送信し、前記通話サーバが該セッション切断要求メッセージに対するセッション切断応答メッセージを送信することで、前記通話端末と前記通話サーバとのセッションを切断することを特徴とする。
【００１５】
請求項５記載の通話端末は、通話サーバと、複数の通話端末とがネットワークで接続され、特定の通話端末の音声が、通話サーバとセッションを確立している各通話端末へ送信される多者間通話システムにおける通話端末において、音声が入力される音声入力手段と、前記音声入力手段に入力された音声の大きさが、設定値よりも大きいか否かを判断する入力音声判断手段と、前記入力音声判断手段により入力された音声が設定値よりも大きい場合、前記通話サーバへミキシング要求を行い、前記通話サーバからの応答を受信してミキシング状態を確立するミキシング状態確立手段と、前記ミキシング状態確立手段により前記通話サーバとのミキシング状態が確立した後、前記音声入力手段で入力された音声をパケット化して前記通話サーバへ送信する第1の音声パケット送信手段とを有することを特徴とする。
【００１６】
請求項６記載の発明は、請求項５記載の通話端末において、前記入力音声判断手段により、入力された音声が設定値よりも小さい場合、設定値よりも小さい音声入力が何回連続しているかを記憶する回数記憶手段と、前記回数記憶手段で記憶された、設定値よりも小さい音声入力回数が所定回数以上連続していた場合、前記通話サーバへミキシング切断要求を行い、前記通話サーバからの応答を受信してミキシング状態を切断するミキシング状態切断手段とを更に有することを特徴とする。
【００１７】
請求項７記載の通話サーバは、通話サーバと、複数の通話端末とがネットワークで接続され、特定の通話端末の音声が、通話サーバとセッションを確立している各通話端末へ送信される多者間通話システムにおける通話サーバにおいて、ミキシング要求を行った通話端末へ応答を送信し、ミキシング制御対象として記録するミキシング制御対象記録手段と、前記ミキシング制御対象記録手段により記録した当該通話端末から送信された音声パケットを、セッションを確立している他の通話端末へ送信する第２の音声パケット送信手段とを有することを特徴とする。
【００１８】
請求項８記載の発明は、請求項７記載の通話サーバにおいて、ミキシングの切断要求を行った通話端末を、ミキシング制御対象から削除するミキシング制御対象削除手段を更に有することを特徴とする。
【００１９】
請求項９記載の多者間通話方法は、通話サーバと、複数の通話端末とがネットワークで接続され、特定の通話端末の音声が、通話サーバとセッションを確立している各通話端末へ送信される多者間通話方法において、前記通話端末が、音声が入力されるステップと、入力された音声の大きさが、設定値よりも大きいか否かを判断するステップと、入力された音声が設定値よりも大きい場合、前記通話サーバへミキシング要求を行い、前記通話サーバからの応答を受信してミキシング状態を確立するステップと、前記通話サーバとのミキシング状態が確立した後、前記音声入力手段で入力された音声をパケット化して前記通話サーバへ送信するステップとを有し、前記通話サーバが、ミキシング要求を行った通話端末へ応答を送信し、ミキシング制御対象として記録するステップと、記録した当該通話端末から送信された音声パケットを、セッションを確立している他の通話端末へ送信するステップとを有することを特徴とする。
【００２０】
請求項１０記載の発明は、請求項９記載の多者間通話方法において、前記通話端末が、入力された音声が設定値よりも小さい場合、設定値よりも小さい音声入力が何回連続しているかを記憶するステップと、記憶された設定値よりも小さい音声入力回数が所定回数以上連続していた場合、前記通話サーバへミキシング切断要求を行い前記通話サーバからの応答を受信してミキシング状態を切断するステップとを更に有し、前記通話サーバが、ミキシングの切断要求に対する応答を送信した通話端末を、ミキシング制御対象から削除するステップとを更に有することを特徴とする。
【発明の効果】
【００２１】
以上の説明で明らかなように、本発明によれば、通話端末に入力された音声の大きさが設定値よりも大きい場合に、ミキシング状態を確立し、音声を通話サーバに送信し、通話サーバから他の通話端末へ該音声を送信する。よって、実際に音声入力があった通話端末からの音声のみをミキシング処理の対象にすればよいので、通話サーバのミキシング処理を効率的に行うことができる。その結果、端末数を増加させることができる。
また、現に発言している通話端末の音声だけを通話サーバで処理することで、ミキシングが必要なストリーム数を大幅に削減することができる。通話サーバで、入力のあった通話端末からの音声のみをミキシングし、得られた音声パケットを他の通話端末へ送信することで、多者間通話を実現する。
通話端末は通話サーバとセッションを開始するだけで、多者間通話を開始できる。さらに、通話端末は、セッションを確立した後は、マイクなど入力装置を利用するだけで、付加的操作を要することなく通話できる。
【００２２】
また、請求項２記載の本発明によれば、設定値よりも小さい音声入力が所定回数以上連続していた場合、ミキシング状態を切断するので、連続して音声入力がない場合のネットワークの負荷も低減できる。
【００２３】
また、請求項３記載の本発明によれば、通話端末から通話サーバへセッション開始の要求を行い、通話サーバから通話端末へ応答を行うことでセッションが確立されるので、音声パケットを送信する通話端末を特定することができる。
【００２４】
また、請求項４記載の本発明によれば、通話端末から通話サーバへセッション切断の要求を行い、通話サーバから通話端末へ応答を行うことでセッションが切断されるので、音声パケットを送信しない通話端末を特定することができる。
【００２５】
請求項５記載の通話端末によれば、入力された音声の大きさが設定値よりも大きい場合に、ミキシング状態を確立し、音声を通話サーバに送信する。よって、通話端末は音声の入力のみで多者間通話を開始できる。
【００２６】
請求項６記載の通話端末によれば、設定値よりも小さい音声入力が所定回数以上連続していた場合、通話サーバへミキシング切断要求を行うので、ミキシングが必要な音声パケット数を大幅に削減することができる。
【００２７】
請求項7記載の通話サーバによれば、ミキシング要求を行った通話端末からの音声パケットを、セッションを確立している他の通話端末へ送信するので、通話サーバのミキシング処理を効率的に行うことができる。
【００２８】
請求項８記載の通話サーバによれば、ミキシングの切断要求を行った通話端末を、ミキシング制御対象から削除するので、通話サーバでのミキシングが必要なパケット数を大幅に削減することができる。
【００２９】
請求項９記載の多者間通話方法によれば、通話端末に入力された音声の大きさが設定値よりも大きい場合に、ミキシング状態を確立し、音声を通話サーバに送信し、通話サーバから他の通話端末へ該音声を送信する。よって、実際に音声入力があった通話端末からの音声のみをミキシング処理の対象にすればよいので、通話サーバのミキシング処理を効率的に行うことができる。その結果、端末数を増加させることができる。
また、現に発言している通話端末の音声だけを通話サーバで処理することで、ミキシングが必要なストリーム数を大幅に削減することができる。通話サーバで、入力のあった通話端末からの音声のみをミキシングし、得られた音声パケットを他の通話端末へ送信することで、多者間通話を実現する。
通話端末は通話サーバとセッションを開始するだけで、多者間通話を開始できる。さらに、通話端末は、セッションを確立した後は、マイクなど入力装置を利用するだけで、付加的操作を要することなく通話できる。
【００３０】
請求項１０記載の多者間通話方法によれば、設定値よりも小さい音声入力が所定回数以上連続していた場合、ミキシング状態を切断するので、連続して音声入力がない場合のネットワークの負荷も低減できる。
【発明を実施するための最良の形態】
【００３１】
以下、図面を参照して本発明の実施の形態を説明する。本発明で提案する「限定ミキシング」方式は、参加する端末が多くても、実際に同時に発言する端末は少ない点に着目した方式である。
【００３２】
図１は、本発明の一実施形態に係る多者間通話システムを適用した多者間通話サーバと通話端末との概略構成を示すブロック図である。図１において、1は多者間通話サーバで、複数の通話端末２（IP電話機）に対して多者間通話サービスを提供する。1、2は共にネットワーク3で接続されている。ネットワーク3は、IP電話トラフィックのみ伝送する専用網と、インターネットのように電話以外のトラフィックが伝送されている共有回線も含む。
【００３３】
通話サーバ１には、音声ミキシングの機能を持たせる。各通話端末２はあらかじめ通話サーバ１とセッションを確立しておく。発言を行う端末（２Ａとする）は、通話サーバ１との間でミキシング状態が確立される。セッションを確立しているがミキシング状態を確立していない端末には、通話サーバ１から、ミキシング状態を確立した端末からの音声のみが送信される。次に通話端末２Ａが発言をした時に、同時に発言をした他の端末数が一定数 (N) を超えている場合は、他の端末は発言不可能とする。すなわち、先に発言（ミキシング状態を確立）していた通話端末２Ａを優先する。端末は、音声が一定時間入力されなかった場合、通話サーバ１とのミキシング状態を終了する。 
【００３４】
本実施例で使用するシグナリングプロトコルは、標準として定められているSIP (Session Initiation Protocol) を用いる。
図２は通話サーバ１と通話端末２とのセッション確立および終了におけるSIPメッセージのやり取りを示している。通話端末２が通話を開始するとき、通話端末２は通話サーバ１へ、セッション開始要求としてINVITEメッセージを送信する（ステップＳ２０１）。呼び出しが成功すると、通話サーバ１は応答として180 Ringing、200 OKのメッセージを返し（ステップＳ１０１、１０３）、これに対して通話端末２がACKを送信することで（ステップＳ２０３）セッションを確立する。
セッションを切断する場合は、切断を要求したい通話端末２がBYEメッセージを送信し（ステップＳ２１１）、通話サーバ１が応答として200 OKのメッセージを返す（ステップＳ１１１）。
【００３５】
図３は通話サーバ１と通話端末２がセッション確立した後に、ミキシング状態を確立するためのメッセージのやり取りを示している。ここで、SIPに準じたメッセージとして、SPEAKとMUTEを定義する。
通話端末２は通話サーバ１とセッションを確立した後、音声データを送信する前にSPEAKメッセージを用いて通話サーバ１にミキシングを要求する（ステップＳ２２１）。SPEAKを受信した通話サーバ１は、図２でINVITEを受信したときと同様に180 Ringing、200 OKを返す（ステップＳ１２１、１２３）。通話端末２は、これを受けてACKを通話サーバ１に送信して（ステップＳ２２３）、通話サーバ１とのミキシング状態を確立する。
通話端末２が音声データを送信しなくなった場合は、通話端末２からMUTEメッセージを送信する（ステップＳ２３１）。MUTEは図２におけるSIPメッセージのBYEに相当する。MUTEを受信した通話サーバ１は、通話端末２に200 OKを返し（ステップＳ１３１）、ミキシング状態が終了する。 
【００３６】
ここで、通話サーバ１、通話端末２それぞれの構成と、図２、図３で説明したSIPメッセージのやり取りにおけるそれぞれの詳細な動作について、以下に記載する。
【００３７】
まず、通話サーバ１の機能ブロックを図４に示す。本実施例での通話サーバ１は、接続している通話端末２から受信するSIPの各種メッセージとRTPの音声パケットを処理する必要がある。通話サーバ１は、制御部１０（ミキシング制御対象記録手段、ミキシング制御対象削除手段）、SIPプロトコルスタック部１１、ミキシング部１２、端末接続状態管理テーブル１３、ミキシング制御テーブル１４、パケット送受信部１５（第２の送信手段）、符号化部１６、復号化部１７、RTP(Real-Time Transport Protocol)パケット生成部１８、RTPパケット解析部１９を有する。
【００３８】
パケット送受信部１５は、通話端末２からの音声パケットの受信および通話端末２への送信を行うためのモジュールで、音声パケットの送受信に関してRTP (Real-Time Transport Protocol : ストリーム制御プロトコル) を用い、受信したパケットの正当性チェックを行う。そして、パケットロスやパケット遅延を検出し、制御や破棄を行う。
【００３９】
SIPプロトコルスタック部１１は、SIPメッセージを送信した通話端末２に対して応答を返す処理を行う。
【００４０】
次に、通話サーバ１の詳細な動作について説明する。
図５に通話サーバ１と通話端末２とでセッション確立・切断を行う際の通話サーバ１の動作フローを示す。通話サーバ１のパケット送受信部１５は、特定の通話端末２ＡからSIPメッセージを受信する（ステップＳａ１０１）。受信したSIPメッセージがINVITEメッセージの場合（ステップＳａ１０５で「Yes」）、SIPプロトコルスタック部１１は図２のステップＳ１０１、１０３に示した応答を返し（ステップＳａ１０３）、通話端末２Ａとのセッションを確立する（ステップＳａ１０７）。また制御部１０は、端末接続状態管理テーブル１３に通話端末２Ａが接続されたことを追加する（ステップＳａ１０９）。そして図６の処理に移る。
パケット送受信部１５が通話端末２Ａから受信したSIPメッセージがBYEメッセージの場合（ステップＳａ１０５で「No」）、SIPプロトコルスタック部１１は図２のステップＳ１１１に示した応答を返して（ステップＳａ１２１）、通話端末２Ａとのセッションを切断する（ステップＳａ１２３）。そして制御部１０は、端末接続状態管理テーブル１３から通話端末２Ａの情報を削除する（ステップＳａ１２５）。
【００４１】
図６に通話サーバ１と通話端末２とでミキシング状態の確立・切断を行う際の通話サーバ１の動作フローを示す。通話サーバ１はステップＳａ１０７で通話端末２Ａとのセッションを確立し、通話端末２Ａからのミキシング要求を待機している。パケット送受信部１５は、通話端末２Ａからメッセージを受信する（ステップＳａ１５１）。ここで受信するメッセージはSIPに準じている。受信したメッセージがSPEAKメッセージの場合（ステップＳａ１５５で「Yes」）、SIPプロトコルスタック部１１は図３のステップＳ１２１、１２３に示した応答を返す（ステップＳａ１５３）。そして制御部１０は、ミキシング制御テーブル１４に通話端末２Ａを追加する（ステップＳａ１５７）。これにより、通話端末２Ａの音声がミキシング処理されるようになる。そして、図７の処理に移る。
パケット送受信部１５が通話端末２Ａから受信したメッセージがMUTEメッセージの場合（ステップＳａ１５５で「No」）、SIPプロトコルスタック部１１は図３のステップＳ１３１に示した応答を返し（ステップＳａ１５９）、制御部１０はミキシング制御テーブル１４から通話端末２Ａを削除する（ステップＳａ１６１）。つまり、通話端末２Ａの音声がミキシング処理されないようにする。
【００４２】
図７にミキシング確立状態における、通話サーバ１のRTP送受信処理の動作フローを示す。パケット送受信部１５が通話端末２ＡからのRTPパケットを受信すると（ステップＳａ１７１）、RTPパケット解析部１９は、受信したRTPパケットを解析する。RTPパケットにエラーが無ければ、復号化部１７で音声データを復号化し（ステップＳａ１７３）、ミキシング部１２に送る。ミキシング部１２は、ミキシング制御テーブル１４から、ステップＳａ１５７で追加した通話端末２Ａの情報を呼び出し、ミキシング状態が確立している通話端末２Ａの音声のみをミキシングする（ステップＳａ１７５）。ミキシング済みのパケットは、符号化部１６で符号化した後（ステップＳａ１７７）、RTPに合わせた形式になるようパケットを生成し、パケット送受信部１５を用いてセッションを確立しているネットワーク３内の端末すべてに送信する（ステップＳａ１７９）。
【００４３】
図８に通話サーバ１における端末接続状態管理テーブル１３のデータ構造を、図９にミキシング制御テーブル１４のデータ構造を示す。端末接続状態管理テーブル１３の最大要素数は最大参加人数、ミキシング制御テーブル１４の最大要素数は最大同時発言者数となる。
例えば、通話端末２からのSPEAKを受け付けると、制御部１０は各種情報（SIP交換情報など）をミキシング制御テーブル１４に保存する。逆に、通話端末２からMUTEを受信すると、制御部１０は通話端末２の各種情報をミキシング制御テーブル１４から破棄する。
【００４４】
次に通話端末２の機能ブロックを図１０に示す。通話端末２は、SIPの送信、受信、RTPの送信、受信を処理する必要がある。通話端末２は、メモリ２０（回数記憶手段）、SIPプロトコルスタック部２１、接続制御部２２（入力音声判断手段、ミキシング状態確立手段、ミキシング状態切断手段）、パケット送受信部２３（第２の音声パケット送信手段）、音声入力部２４（音声入力手段）、音声出力部２５、符号化部２６、復号化部２７、RTPパケット生成部２８、RTPパケット解析部２９、ミキシング状態管理部３０を有する。
【００４５】
パケット送受信部２３は、通話サーバ１とのパケットの送受信をつかさどる。音声パケットの送受信に関してRTPを用い、受信したパケットの正当性チェックを行う。そして、パケットロスやパケット遅延を検出し、制御や破棄を行う。
【００４６】
SIPプロトコルスタック部２１は、SIPメッセージを送信し、それに対する通話サーバ１からの応答を受信する処理を行う。メモリ２０は、入力音声と判断される音声の大きさの最小値（閾値）を記憶している。ミキシング状態管理部３０は、通話端末２が通話サーバ1とミキシング状態を確立しているか否かの情報を管理している。
【００４７】
次に通話端末２の詳細な動作について説明する。
図１１に特定の通話端末２Ｂと通話サーバ１とでセッション確立・切断を行う際の通話端末２Ｂの動作フローを示す。図１１ａにおいて、ユーザが通話端末２Ｂを用いて発呼を行い、通話サーバ１とのセッションを確立しようとすると、通話端末２ＢのSIPプロトコルスタック部２１は、パケット送受信部２３を介してINVITEメッセージを通話サーバ１へ送信する（ステップＳｂ２０１）。パケット送受信部２３が、通話サーバ１から図２のステップＳ１０１、Ｓ１０３で示した応答を受信すると（ステップＳｂ２０３）、SIPプロトコルスタック部２１はACKを通話サーバ1へ返し(ステップＳｂ２０５)、セッションを確立する。
図１１ｂにおいてユーザからのセッション切断要求があると、SIPプロトコルスタック部２１は、パケット送受信部２３を介してBYEメッセージを通話サーバ１へ送信する（ステップＳｂ２０７）。そして、パケット送受信部２３は通話サーバ１から図２のステップＳ１１１で示した応答を受信する（ステップＳｂ２０９）。
【００４８】
図１２に通話端末２Ｂと通話サーバ１とでミキシング状態の確立・切断を行う際の通話端末２の動作フローを示す。
通話端末２Ｂの音声入力部２４から音声が入力されると（ステップＳｂ２５１）、接続制御部２２はその音声の大きさを、メモリ２０であらかじめ記憶された音声の閾値と比較する（ステップＳｂ２５３）。入力された音声が閾値より大きければ（ステップＳｂ２５３で「Yes」）、音声が入力されたと判断する。次に接続制御部２２はミキシング状態管理部３０から、通話端末２Ｂと通話サーバ１とがミキシング状態か否かの情報を取得する。ミキシング状態が確立されていない場合（ステップＳｂ２５５で「No」）、SIPプロトコルスタック部２１はパケット送受信部２３を介して通話サーバ１にSPEAKを送信する（ステップＳｂ２５７）。そして、図３のステップＳ１２１、Ｓ１２３に示す通話サーバ１からの応答をパケット送受信部２３が受信すると、SIPプロトコルスタック部２１はACKを返してミキシング状態を確立する（ステップＳｂ２５８）。接続制御部２２はミキシング状態管理部３０に、通話端末２がミキシング状態であることを記録する（ステップＳｂ２５９）。
ステップＳｂ２５５でミキシング状態が確立されている場合は（ステップＳｂ２５５で「Yes」）、後述する図１３ａのステップＳｂ２７５の処理に移る。
【００４９】
入力された音声の大きさがメモリ２０に記憶された音声の閾値以下の場合（ステップＳｂ２５３で「No」）、接続制御部２２はメモリ２０に、閾値以下の音声入力回数を記録する（ステップＳｂ２６０）。また、接続制御部２２はミキシング状態管理部３０から、通話端末２Ｂと通話サーバ１とがミキシング状態か否かの情報を取得する。ミキシング状態が確立されている場合（ステップＳｂ２６１で「Yes」）、接続制御部２２はメモリ２０に記録している、音声入力が連続して閾値を下回った回数を取得する。
音声入力が一定回数以上連続して閾値を下回った場合（ステップＳｂ２６３で「Yes」）、接続制御部２２は一定時間音声の入力がないと判定する。そして、ミキシング状態を切断するために、SIPプロトコルスタック部２１はパケット送受信部２３を介して通話サーバ1へMUTEを送信する（ステップＳｂ２６５）。パケット送信部２３が、図３のステップＳ１３１に示す通話サーバ１からの応答を受信すると、ミキシング状態が切断となる（ステップＳｂ２６７）。接続制御部２２はミキシング状態管理部３０に、通話端末２がミキシング状態でなくなったことを記録する（ステップＳｂ２６９）。
音声入力が閾値を下回った回数が一定回数連続していない場合（ステップＳｂ２６３で「No」）、再び次の音声入力を待機する。
【００５０】
図１３ａにミキシング確立状態における、通話端末２のRTP送信処理の動作フローを示す。音声入力部２４から入力された音声（ステップＳｂ２７１）は、図１２に示す動作でミキシング状態を確立し（ステップＳｂ２７３）、符号化部２６で符号化される（ステップＳｂ２７５）。符号化された音声データは、RTPパケット生成部２８でRTPパケットとして生成され、パケット送受信部２３から通話サーバ１へ送信される（ステップＳｂ２７７）。
【００５１】
図１３ｂに通話端末２のRTP受信処理の動作フローを示す。パケット送受信部２３が通話サーバ１からRTPパケットを受信すると（ステップＳｂ２８１）、RTPパケット解析部２９は、受信したRTPパケットを解析する。エラーが無ければ復号化部で音声データに復号化し（ステップＳｂ２８３）、音声データを音声出力部２５に送って音声を出力する（ステップＳｂ２８５）。
【産業上の利用可能性】
【００５２】
以上説明したように、本発明の「限定ミキシング」と呼ぶ方式は、現に発言している端末の音声だけを多者間通話サーバで処理することで、ミキシングが必要なストリーム数を大幅に削減する。多者間通話サーバで発言者の音声のみをミキシングし、得られた音声を端末へ送信することで、多者間通話を実現する。
【００５３】
音声が入力されると、既に通話サーバとミキシング状態確立済みか調べ、確立されていない場合はSPEAKメッセージを送信してミキシング状態確立を通話サーバに要求する。ミキシング状態が確立できたら、入力された音声を符号化部で符号化する。次に、RTPパケット生成部でRTPパケットとして整形した後、パケット送受信部に渡す。また、一定時間音声の入力がない場合、ミキシング状態を終了するためにサーバにMUTEメッセージを送信する。RTPパケット解析部は、RTPパケットを受信すると、エラーの有無をチェックし、エラーが無ければ音声データを復号化し、データを音声出力部に渡す。
【００５４】
通話端末は多者間通話サーバとセッションを開始するだけで、多者間通話を開始できる。さらに、通話端末は、セッションを確立した後は、マイクなど入力装置を利用するだけで、発言権要求ボタンを押すなどの付加的操作を要することなく通話できる。発言者にとっては、マイクからの音声入力により発言が可能になるので、議長制発言方式のような発言権の意識を不要にできるという効果がある。
【００５５】
以上、本発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。
【図面の簡単な説明】
【００５６】
【図１】本発明の一実施形態に係る通話システムを適用した多者間通話サーバとユーザ端末との概略構成を示すブロック図である。
【図２】同上の実施形態における通話サーバ１と通話端末２とのセッション確立および切断におけるSIPメッセージのやり取りを示す図である。
【図３】同上の実施形態における、通話サーバ１と通話端末２とのミキシング状態の確立および切断におけるメッセージのやり取りを示す図である。
【図４】同上の実施形態における通話サーバ１の機能ブロックを示す図である。
【図５】セッション確立・切断を行う際の通話サーバ１の動作を示すフローチャートである。
【図６】ミキシング状態の確立・切断を行う際の通話サーバ１の動作を示すフローチャートである。
【図７】通話サーバ１のRTP送受信処理の動作を示すフローチャートである。
【図８】通話サーバ１における端末接続状態管理テーブル１３のデータ構造を示すテーブルである。
【図９】通話サーバ１におけるミキシング制御テーブル１４のデータ構造を示すテーブルである。
【図１０】同上の実施形態における通話端末２の機能ブロックを示す図である。
【図１１ａ】セッションの確立を行う際の通話端末２の動作を示すフローチャートである。
【図１１ｂ】セッションの切断を行う際の通話端末２の動作を示すフローチャートである。
【図１２】ミキシング状態の確立・切断を行う際の通話端末２の動作を示すフローチャートである。
【図１３ａ】通話端末２のRTP送信処理の動作を示すフローチャートである。
【図１３ｂ】通話端末２のRTP受信処理の動作を示すフローチャートである。
【符号の説明】
【００５７】
１…通話サーバ、２…通話端末（IP電話機）、３…インターネット、
１０…制御部、１１…通話サーバのSIPプロトコルスタック部、１２…ミキシング部、１３…端末接続状態管理テーブル、１４…ミキシング制御テーブル、１５…パケット送受信部、１６…符号化部、１７…復号化部、１８…RTPパケット生成部、１９…RTPパケット解析部、
２０…端末のメモリ、２１…SIPプロトコルスタック部、２２…接続制御部、２３…パケット送受信部、２４…音声入力部、２５…音声出力部、２６…符号化部、２７…復号化部、２８…RTPパケット生成部、２９…RTPパケット解析部、３０…ミキシング状態管理部
【図１】
0004644813.tif 000002
【図２】
0004644813.tif 000003
【図３】
0004644813.tif 000004
【図４】
0004644813.tif 000005
【図５】
0004644813.tif 000006
【図６】
0004644813.tif 000007
【図７】
0004644813.tif 000008
【図８】
0004644813.tif 000009
【図９】
0004644813.tif 000010
【図１０】
0004644813.tif 000011
【図１１ａ】
0004644813.tif 000012
【図１１ｂ】
0004644813.tif 000013
【図１２】
0004644813.tif 000014
【図１３ａ】
0004644813.tif 000015
【図１３ｂ】
0004644813.tif 000016