JP3757351B2

JP3757351B2 - Subscriber terminal device and multicast broadcasting method

Info

Publication number: JP3757351B2
Application number: JP33777699A
Authority: JP
Inventors: 順文江藤; 真幸西村; 隆哉山本
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1999-11-29
Filing date: 1999-11-29
Publication date: 2006-03-22
Anticipated expiration: 2019-11-29
Also published as: JP2001156847A

Description

【０００１】
【発明の属する技術分野】
本発明は、ＩＰ（Internet Protocol ）ネットワークを利用したマルチキャストに関し、特に、特定のユニキャストの音声パケットをマルチキャスト化するマルチキャストサーバをＩＰネットワーク上に具備し、該マルチキャストサーバから複数の加入者端末装置へ音声パケットを配信し、大規模集合住宅、病院、学校又は地方自治体等における定時放送や緊急放送等に好適に利用される加入者端末装置、及びマルチキャストによる放送方法に関する。
【０００２】
【従来の技術】
従来の放送システムは、例えば特開平１１- ８８５４７号公報等に開示されている。この放送システムは、ＣＡＴＶ網を利用した音声／データ共有通信システムにおいて、加入者宅に端末装置を備え、センタ側にセンタ装置を備え、ＴＤＭＡ（Time Division Multiple Access ）方式を用いて１対ｎの放送型通信を行うものである。
【０００３】
このＴＤＭＡ方式を用いた放送システムは、音声用の通信チャネルとデータ用の通信チャネルとを具備し、伝送帯域を有効利用して通信を行うシステムであるが、このシステムはＴＤＭＡ方式を用いているため、既にＬＡＮ（Local Area Net Work ）としてケーブルモデム等を用いてＩＰネットワークが構築されている場合には、この既設のＩＰネットワークとは別のシステムとして構築する必要がある。
【０００４】
また、ＩＰネットワーク上で音声を扱うシステムとして、ＩＴＵ−ＴのＨ．３２３プロトコルとして勧告されたものがあるが、このシステムはテレビ会議システム等のグループウェアを主としたものであり、会議等に参加する加入者の端末装置は呼び出し可能なもので、且つ呼び出しに応答するものでなければならない。
【０００５】
そのため、ＩＴＵ−ＴのＨ．３２３プロトコルによるシステムは、放送のように受信者の意図によらずに一方的に複数の加入者に送信するシステムには不向きであり、ＩＰネットワーク上で音声を放送のように送信するためのプロトコルは特に勧告されていない。
【０００６】
【発明が解決しようとする課題】
従来のＴＤＭＡ方式等による有線放送網システムは、その有線放送網固有の特定の技術体系により構築されるため、ネットワークシステムの汎用性、拡張性、柔軟性に乏しいという問題があった。
【０００７】
本発明は、汎用のＩＰネットワーク環境下で音声を従来の放送システムと同様に放送するシステムを実現し、システム構築及び拡張の簡易化を図り、同じＩＰネットワーク上で音声パケット配信サービス（ＶｏＩＰサービス）や他のＩＰ通信サービスと併存させることができ、機能変更や機能追加を柔軟に行うことができるマルチキャストによる放送方法及びその方法の実施に使用する加入者端末装置を提供することを目的とする。
【０００８】
また、本発明は、放送可能な発信者の資格をチェックし、放送システムの安全な運用管理を行い、複数の放送種別の放送を行うことができ、また受信対象加入者端末装置をマルチキャストサーバから一元管理することができ、また放送受信者は放送発信者を確認することができ、また放送発信者は放送を受信した加入者を確認することができ、また放送音声を必要に応じて録音し、同一放送を繰り返して放送することができ、また重複した放送の優先制御を行うことができるマルチキャストによる放送方法及びその方法の実施に使用する加入者端末装置を提供することを目的とする。
【０００９】
【課題を解決するための手段】
本発明の加入者端末装置は、（１）ＩＰネットワークに接続される加入者端末装置において、マルチキャストＩＰアドレスを有する受信パケットの中から、放送用電話番号に対応し、自装置に予め格納されたマルチキャストＩＰアドレスを有する音声パケットの受信を判別する手段と、前記マルチキャストＩＰアドレスを有する音声パケットの受信を判別したときに、スピーカをオンにし、受信した前記音声パケットの音声を該スピーカより放音する手段と、を備えたことを特徴とする。
【００１０】
また、（２）放音する前記音声パケットに含まれる放送用電話番号及び音声データを格納する音声データ蓄積手段を有することを特徴とする。
【００１１】
また、（３）接続されるアナログ電話機から、蓄積された放送音声データの再生用電話番号を受信すると、対応する放送音声蓄積データを読み出し再生してスピーカから放音することを特徴とする。
【００１２】
また、（４）マルチキャストによる放音の終了後にスピーカをオフとし、録音放送の有無を可視又は可聴表示することを特徴とする。
【００１３】
また、（５）優先順位を付けたマルチキャストＩＰアドレス格納テーブルを設け、受信する複数のマルチキャストの中から優先順位に応じて放音するマルチキャストの音声パケットを選択することを特徴とする。
【００１４】
また、（６）優先順位が低く選択されなかったマルチキャストの音声パケットを格納する音声データ蓄積手段を設け、要求に応じて格納された前記音声パケットを再生して放音することを特徴とする。
【００１５】
また、（７）マルチキャストの受信中のときに、音声パケットの送信元であるマルチキャストサーバへ受信中である旨を示すメッセージを返信することを特徴とする。
【００１６】
また、（８）マルチパケット受信状態の問い合わせパケットをマルチキャストサーバより受信した場合には、受信中である旨を示すメッセージを返信することを特徴とする。
【００１７】
また、（９）前記マルチキャストＩＰアドレスを記憶するテーブルを設け、マルチキャストサーバからの自装置のＩＰアドレス宛へ送られてくる更新テーブルによって、前記テーブルを更新することを特徴とする。
【００１８】
また、（１０）自装置に接続された電話機から放送用電話番号がダイヤル送出されて送話中である場合には、ＩＰネットワークから配信される前記マルチキャストＩＰアドレスによる音声パケットを受信しないように受信処理を中止する手段を備えたことを特徴とする。
【００１９】
また、（１１）前記マルチキャストＩＰアドレスを有する音声パケットを受信する前に発信者の放送者識別情報を受信すると、前記放送者識別情報を表示する手段を設けたことを特徴とする。
【００２０】
また、本発明のマルチキャストによる放送方法は、（１２）ＩＰネットワークに接続される加入者端末装置へ音声パケットを配信するマルチキャストによる放送方法であって、放送用電話番号に対応したマルチキャストＩＰアドレス宛てに音声パケットをマルチキャストサーバから送信するステップと、加入者端末装置においてマルチキャストＩＰアドレスを有する受信パケットの中から、自装置に予め格納され、放送用電話番号に対応したマルチキャストＩＰアドレスを有する音声パケットの受信を判別するステップと、該マルチキャストＩＰアドレスを有する音声パケットの受信を判別したときに、スピーカをオンにし、受信した前記音声パケットの音声を該スピーカより放音するステップと、から成ることを特徴とする。
【００２９】
【発明の実施の形態】
図１は本発明のマルチキャストによる放送システムの構成図である。同図において、１−１０は加入者端末装置、１−１１は加入者端末装置にアナログ回線で接続された電話機（アナログ電話機）、１−１２は加入者端末装置に備えられた放送用スピーカ、１−２０はゲートキーパ（ＧＫ）、１−３０はマルチキャストサーバ（ＭＳ）、１−４０は加入者端末装置、ゲートキーパ（ＧＫ）及びマルチキャストサーバ（ＭＳ）を相互に接続するＬＡＮ等のＩＰネットワークである。
【００３０】
ＴＢＬ１はゲートキーパ（ＧＫ）に備えられた電話番号−ＩＰアドレス対応テーブル、ＴＢＬ２はマルチキャストサーバ（ＭＳ）に備えられた放送用電話番号−マルチキャストＩＰアドレス対応テーブル、ＴＢＬ３はマルチキャストＩＰアドレス格納テーブルである。
【００３１】
加入者端末装置１−１０は、マルチキャストサーバ（ＭＳ）１−３０からＩＰネットワーク１−４０を介して配信されるマルチキャストパケットの中から、自装置で受信するマルチキャストパケットのＩＰアドレスを格納したマルチキャストＩＰアドレス格納テーブルＴＢＬ３と、受信したマルチキャストパケットの音声信号を放音するスピーカ１−１２と、放送音声信号を送出するアナログ電話機１−１１とを具備する。
【００３２】
ゲートキーパ（ＧＫ）１−２０は、加入者の電話番号とＩＰアドレスとを対応付けた電話番号−ＩＰアドレス対応テーブルＴＢＬ１を具備し、マルチキャストサーバ（ＭＳ）１−３０は放送用電話番号毎にそれぞれ異なるマルチキャストＩＰアドレスを対応付けた放送用電話番号−マルチキャストＩＰアドレス対応テーブルＴＢＬ２を具備する。
【００３３】
図２は本発明のマルチキャストによる放送システムの枢要部の動作説明図である。音声により告知放送を行おうとする発信者は、その加入者端末装置のアナログ電話機をオフフックし（２−１）、放送用電話番号をダイヤル信号により送出する（２−２）。
【００３４】
該発信者の加入者端末装置は、アナログ電話機から送出された放送用電話番号を着アドレス情報とし、且つ該発信者の電話番号を発アドレス情報としたデータを含むＩＰパケットを、ゲートキーパ（ＧＫ）に送信する（２−３）。ゲートキーパ（ＧＫ）は、受信した該ＩＰパケットに含まれる着アドレス情報としての放送用電話番号から、電話番号−ＩＰアドレス対応テーブル（ＴＢＬ１）により、マルチキャストサーバ（ＭＳ）のＩＰアドレスを取得し、該マルチキャストサーバ（ＭＳ）のＩＰアドレスを発信者の加入者端末装置に通知する（２−４）と共に、マルチキャストサーバ（ＭＳ）に前述の着アドレス情報（放送用電話番号）及び発アドレス情報（発信者の電話番号又はＩＰアドレス）をＩＰパケットにより通知する（２−５）。
【００３５】
マルチキャストサーバ（ＭＳ）は、ゲートキーパ（ＧＫ）から通知された着アドレス情報（放送用電話番号）から、放送用電話番号−マルチキャストＩＰアドレス対応テーブル（ＴＢＬ２）により、該放送用電話番号に対応するマルチキャストＩＰアドレスを取得し（２−６）、ゲートキーパ（ＧＫ）に対して放送確認の応答パケットを送出する（２−７）。
【００３６】
放送確認の応答パケットを受け取ったゲートキーパ（ＧＫ）は、加入者端末装置に対して同様に放送確認の応答パケットを送出し（２−８）、該放送確認の応答パケットを受け取った加入者端末装置は、発信者に対して放送開始の指示信号を送出する（２−９）。
【００３７】
発信者の音声は、電話機からアナログ信号として加入者端末装置に送出され（２−１０）、加入者端末装置は、該アナログ音声信号を音声パケットに変換し、該音声パケットをマルチキャストサーバ（ＭＳ）宛てにユニキャスト送信する（２−１１）。マルチキャストサーバ（ＭＳ）は、加入者端末装置から受信した音声ＩＰパケットを、当該放送用電話番号に対応したマルチキャストＩＰアドレス宛てにマルチキャスト送信する（２−１２）。
【００３８】
受信者側の加入者端末装置は、マルチキャストサーバ（ＭＳ）から送信されるマルチキャストＩＰパケットの中から、自装置のマルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）に格納されているマルチキャストＩＰアドレス宛のパケットを受信し、該パケットの音声データをアナログ音声信号に変換し、スピーカをオンにして該音声をスピーカから放音する（２−１３）。
【００３９】
発信者が放送による告知を終え、アナログ電話機をオンフックすると（２−１４）、加入者端末装置は放送終了メッセージをユニキャストによりゲートキーパ（ＧＫ）介してマルチキャストサーバ（ＭＳ）に通知する（２−１５，２−１６）。
【００４０】
マルチキャストサーバ（ＭＳ）は、放送終了メッセージを当該マルチキャストＩＰアドレス宛てに送信し（２−１７）、当該マルチキャストＩＰアドレスのパケットを受信中の加入者端末装置は、放送終了メッセージを受信するとスピーカをオフにし、これにより放送を終了する（２−１８）。以上のシステム動作により、ＩＰネットワーク上で１つの加入者端末装置のアナログ電話機から複数の加入者端末装置のスピーカヘ同時に音声信号を配信することができる。
【００４１】
上述のマルチキャストによる放送シーケンスを実行するためのプロトコルメッセージの例を図３に示す。図３にはＨ．３２３のプロトコルによるメッセージを用いた場合の例を示しているが、本発明はこれに限られるものではない。
【００４２】
Ｈ．３２３のプロトコルでは、ゲートキーパ（ＧＫ）とその配下の加入者端末装置との間でＨ．２２５．０ＲＡＳプロトコルのメッセージによる登録、参加、帯域確保、Ｈ．２２５．０Ｑ．９３１プロトコルのメッセージによる呼制御、Ｈ．２４５プロトコルのメッセージによる呼制御の制御（マスタ・スレーブ、通話能力交換、論理チャネル交換）、Ｈ．２２５．０ＲＴＰ（Real Time Transport Protocol）プロトコルによる音声ストリームの送受を行う。
【００４３】
図３に示すシーケンスにおいて、発信者電話機のオフフック信号が加入者端末装置に送出されると、加入者端末装置から該電話機にダイヤルトーン（ＤＴ）を送出し、発信者はダイヤルトーン（ＤＴ）を聴取した後、放送用電話番号をダイヤルすると、加入者端末装置からゲートキーパ（ＧＫ）にＨ．２２５．０ＲＡＳメッセージであるＡＲＱ（Admission Request;参加要求）を送信（３−１）し、ゲートキーパ（ＧＫ）からＡＣＦ（Admission Confirmation；参加許可確認）を返信（３−２）する。
【００４４】
ＡＣＦを受信した加入者端末装置からＨ．２２５．０Ｑ．９３１呼制御メッセージであるＳＥＴＵＰメッセージ（発アドレス情報／着アドレス情報）がゲートキーパ（ＧＫ）を経由してマルチキャストサーバ（ＭＳ）に送信される（３−３）。
【００４５】
図３に示すように、以下Ｈ．２２５．０Ｑ．９３１呼制御メッセージを用いて、ＣＡＬＬＰＲＯＣ、ＡＬＥＲＴ、ＣＯＮＮＥＣＴのメッセージがゲートキーパ（ＧＫ）を介して加入者端末装置とマルチキャストサーバ（ＭＳ）との間で送受され（３−４〜３−８）、加入者端末装置から発信者電話機にリングバックトーン（ＲＢＴ）が送出される。
【００４６】
Ｈ．２４５プロトコルにより加入者端末装置とマルチキャストサーバ（ＭＳ）との間でマスタ・スレーブ、通話能力交換、論理チャネル交換のネゴシエーションが確立されると（３−９）、加入者端末装置は発信者電話機に対するリングバックトーン（ＲＢＴ）の送出を停止し、加入者端末装置からマルチキャストサーバ（ＭＳ）に対して、Ｈ．２２５．０ＲＴＰプロトコルにより音声ストリームを送出する（３−１０）。
【００４７】
マルチキャストサーバ（ＭＳ）は、加入者端末装置からユニキャストにより送信された音声ストリームを、Ｈ．２２５．０ＲＴＰプロトコルにより受信対象加入者端末装置のマルチキャストＩＰアドレス宛てへ送信し（３−１１）、受信加入者端末装置は、スピーカをオンにして放送音声を流す。
【００４８】
告知放送を終えて発信者が送受話器をオンフックすると、加入者端末装置からＨ．２２５．０Ｑ．９３１呼制御メッセージである切断（ＤＩＳＣ）メッセージがゲートキーパ（ＧＫ）を経由しマルチキャストサーバ（ＭＳ）に送信される（３−１２）。
【００４９】
マルチキャストサーバ（ＭＳ）は、Ｈ．２２５．０ＲＴＰプロトコルによる音声ストリームを受信している加入者端末装置に周期的に制御パケットを送ることができるＲＴＣＰ（ＲＴＰ制御プロトコル）を用いて、終了（ＢＹＥ）メッセージを放送受信加入者端末装置に送信する（３−１３）。
【００５０】
終了（ＢＹＥ）メッセージを受信した加入者端末装置は、スピーカをオフにし放送を終了する。また、マルチキャストサーバ（ＭＳ）と放送者の加入者端末装置と間でゲートキーパ（ＧＫ）を経由してＨ．２２５．０Ｑ．９３１呼制御メッセージの解放（ＲＥＬ）メッセージ、解放完了（ＲＥＬＣＯＭＰ）メッセージが送受され、放送シーケンス終了となる（３−１４〜３−１５）。
【００５１】
前述のマルチキャストによる放送システムの基本機能の構成に、更に以下に説明する機能構成を付加することにより、種々の変形又は改良を施した実施形態のマルチキャストによる放送システムを構成することができる。
【００５２】
先ず、発信者の放送資格をチェックする実施形態として、前述のマルチキャストサーバ（ＭＳ）は、放送可否加入者番号テーブルを備え、マルチキャスト送信を行うに先立って、該テーブルにより発信者の放送資格をチェックし、発信者が放送有資格者である場合のみに、マルチキャスト送信を行う構成とすることができる。
【００５３】
図４は放送可否加入者番号テーブルを具備したマルチキャストサーバ（ＭＳ）の構成図である。マルチキャストサーバ（ＭＳ）は、発アドレス情報と放送可否とを対応付けた放送可否加入者番号テーブル４−１を具備し、マルチキャストサーバ（ＭＳ）は、受信した発アドレス情報を放送可否加入者番号テーブル４−１によりチェックし、発信者が放送可能か否かを判別する手段を備える。
【００５４】
この手段により、発信者が放送可能であると判別された場合に、前述したように、放送用電話番号−マルチキャストＩＰアドレス対応テーブル（ＴＢＬ２）を用いてマルチキャストＩＰアドレスを割り出し、放送確認の応答パケットを送出し、マルチキャスト送信を実行する。
【００５５】
一方、発信者が放送不可能であると判別された場合には、発信者に対して音声パケット受信拒否のメッセージを送信し、マルチキャスト送信を行わないこととする。このようにして、発信者の加入者端末装置毎に放送資格を与える機能を備えることができる。
【００５６】
放送資格判別を行うマルチキャストによる放送シーケンスのプロトコルメッセージの例を図５及び図６に示す。図５及び図６はＨ．３２３プロトコルを使用した場合の放送資格判別を含むシーケンスであり、図５は発信者に放送許可を与える場合のシーケンス、図６は発信者に放送許可を与えない場合のシーケンスである。
【００５７】
図５及び図６において、マルチキャストサーバ（ＭＳ）は、ＳＥＴＵＰメッセージを受信すると（５−１）、受信した発アドレス情報（発信者の電話番号）と放送可否情報とを対応付ける放送可否加入者番号テーブルから、発信者の放送資格をチェックする（５−２）。
【００５８】
マルチキャストサーバ（ＭＳ）は、発信者の加入者端末装置が放送可であると判別した場合、図５に示すように、ゲートキーパ（ＧＫ）を経由して、Ｈ．３２３Ｑ．９３１呼制御メッセージであるＣＡＬＬＰＲＯＣ，ＡＬＥＲＴ，ＣＯＮＮＥＣＴのメッセージ及びＨ．２２５．０ＲＡＳメッセージであるＡＲＱ，ＡＣＦのメッセージを発信者の加入者端末装置と送受し（５−３〜５−７）、発信者の加入者端末とマルチキャストサーバ（ＭＳ）との間の通信を確立する。
【００５９】
マルチキャストサーバ（ＭＳ）は、発信者の加入者端末装置が放送不可であると判別した場合、図６に示すように、ゲートキーパ（ＧＫ）を経由して、Ｈ．３２３Ｑ．９３１呼制御メッセージを用いてＣＡＬＬＰＲＯＣ，ＤＩＳＣ，ＲＥＬ，ＲＥＬＣＯＭＰのメッセージ及びＨ．２２５．０ＲＡＳメッセージであるＡＲＱ，ＡＣＦのメッセージを発信者の加入者端末装置と送受し（６−３〜６−８）、発信者の電話機には話中音（ＢＴ）が送出され、放送不可となる。
【００６０】
次に、複数の放送種別を有する放送システムの実施形態として、前述の放送用電話番号に複数の電話番号を割り当て、各放送用電話番号毎に異なる放送種別及びマルチキャストＩＰアドレスを割り当てる構成とすることができる。図７は放送用電話番号毎に放送種別を割り当てるテーブルの構成を示している。
【００６１】
ゲートキーパ（ＧＫ）は、図７の（ａ）に示すように、電話番号−ＩＰアドレス対応テーブル（ＴＢＬ１）に、複数の放送用電話番号＃１〜＃ｎをマルチキャストサーバ（ＭＳ）のＩＰアドレスに対応付けて格納する。また、マルチキャストサーバ（ＭＳ）は、図７の（ｂ）に示すように、放送用電話番号−マルチキャストＩＰアドレス対応テーブル（ＴＢＬ２）に、それぞれの放送用電話番号＃１〜＃ｎ毎に個別にマルチキャストＩＰアドレス及び放送種別情報を対応付けて格納する。
【００６２】
ゲートキーパ（ＧＫ）は、複数の放送用電話番号＃１〜＃ｎをマルチキャストサーバ（ＭＳ）のＩＰアドレスに対応付けて格納することにより、複数の異なる放送用電話番号を発信者の加入者装置から着アドレス情報として受信し、それらをマルチキャストサーバ（ＭＳ）に送信することができる。
【００６３】
マルチキャストサーバ（ＭＳ）は、それぞれ異なる放送用電話番号＃１〜＃ｎに個別にマルチキャストＩＰアドレス及び放送種別情報を対応付けることにより、該放送を受信する加入者端末装置のグループ（受信対象加入者端末装置）を、マルチキャストＩＰアドレス毎に切り分け、放送対象の加入者端末装置グループを放送用電話番号で選択して放送することが可能となる。
【００６４】
また、マルチキャストサーバ（ＭＳ）において、各放送用電話番号＃１〜＃ｎ毎に放送種別情報を対応付けることにより、発信者は希望する放送種別の放送用電話番号を送出し、マルチキャストサーバ（ＭＳ）は受信した放送用電話番号に応じて、種別の異なるマルチキャスト送信を行う構成とすることができる。
【００６５】
放送種別情報として、放送音声データをマルチキャストサーバ（ＭＳ）で蓄積し、後に再生して放送する「録音有り」の放送か、放送音声データを蓄積することなく放送する「録音無し」の放送かの種別、又は放送の緊急性を示す「緊急性有り」、「緊急性無し」等の情報とすることができる。また、放送種別情報は付加番号により識別する構成とすることができる。
【００６６】
複数の放送用電話番号を割り当てたマルチキャストによる放送シーケンスの例を図８に示す。図８はＨ．３２３プロトコルを使用した場合の複数の放送用電話番号による放送シーケンスである。同図において、ＳＥＴＵＰ（着アドレスとして放送用電話番号＃１）を受信したマルチキャストサーバ（ＭＳ）は、図７の（ｂ）に示す放送用電話番号−マルチキャストＩＰアドレス対応テーブル（ＴＢＬ２）から、マルチキャストＩＰアドレス＃Ａを引き出し（８−１）、マルチキャストＩＰアドレス＃Ａ宛てに該発信者からのパケット音声を送信する（８−２）。
【００６７】
マルチキャストサーバ（ＭＳ）は、別の加入者端末装置からＳＥＴＵＰメッセージ（着アドレスとして放送用電話番号＃２）を受信すると、図７の（ｂ）に示す放送用電話番号−マルチキャストＩＰアドレス対応テーブル（ＴＢＬ２）から、マルチキャストＩＰアドレス＃Ｂを引き出し（８−３）、マルチキャストＩＰアドレス＃ｂ宛てに該発信者からのパケット音声を送信する（８−４）。
【００６８】
次に、加入者端末装置内のテーブルをマルチキャストサーバ（ＭＳ）から更新する実施形態について説明する。前述のマルチキャストサーバ（ＭＳ）に具備する放送用電話番号−マルチキャストＩＰアドレス対応テーブル（ＴＢＬ２）は、図９の（ａ）に示すように、マルチキャストＩＰアドレス毎に、該マルチキャストを受信する受信対象加入者端末装置のＩＰアドレスの全てを対応付けて格納する構成とする。
【００６９】
この構成により、マルチキャストサーバ（ＭＳ）は、どのＩＰアドレスの加入者端末装置がどのマルチキャストＩＰアドレス宛てのパケットを受信するかを認識することができ、その情報を基に図９の（ｂ）に示すような加入者端末装置のＩＰアドレス毎のマルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）を作成することができる。
【００７０】
マルチキャストサーバ（ＭＳ）は、作成した加入者端末装置のＩＰアドレス毎のマルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）を、放送受信対象の各加入者端末装置のＩＰアドレス宛てに送信する。この構成により、放送受信対象の加入者端末装置に具備されたマルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）を、マルチキャストサーバ（ＭＳ）からＩＰネットワーク上で更新することができる。
【００７１】
また、加入者端末装置内のテーブルをマルチキャストサーバ（ＭＳ）から更新する他の実施形態として、前述のマルチキャストサーバ（ＭＳ）に具備する放送用電話番号−マルチキャストＩＰアドレス対応テーブル（ＴＢＬ２）を、図１０の（ａ）に示すように、マルチキャストＩＰアドレス毎に、該マルチキャストを受信する受信対象加入者端末装置の加入電話番号の全てを対応付けて格納する構成とすることができる。
【００７２】
この構成により、マルチキャストサーバ（ＭＳ）は、どの電話番号の加入者端末装置がどのマルチキャストＩＰアドレス宛てのパケットを受信するかを認識することができ、その情報を基に図１０の（ｂ）に示すような加入者端末装置の電話番号毎のマルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）を作成することができる。
【００７３】
マルチキャストサーバ（ＭＳ）は、作成した加入者端末装置の電話番号毎のマルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）を、放送受信対象の各加入者端末装置のＩＰアドレス宛てに送信する。この際、マルチキャストサーバ（ＭＳ）は、電話番号−ＩＰアドレス対応テーブル（前述のゲートキーパ（ＧＫ）に具備したテーブルＴＢＬ１と同等のもの）を備え、該テーブルを用いて各加入者端末装置の電話番号をＩＰアドレスに変換して送信する。
【００７４】
或いは、マルチキャストサーバ（ＭＳ）には、電話番号−ＩＰアドレス対応テーブルを備えず、マルチキャストサーバ（ＭＳ）が加入者端末装置のマルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）を更新する際に、その都度ゲートキーパ（ＧＫ）に電話番号に対応するＩＰアドレスを問い合わせる手段を備え、ゲートキーパ（ＧＫ）に具備する電話番号−ＩＰアドレス対応テーブル（ＴＢＬ１）から最新の加入者端末情報を取得し、マルチキャストサーバ（ＭＳ）からＩＰネットワーク上で放送受信対象の加入者端末装置のマルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）を更新する構成とすることもできる。この場合、加入者端末装置のＩＰアドレス情報をゲートキーパ（ＧＫ）で一元管理することができ、加入者端末装置のテーブルとのアンマッチを防ぐことができる。
【００７５】
図１１はマルチキャストサーバ（ＭＳ）から加入者端末装置にテーブルを送信して更新する実施形態のシーケンスの例を示す。加入者端末装置の電源が投入されると、ＤＨＣＰ（Dynamic Host Configuration Protocol ）サーバから、加入者端末装置ＩＰアドレス、マルチキャストサーバ（ＭＳ）ＩＰアドレス、その他の初期設定のファイルが送出される。
【００７６】
初期設定ファイルを受信した加入者端末装置は、ＬＡＮ上に存在するホストとして立ち上がり、マルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）を、マルチキャストサーバ（ＭＳ）に要求する（TABLE REQUEST ）。マルチキャストサーバ（ＭＳ）は、加入者端末装置毎の図９の（ｂ）に示すマルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）を作成し、TABLE REQUEST の要求を発信した加入者端末装置に対して、該当のマルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）を送信する。
【００７７】
該当のマルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）を受信した加入者端末装置は、Ｈ．３２３プロトコルの端末として立ち上がり、ゲートキーパ（ＧＫ）に対してＨ．２２５．０ＲＡＳメッセージＲＲＱ(Registration Request ：登録要求）を送信し、ゲートキーパ（ＧＫ）は加入者端末装置にＲＣＦ（Registration Confirmation ：登録確認）を送出する。ＲＣＦを受信した加入者端末装置は、ＩＰマルチキャストによる放送サービスに参加できる放送端末となる。
【００７８】
図１２はマルチキャストサーバ（ＭＳ）から加入者端末装置にテーブルを送信して更新する他の実施形態のシーケンスの例を示す。加入者端末装置の電源が投入されると、ＤＨＣＰサーバから加入者端末ＩＰアドレス、マルチキャストサーバ（ＭＳ）ＩＰアドレス、その他の初期設定のファイルが送出される。
【００７９】
初期設定ファイルを受信した加入者端末装置は、ＬＡＮ上に存在するホストとして立ち上がり、マルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）を、マルチキャストサーバ（ＭＳ）に要求する（TABLE REQUEST ）。マルチキャストサーバ（ＭＳ）は、加入者端末装置毎の図１０の（ｂ）に示すマルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）を作成し、宛て先ＩＰアドレスをゲートキーパ（ＧＫ）にＨ．２２５．０ＲＡＳメッセージＬＲＱ（Location Request：位置情報要求）により加入者番号に対応するＩＰアドレスをゲートキーパ（ＧＫ）に問い合わせる。
【００８０】
ＬＲＱを受信したゲートキーパ（ＧＫ）はＬＣＦ（Location Confirmation ：位置情報確認）により加入者番号に対応するＩＰアドレスを通知する。ＬＲＱによりマルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）を送出する相手先ＩＰアドレスを認識したマルチキャストサーバ（ＭＳ）は、該当の加入者端末装置に対してマルチキャストサーバ（ＭＳ）で作成したマルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）を送信する。
【００８１】
マルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）を受信した加入者端末装置はＨ．３２３プロトコル端末として立ち上がり、ゲートキーパ（ＧＫ）に対してＨ．２２５．０ＲＡＳメッセージＲＲＱ（Registration Request：登録要求）を送信し、ゲートキーパ（ＧＫ）は加入者端末装置にＲＣＦ（Registration Confirmation ：登録確認）を送出する。ＲＣＦを受信した加入者端末装置はＩＰ告知放送サービスに参加できる放送端末となる。
【００８２】
次に、音声回り込みによる残響雑音の防止を図った実施形態について説明する。図１３は加入者端末装置における放送中のマルチキャスト受信処理を示す。加入者端末装置は、マルチキャスト受信部１３−１により、自装置のマルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）に格納されたマルチキャストＩＰアドレスに該当するＩＰパケットを受信する。
【００８３】
但し、放送音声送出中判別部１３−２により、自装置のアナログ電話機から放送音声を送出している最中かどうかを判別し、放送音声の送出中でないと判別した場合に、マルチキャスト受信処理部１３−３により、マルチキャスト音声パケットを受信してスピーカから放音する処理を実行する。
【００８４】
他方、放送音声送出中判別部１３−２により、自加入者端末装置から放送音声を送出中であると認識した場合、マルチキャスト受信処理中止部１３−４により、マルチキャスト受信処理を中止する。この放送音声の送出中にマルチキャスト受信処理を中止する手段により、放送者の加入者端末装置のスピーカから自分の放送音声が放音されるのを防止し、スピーカから電話機への音声の回り込みによる残響音発生等の音声品質の劣化を防止する。
【００８５】
図１４に放送者の加入者端末装置でマルチキャスト受信処理を中止するシーケンス例を示す。図１４はＨ．３２３のプロトコルを使用した場合のシーケンス例である。発信者からの音声は加入者端末装置にてパケット音声でマルチキャストサーバ（ＭＳ）に送信される（１４−１）。
【００８６】
マルチキャストサーバ（ＭＳ）は、着アドレスをマルチキャストＩＰアドレスに変換して発信加入者のパケット音声を送信する（１４−２）。放送音声送出中の加入者端末装置は、自装置に接続された電話機から放送用電話番号がダイヤル送出され、かつ送話中であることから、ＩＰネットワークから配信される当該マルチキャストを受信しないように受信処理を中止する（１４−３）。
【００８７】
次に、放送者の識別情報を報知する実施形態について説明する。マルチキャストサーバ（ＭＳ）は、放送要求した発信者の音声をマルチキャストする前に、受信した発アドレス情報を基に、発信者の加入者電話番号等の放送者識別情報をマルチキャストＩＰアドレス宛てに通知する手段を備える。この手段により、放送を受信する加入者端末装置では、放送者の加入者電話番号等の放送者識別情報を表示し、放送受信者は誰からの放送であるかを認識することができる。
【００８８】
図１５はＨ．３２３プロトコルを使用した場合の放送者識別情報通知シーケンスの例である。発信者からの放送用電話番号がダイヤル送出され、発信者の加入者端末装置とマルチキャストサーバ（ＭＳ）と間でＨ．２４５ネゴシエーションが確立されると（１５−１）、マルチキャストサーバ（ＭＳ）はＲＴＣＰ（Real Time Transport Protocol）による発信者の加入者端末装置情報（発アドレス情報）をマルチキャストすることにより、放送受信する全加入者端末装置に放送者識別情報を通知する（１５−２）。
【００８９】
マルチキャストの受信加入者端末装置は、通知された発信者の加入者端末装置情報（発アドレス情報）を自加入者端末装置に表示する。その後、放送者の加入者端末装置からマルチキャストサーバ（ＭＳ）にＨ．２２５．０ＲＴＰによる音声ストリームが送出され、マルチキャストサーバ（ＭＳ）は、該音声ストリームを受信してマルチキャストＩＰアドレス宛てへ送信する（１５−３）。
【００９０】
次に、加入者端末装置からマルチキャスト受信を通知する実施形態について説明する。各加入者端末装置は、マルチキャストサーバ（ＭＳ）からのマルチキャストパケットを受信すると、マルチキャストサーバ（ＭＳ）に対して、放送受信中である旨を通知する手段を備える。
【００９１】
この手段により、マルチキャストサーバ（ＭＳ）は、放送受信対象の全加入者端末装置の放送受信状態を把握することができ、放送受信中の加入者端末装置をマルチキャストサーバ（ＭＳ）で確認することが可能となる。
【００９２】
加入者端末装置からマルチキャスト受信中の旨を通知するの実施形態のシーケンスの例を図１６に示す。発信者の加入者端末装置からマルチキャストサーバ（ＭＳ）にＨ．２２５．０ＲＴＰによる音声ストリームが送出され、マルチキャストサーバ（ＭＳ）から該音声ストリームがマルチキャスト送信（１６−１）されているときに、マルチキャスト受信中の各加入者端末装置からマルチキャストサーバ（ＭＳ）に対して、マルチキャスト受信中の旨を示すＲＴＣＰ（Receiver Report ）メッセージを送信する（１６−２）。
【００９３】
前述の放送受信中の加入者端末装置の確認において、マルチキャストサーバ（ＭＳ）は、マルチキャスト送信中に該マルチキャストＩＰアドレス宛てに、放送受信状態問い合わせパケットを送信し、該放送受信状態問い合わせパケットを受信した加入者端末装置がマルチキャストサーバ（ＭＳ）宛てに、放送受信状態応答パケットを返信する構成とすることもできる。
【００９４】
この実施形態のシーケンス例を図１７に示す。発信者の加入者端末装置からマルチキャストサーバ（ＭＳ）にＨ．２２５．０ＲＴＰプロトコルによる音声ストリームが送出され、マルチキャストサーバ（ＭＳ）から該音声ストリームがマルチキャスト送信（１７−１）されているときに、マルチキャストサーバ（ＭＳ）からマルチキャスト受信中の各加入者端末装置に対して、放送受信状態問い合わせパケットＲＴＣＰ(Send Report) を発信し（１７−２）、該パケットを受信した加入者端末装置は、マルチキャストサーバ（ＭＳ）へマルチキャスト受信中の旨を示すＲＴＣＰ（Receiver Report ）メッセージを返信する（１７−３）。
【００９５】
従来のＴＤＭＡ方式による放送システムは、各加入者端末装置毎にパスを設定するマルチパス方式のものであり、各加入者端末装置毎に受信確認を行うには、ポーリング方式のように複雑で時間の掛かるシステム固有の問い合わせ手段を用いていたが、本発明はＩＰネットワークの汎用プロトコルにより容易に受信確認を行うことができる。
【００９６】
次に、放送者に放送受信加入者装置の識別情報を通知する実施形態について説明する。前述の実施形態により、放送受信中の加入者端末装置を確認したマルチキャストサーバ（ＭＳ）は、マルチキャスト送信終了時に、放送要求した発信者の加入者端末装置に、放送受信を確認した加入者端末装置の識別情報を通知する手段を備える。この手段により、放送者は放送を受信した加入者端末装置がどれであったかを確認することができる。
【００９７】
図１８に放送者に放送受信加入者装置の識別情報を通知するシーケンスの例を示す。発信加入者端末装置からマルチキャストサーバ（ＭＳ）にＨ．２２５．０ＲＴＰプロトコルによる音声ストリームが送出され、該音声ストリームがマルチキャストサーバ（ＭＳ）からマルチキャスト送信（１８−１）されているときに、加入者端末装置からのマルチキャスト受信中の旨を示すＲＴＣＰ（Receiver Report ）メッセージを受信すると（１８−２）、マルチキャストサーバ（ＭＳ）は、放送受信中の加入者端末装置を認識し、該加入者端末装置の識別情報を保持する。
【００９８】
その後、発信者が放送を終了し、発信者の加入者端末装置からＨ．３２３Ｑ．９３１呼制御メッセージによる切断（ＤＩＳＣ）メッセージがゲートキーパ（ＧＫ）を経由してマルチキャストサーバ（ＭＳ）に送信される（１８−３）と、マルチキャストサーバ（ＭＳ）は、受信加入者端末装置に終了（Ｂｙｅ）メッセージを送信（１８−４）するとともに、発信加入者端末装置に送信する解放（ＲＥＬ）メッセージに、マルチキャストサーバ（ＭＳ）が認識した放送受信加入者端末装置の識別情報を載せて通知し（１８−５）、発信者（放送者）は該識別情報により、放送を受信した加入者を認識することができる（１８−６）。
【００９９】
次に、音声蓄積機能を備えた実施形態について説明する。図１９はマルチキャストサーバ（ＭＳ）に音声データ蓄積手段を備えた第１の実施形態の説明図である。マルチキャストサーバ（ＭＳ）は、放送用電話番号及び放送音声を含むユニキャストＩＰパケットを受信すると、放送用電話番号−マルチキャストＩＰアドレス対応テーブル（ＴＢＬ２）を参照し、受信した放送用電話番号に対応したマルチキャストＩＰアドレス宛てに、放送音声のＩＰパケットをマルチキャスト送信するとともに、音声データ蓄積部１９−１に該放送用電話番号及び放送音声データを蓄積する。
【０１００】
その後、放送音声データの再生用電話番号をゲートキーパ（ＧＫ）から受信すると、マルチキャストサーバ（ＭＳ）は、蓄積データ検索部１９−２により、受信した再生用電話番号に対応する放送音声蓄積データを検索し、その蓄積データが存在すれば、再生要求した発信者ヘ該放送音声データをパケット送信する。従って、再度又は後刻に放送を聴きたい加入者は、アナログ電話機から再生用電話番号のダイヤル操作を行うことにより、録音放送を任意に聴取することができる。
【０１０１】
前述の実施形態のシーケンス例を図２０に示す。図２０はＨ．３２３プロトコルを使用した場合の放送録音再生シーケンスを示している。発信加入者端末装置からマルチキャストサーバ（ＭＳ）にＨ．２２５．０ＲＴＰプロトコルによる音声ストリームが送出され、マルチキャストサーバ（ＭＳ）は該音声ストリームをマルチキャスト送信すると同時に、マルチキャストサーバ（ＭＳ）内の音声データ蓄積部に該パケット音声データを蓄積する（２０−１）。
【０１０２】
放送終了後、任意の加入者端末装置から録音放送の再生用電話番号がダイヤルされると（２０−２）、着アドレス情報に再生用電話番号を含んだＳＥＴＵＰメッセージをマルチキャストサーバ（ＭＳ）が受信すると（２０−３）、マルチキャストサーバ（ＭＳ）は内部に蓄積したパケット音声を、該加入者端末装置に対してＨ２２５．０ＲＴＰプロトコルにより音声ストリームとして送信し（２０−４）、該加入者端末装置は該音声ストリームをマルチキャスト受信と同様に受信し、スピーカをオンにして再生音を放送する（２０−５）。
【０１０３】
図２１は録音有無の放送種別に応じて音声蓄積する実施形態の説明図である。マルチキャストサーバ（ＭＳ）は、放送用電話番号及び放送音声を含むユニキャストＩＰパケットを受信すると、放送用電話番号−マルチキャストＩＰアドレス対応テーブル（ＴＢＬ２）を参照し、受信した放送用電話番号の放送種別が「録音有り」であるか「録音無し」であるか判定する録音有無判別部２１−１を備える。
【０１０４】
放送種別が「録音無し」である場合、受信した放送用電話番号に対応したマルチキャストＩＰアドレス宛てに放送音声のＩＰパケットをマルチキャスト送信するだけで、録音（音声データの蓄積）は行わない。一方、放送種別が「録音有り」である場合、放送音声のＩＰパケットをマルチキャスト送信するとともに、音声データ蓄積部２１−２に該放送用電話番号及び放送音声データを蓄積する。
【０１０５】
即ち、音声データ蓄積部２１−２には、放送用電話番号−マルチキャストＩＰアドレス対応テーブル（ＴＢＬ２）により「録音有り」と解析された放送種別の放送番号に該当する放送音声データのみを蓄積する。従って、放送要求した発信者の意図により、自己の放送する放送内容の録音／非録音を選択することができる。
【０１０６】
マルチキャストサーバ（ＭＳ）は、再生用電話番号をゲートキーパ（ＧＫ）から受信すると、蓄積データ検索部２１−３により、受信した再生用電話番号に対応する放送音声蓄積データを検索し、その蓄積データが存在すれば、再生要求した発信者ヘ該放送音声データをパケット送信する。
【０１０７】
前述の図２１に示した実施形態のシーケンス例を図２２に示す。同図はＨ．３２３プロトコルを使用した場合の録音指定のシーケンス例である。発信者から「録音有り」の放送種別の放送用電話番号がダイヤルされ（２２−１）、加入者端末装置からのＳＥＴＵＰメッセージに「録音有り」の放送種別を含む着アドレス情報がマルチキャストサーバ（ＭＳ）に送信される（２２−２）。
【０１０８】
発信者の加入者端末装置からマルチキャストサーバ（ＭＳ）にＨ．２２５．０ＲＴＰプロトコルによる音声ストリームが送出されると、「録音有り」の放送種別を受信したマルチキャストサーバ（ＭＳ）は、該音声ストリームをマルチキャスト送信するのと同時に、マルチキャストサーバ（ＭＳ）内の音声データ蓄積部部にそのパケット音声データを蓄積する（２２−３）。
【０１０９】
図２３は所定回数再生放送する音声データ蓄積再生手段の実施形態の説明図である。マルチキャストサーバ（ＭＳ）は、放送用電話番号及び放送音声を含むユニキャストＩＰパケットを受信すると、放送用電話番号−マルチキャストＩＰアドレス対応テーブル（ＴＢＬ２）により、受信した放送用電話番号の放送種別が「録音有り」であるか「録音無し」であるか判定するとともに、該放送用電話番号の付加番号により指定される再生放送回数を判別する手段２３−１を備える。
【０１１０】
放送種別が「録音無し」である場合、受信した放送用電話番号に対応したマルチキャストＩＰアドレス宛てに放送音声データのＩＰパケットをマルチキャスト送信するだけで、録音（音声データの蓄積）は行わない。一方、放送種別が「録音有り」である場合、放送音声データのＩＰパケットをマルチキャスト送信するとともに、音声データ蓄積部２３−２に該放送用電話番号、放送音声データ及び再生回数を蓄積する。
【０１１１】
音声データ蓄積部２３−２は、蓄積された放送用電話番号及び放送音声データを、再生回数として指定された回数だけ読み出し、放送用電話番号に対応したマルチキャストＩＰアドレス宛てに放送音声データのＩＰパケットをマルチキャスト送信する。
【０１１２】
従って、放送者の音声による放送終了後に、マルチキャストサーバ（ＭＳ）に蓄積された放送音声データを、放送用電話番号により指定された回数だけ繰り返して送信し、放送要求した発信者が意図した回数だけ自動的に繰り返される放送を行うことができる。
【０１１３】
前述の図２３に示した実施形態のシーケンス例を図２４に示す。同図はＨ．３２３プロトコルを使用した場合の再生回数指定による放送のシーケンス例を示している。発信者が再生放送回数を指定する放送種別の放送用電話番号をダイヤルし（２４−１）、加入者端末装置からのＳＥＴＵＰメッセージに該放送種別を含む着アドレス情報がマルチキャストサーバ（ＭＳ）に受信される（２４−２）。
【０１１４】
発信者の加入者端末装置からマルチキャストサーバ（ＭＳ）にＨ．２２５．０ＲＴＰプロトコルによる音声ストリームが送出され、マルチキャストサーバ（ＭＳ）から該音声ストリームがマルチキャストされているときに、マルチキャストサーバ（ＭＳ）は、内部の音声データ蓄積部に該音声ストリームのパケット音声を蓄積する（２４−３）。
【０１１５】
発信者による放送終了後、マルチキャストサーバ（ＭＳ）は、指定された放送種別及び放送回数に従い、音声データ蓄積部に蓄積されたパケット音声を、同じマルチキャストＩＰアドレス宛てに、Ｈ．２２５．０ＲＴＰプロトコルによる音声ストリームとして送出する（２４−４）。
【０１１６】
次に、前述した各音声蓄積手段における蓄積音声の消去の実施形態について説明する。前述の音声データ蓄積部に蓄積された音声データは、放送終了後、一定時間内にアナログ電話機から再生用電話番号が送出されず、蓄積データが所定時間以上読み出されない状態が継続すると、マルチキャストサーバ（ＭＳ）は、該放送音声データを音声データ蓄積部から消去する手段を備える。この手段により、「録音有り」の放送種別の放送が多数要求された場合に、音声データ蓄積部のメモリ領域が不足する事態を防ぐことができる。
【０１１７】
次にメールボックスに音声データを格納する実施形態について説明する。図２５に示すように、マルチキャストサーバ（ＭＳ）は、放送用電話番号及び放送音声データを含むユニキャストＩＰパケットを受信すると、放送用電話番号−マルチキャストＩＰアドレス対応テーブル（ＴＢＬ２）参照し、受信した放送用電話番号に対応したマルチキャストＩＰアドレス宛てに、放送音声のＩＰパケットをマルチキャスト送信するとともに、メールボックス２５−１に該放送用電話番号及び放送音声データを蓄積する。
【０１１８】
メールボックス２５−１は、記憶領域が加入者端末装置毎に区分けされ、各加入者端末装置毎のメールボックス領域部に放送音声データが個々に蓄積される。放送要求した発信者の音声データは、マルチキャスト対象の各入者端末装置のメールボックス領域部にのみ蓄積され、受信加入者からの再生用電話番号をゲートキーパ（ＧＫ）から受信すると、マルチキャストサーバ（ＭＳ）は、メールボックス内蓄積データ検索部２５−２により、受信した再生用電話番号に対応する放送音声蓄積データを、その受信加入者のメールボックス領域部から検索して読み出し、再生要求した加入者ヘ該放送音声をパケット送信する。
【０１１９】
また、マルチキャストサーバ（ＭＳ）は、各メールボックス内の音声データ蓄積状態（放送音声データの有無）を監視し、該メールボックス内蓄積状態通知部２５−３により、メールボックス内の音声データ蓄積状態を各加入者端末装置に通知し、加入者端末装置は、通知された自己のメールボックスの音声データ蓄積状態を可視又は可聴表示する。この手段により、加入者は自己のメールボックスに格納された録音放送の有無を認識することができる。
【０１２０】
前述の実施形態のシーケンス例を図２６及び図２７に示す。同図はＨ．３２３プロトコルを使用するメールボックス形式の放送録音再生シーケンスの例を示している。発信者が「録音有り」の放送種別の放送用電話番号をダイヤルし、加入者端末装置からのＳＥＴＵＰメッセージに上記放送種別を含む着アドレス情報がマルチキャストサーバ（ＭＳ）に送信される（２６−１）。
【０１２１】
発信者の加入者端末装置からマルチキャストサーバ（ＭＳ）にＨ．２２５．０ＲＴＰプロトコルによる音声ストリームが送出され、放送種別が「録音有り」の場合、マルチキャストサーバ（ＭＳ）は、音声ストリームをマルチキャスト送信すると同時に、マルチキャストサーバ（ＭＳ）内部の加入者毎のメールボックスにパケット音声を蓄積する（２６−２）。
【０１２２】
図２６では加入者番号＃３のメールボックスにパケット音声を蓄積したものとする。マルチキャストサーバ（ＭＳ）は、メールボックスにデータが蓄積された加入者番号の加入者端末装置に対して、図２７に示すようにメールボックス情報通知を行い（２７−１）、放送が録音されている旨を放送受信対象者に可視又は可聴表示により通知する。
【０１２３】
放送受信対象者の電話機から再生用電話番号がダイヤルされると（２７−２）、その加入者端末装置は着アドレス情報に再生用番号を含んだＳＥＴＵＰメッセージをマルチキャストサーバ（ＭＳ）に送信し、マルチキャストサーバ（ＭＳ）は内部にメールボックス形式で蓄積した該加入者宛てのパケット音声を、該加入者端末装置に対してＨ２２５．０ＲＴＰプロトコルによる音声ストリームとして送出する（２７−３）。該加入者端末装置では、マルチキャスト受信の場合と同様にスピーカをオンにし、再生された録音放送を放音する（２７−４）。
【０１２４】
次に、音声データ蓄積手段を加入者端末装置に備えた実施形態について説明する。図２８に示すように、加入者端末装置は、マルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）に格納されたＩＰアドレスに、受信パケットのＩＰアドレスが合致するかどうかを判別する手段２８−１を備え、該判別手段２８−１により合致を検出した場合、該パケットの音声データを、スピーカ再生部２８−２により再生してスピーカから放音するとともに、該パケットに含まれる放送用電話番号及び音声データを、音声データ蓄積部２８−３に格納する。
【０１２５】
その後、加入者端末装置に接続されたアナログ電話機から、蓄積された放送音声データの再生用電話番号を受信すると、蓄積データ検索部２８−４により、その再生用電話番号に対応する放送音声蓄積データを検索し、対応する放送音声蓄積データが存在する場合、該蓄積音声データを読み出し、スピーカ再生部２８−２により再生してスピーカから放音する。
【０１２６】
また、加入者端末装置は、放送録音状態表示部２８−５を備え、該放送録音状態表示部２８−５は、音声データ蓄積部２８−３に蓄積された放送音声データが存在するか否かを表示する。
【０１２７】
このような構成により、自加入者端末装置の改良のみで、放送受信対象加入者は録音放送の有無を認識し、アナログ電話機から再生用電話番号のダイヤル操作を行って録音放送を随時聴取することができる。
【０１２８】
前述の図２８に示した実施形態のシーケンス例を図２９に示す。加入者端末装置はマルチキャストサーバ（ＭＳ）からＨ２２５．０ＲＴＰプロトコルによりパケット音声を受信すると（２９−１）、該音声をスピーカから放音するとともに加入者端末装置内部の音声データ蓄積部に該パケット音声を蓄積する（２９−２）。
【０１２９】
マルチキャスト終了後、加入者端末装置はスピーカをオフにするとともに、録音放送の有無を可視又は可聴表示により加入者に知らせる（２９−３）。加入者の再生ボタン押下等の端末操作により、加入者端末装置は蓄積された音声パケットデータを読み出し、スピーカをオンにし、録音放送を再生する（２９−４）。
【０１３０】
次に、優先度に応じて受信するマルチキャストを選択する実施形態について説明する。図３０に示すように、加入者端末装置内のマルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）は、各マルチキャストＩＰアドレスをその優先度に応じた優先順位を付して格納する。
【０１３１】
複数の放送要求発信者から放送用電話番号がダイヤルされ、マルチキャストサーバ（ＭＳ）から各放送用電話番号に対応するマルチキャストＩＰアドレスのパケットがＩＰネットワーク上に同時に配信された場合、加入者端末装置は、図３０に示す優先順位を付けたマルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）を参照し、複数のマルチキャストの中から該優先順位に応じて、放音するマルチキャストを一つ選択する。
【０１３２】
そして、選択されたマルチキャストを直ちにスピーカにより放音し、優先順位が低く選択されなかったマルチキャストに対しては、前述の図２７又は図２８に示した音声データ蓄積手段を用いて蓄積し、後刻、再生して放音することにより、同時に配信された放送を漏れなく聴取させることができる。
【０１３３】
次に、複数の放送要求が重複して発生した場合に、先発放送を優先的に放送する実施形態について説明する。図３１は先発放送を優先的に放送する実施形態の説明図である。図３１の（ａ）は、加入者番号＃１〜＃３を受信者対象とする放送用電話番号＃Ａの放送が先発放送としてマルチキャストされているときに、加入者番号＃４〜＃６を受信者対象とする放送用電話番号＃Ｂの放送が後発放送としてマルチキャストされた場合を示す。
【０１３４】
この場合の第１の実施形態として、マルチキャストサーバ（ＭＳ）は無条件で先発放送を優先させて放送する制御を行い、マルチキャストサーバ（ＭＳ）がＳＥＴＵＰメッセージの着アドレス情報として受信する放送用電話番号＃Ａと放送用電話番号＃Ｂとが重複したとき、マルチキャストサーバ（ＭＳ）は先に受信した放送用電話番号＃Ａを優先させ、放送用電話番号＃ＢのＳＥＴＵＰメッセージに対して通話拒否の応答を行う。
【０１３５】
従って、マルチキャストサーバ（ＭＳ）は放送用電話番号＃Ａに該当するマルチキャストをＩＰネットワーク（ＬＡＮ）上に送信し、加入者番号＃１〜＃３の加入者に対する放送用電話番号＃Ａの放送のみをマルチキャスト送信する。
【０１３６】
次に、先発放送を優先的に放送する第２の実施形態について説明する。図３１の（ｂ）は、加入者番号＃１〜＃３を受信者対象とする放送用電話番号＃Ａの放送が先発放送としてマルチキャストされているときに、加入者番号＃３〜＃５を受信者対象とする放送用電話番号＃Ｂの放送が後発放送としてマルチキャストされた場合を示す。
【０１３７】
マルチキャストサーバ（ＭＳ）がＳＥＴＵＰメッセージの着アドレス情報として放送用電話番号＃Ａと放送用電話番号＃Ｂとを受信した場合、マルチキャストサーバ（ＭＳ）は、それぞれの放送用電話番号の受信対象加入者端末装置をチェックし、加入者端末装置が重複している場合のみ優先制御する。
【０１３８】
従って、マルチキャストサーバ（ＭＳ）は、図３１の（ｂ）に示すように、加入者番号＃３が両放送用電話番号＃Ａ及び＃Ｂの受信対象となっている場合に、先に放送した放送用電話番号＃Ａを優先させ、後発の放送用電話番号＃ＢのＳＥＴＵＰメッセージに対して通話拒否し、マルチキャストサーバ（ＭＳ）は放送用電話番号＃Ａに該当するマルチキャストをＩＰネットワーク（ＬＡＮ）上送信する。
【０１３９】
しかし、図３１の（ａ）に示すように、放送用電話番号＃Ａと放送用電話番号＃Ｂとに重複する受信対象加入者が存在しない場合には、放送用電話番号＃Ａと放送用電話番号＃Ｂの両方の放送を同時にマルチキャストする。
【０１４０】
図３２は受信対象加入者重複時の先発放送優先制御のフローを示している。マルチキャストサーバ（ＭＳ）は放送用電話番号を受信すると（３２−１）、そのとき既にマルチキャスト送信中であるかどうかをチェックし（３２−２）、マルチキャスト送信中であれば、送信中の先発放送の受信加入者端末装置と、これから送信しようとする後発放送の受信加入者端末装置とで、重複する加入者端末装置が存在するかどうかをチェックし（３２−３）、重複する加入者端末装置が存在する場合は、先発放送を優先させ、後発放送の加入者からの放送要求に対して、放送不可として該放送要求を破棄する（３２−４）。
【０１４１】
そして、先発放送のマルチキャスト送信がない場合、又は、先発放送の受信加入者端末装置と後発放送の受信加入者端末装置とで、重複する加入者端末装置が存在しない場合、マルチキャストサーバ（ＭＳ）は、前述のように放送用電話番号−マルチキャストＩＰアドレス対応テーブル（ＴＢＬ２）を参照し（３２−５）、マルチキャスト送信を実行する（３２−６）。
【０１４２】
このような構成により、複数の加入者から同時期に放送用電話番号がダイヤルされた場合、既に放送中の先発放送を優先させることにより、先発放送が中断又は妨害されることを保護することができる。
【０１４３】
次に、後発放送を放送する実施形態について説明する。図３３の（ａ）は後発放送を優先的に放送する実施形態の説明図である。同図に示すように、加入者番号＃３が先発放送用電話番号＃Ａ及び後発放送用電話番号＃Ｂの受信対象となる場合に、先発放送用電話番号＃Ａの放送を中断し、後発放送用電話番号＃Ｂの放送を優先させて放送する。
【０１４４】
図３４は前述した後発放送優先のマルチキャストサーバ（ＭＳ）における制御フローを示す。マルチキャストサーバ（ＭＳ）は、放送用電話番号を受信すると（３４−１）、その時点で実行されているマルチキャスト送信状態をチェックし（３４−２）、マルチキャスト送信実行中であれば、送信実行中の先発放送の受信加入者端末装置と、これから送信しようとする後発放送の受信加入者端末装置とで、重複する加入者端末装置が存在するかどうかをチェックする（３４−３）。
【０１４５】
そして、重複する加入者端末装置が存在する場合は、放送用電話番号−マルチキャストＩＰアドレス対応テーブル（ＴＢＬ２）を参照し（３４−４）、先発マルチキャストを中断して（３４−５）、後発マルチキャスト送信を優先させて実行する（３４−６）。
【０１４６】
なお、先発放送のマルチキャスト送信がない場合、又は、先発放送と後発放送とで重複する加入者端末装置が存在しない場合、マルチキャストサーバ（ＭＳ）は、放送用電話番号−マルチキャストＩＰアドレス対応テーブル（ＴＢＬ２）を参照し（３４−７）、マルチキャスト送信を実行する（３４−８）。
【０１４７】
このような構成により、複数の加入者から同時期に放送用電話番号がダイヤルされた場合、先発放送を中断し、後発放送を優先させて放送する構成とすることができる。特に、後発放送の放送種別が緊急度の高い放送である場合に、後発優先とすることにより、受信加入者に緊急性の高い報知内容を直ちに放送することができる。
【０１４８】
図３３の（ｂ）は後発放送を録音し、後で録音データを再生して放送する実施形態の説明図である。同図に示すように、加入者番号＃３が先発放送用電話番号＃Ａ及び後発放送用電話番号＃Ｂの受信対象となる場合に、先発放送用電話番号＃Ａの放送を継続し、後発放送用電話番号＃Ｂの放送を録音する。そして、先発放送用電話番号＃Ａの放送終了後、後発放送用電話番号＃Ｂの録音を再生して放送する。
【０１４９】
図３５は前述の図３３の（ｂ）に示した実施形態のマルチキャストサーバ（ＭＳ）における制御フローを示す。マルチキャストサーバ（ＭＳ）は、放送用電話番号を受信すると（３５−１）、その時点で実行されているマルチキャスト送信状態をチェックし（３５−２）、マルチキャスト送信中であれば、送信中の先発放送の受信加入者端末装置と、これから送信しようとする後発放送の受信加入者端末装置とで、重複する加入者端末装置が存在するかどうかをチェックする（３５−３）。
【０１５０】
そして、重複する加入者端末装置が存在する場合は、先発放送を継続してマルチキャスト送信し、放送用電話番号−マルチキャストＩＰアドレス対応テーブル（ＴＢＬ２）を参照して（３５−４）、後発放送要求者の音声を音声データ蓄積手段に格納する（３５−５）。
【０１５１】
その後、先発放送がなおマルチキャスト送信中であるかどうかをチェックし（３５−６）、マルチキャスト送信中であれば、所定タイミングを計時（３５−７）した後、再び先発放送がマルチキャスト送信中であるかどうかをチェックする（３５−６）。
【０１５２】
先発放送のマルチキャスト送信の終了を検出すると、マルチキャストサーバ（ＭＳ）に蓄積した後発放送者の音声データをマルチキャスト送信する（３５−８）。なお、先発放送のマルチキャスト送信がない場合、又は、先発放送の受信加入者端末装置と後発放送の受信加入者端末装置とで、重複する加入者端末装置が存在しない場合、マルチキャストサーバ（ＭＳ）は、放送用電話番号−マルチキャストＩＰアドレス対応テーブル（ＴＢＬ２）を参照し（３５−９）、マルチキャスト送信を実行する（３５−１０）。
【０１５３】
このような構成により、複数の加入者から同時期に放送用電話番号がダイヤルされた場合、先発放送は中断されることなく、また後発放送も拒否されることなく、両者の放送内容を受信加入者に報知することができる。
【０１５４】
【発明の効果】
以上説明したように、本発明によれば、汎用のＩＰネットワーク上に放送用電話番号の受信によりマルチキャスト送信を実行するマルチキャストサーバを設置し、放送者から送信されたパケット音声を該マルチキャストサーバからマルチキャスト送信することにより、汎用性を有するＩＰネットワーク上で放送音声を配信することができ、システムの拡張が容易で他のＩＰ通信サービスと併存することができる柔軟性に富んだ放送システムを構築することができる。
【０１５５】
また、ＩＰネットワーク上での放送サービスにおいて共通のマルチキャストサーバを設けることにより、各加入者端末装置に特殊なマルチキャスト送信機能を具備する必要がなく、一つのマルチキャストサーバにより、ＩＰネットワーク上に送信するマルチキャスト数やトラヒックの制御（優先制御）、録音及び受信確認等の放送の一元管理を行うことができる。
【０１５６】
また、本発明はマルチキャストサーバ（ＭＳ）において、発アドレス情報から発信者の放送資格をチェックする手段を備えることにより、安全な運用管理を行うことが可能となる。また、マルチキャストサーバに、複数の放送用電話番号に対応するマルチキャストＩＰアドレスを格納したテーブルを備えることにより、複数の放送種別の放送を行うことを可能にする。
【０１５７】
また、各加入者端末装置に具備する受信マルチキャストＩＰアドレスの格納テーブルをマルチキャストサーバで作成し、マルチキャストサーバから各加入者端末装置に該テーブルを送信することにより、マルチキャストサーバからの遠隔操作で全加入者端末装置の該テーブルを更新することができる。
【０１５８】
また、マルチキャストサーバから放送者の発アドレス情報を受信対象加入者端末装置にマルチキャスト送信することにより、受信対象加入者は放送者が誰であるのかを認識することができる。また、受信対象加入者から受信状態情報をマルチキャストサーバを介して発信者の加入者端末装置に送信することにより、ＩＰネットワークの汎用プロトコルを用いて容易に受信確認を行うことができる。
【０１５９】
また、マルチキャストサーバに録音手段を設けることにより、受信対象加入者は、繰り返し又は後刻放送音声を聴取することができる。また、放送用電話番号に録音有無の放送種別を表す番号を設け、録音有りの放送種別の放送用電話番号が送出された場合のみ、放送音声を録音することにより、必要な放送だけを効率よく蓄積することができる。
【０１６０】
また、マルチキャストサーバで同時に複数の放送が要求された場合に、送信するマルチキャストを優先度に応じて選択し、送信数を制限することにより、マルチキャストによるＩＰネットワークのトラフィック負荷をマルチキャストサーバで調整することができる。
【０１６１】
また、同時に放送されるマルチキャスト送信に重複した受信対象加入者が存在した場合、マルチキャストサーバは一つの放送を優先度に応じて選択し、加入者が聴取できない無駄なマルチキャストをＩＰネットワークに送出しないため、ＩＰネットワーク上のトラフィック負荷を低減させことができる。
【０１６２】
また、同時に放送されるマルチキャスト送信に重複した受信対象加入者が存在した場合、後発放送に対して録音機能を利用して蓄積し、先発放送の終了後、後発放送を再生して放送し、ＩＰネットワーク上に一放送ずつ送出することにより、放送重複加入者は先発及び後発の両放送を聴取することができ、かつＬＡＮのトラフィック負荷を低減させることができる。
【図面の簡単な説明】
【図１】本発明のマルチキャストによる放送システムの構成図である。
【図２】本発明のマルチキャストによる放送システムの枢要部の動作シーケンスを示す図である。
【図３】本発明のマルチキャストによる放送を実行するメッセージシーケンスの例を示す図である。
【図４】放送可否加入者番号テーブルを具備したマルチキャストサーバ（ＭＳ）の説明図である。
【図５】放送資格判別を行うマルチキャストのシーケンス例を示す図である。
【図６】放送資格判別を行うマルチキャストのシーケンス例を示す図である。
【図７】放送用電話番号毎に放送種別を割り当てるテーブルの説明図である。
【図８】複数の放送用電話番号を割り当てたマルチキャストのシーケンス例を示す図である。
【図９】放送用電話番号−マルチキャストＩＰアドレス対応テーブルの説明図である。
【図１０】放送用電話番号−マルチキャストＩＰアドレス対応テーブルの説明図である。
【図１１】加入者端末装置のテーブルを更新するシーケンス例を示す図である。
【図１２】加入者端末装置のテーブルを更新するシーケンスの例を示す図である。
【図１３】加入者端末装置における放送中のマルチキャスト受信処理の説明図である。
【図１４】発信加入者端末装置でのマルチキャスト受信処理中止のシーケンス例を示す図である。
【図１５】放送者識別情報通知シーケンス例を示す図である。
【図１６】マルチキャスト受信中の旨を通知するシーケンス例を示す図である。
【図１７】マルチキャスト受信中の旨を通知するシーケンス例を示す図である。
【図１８】放送受信加入者装置の識別情報を通知するシーケンス例を示す図である。
【図１９】マルチキャストサーバ（ＭＳ）に備えた音声蓄積手段の説明図である。
【図２０】音声データ蓄積手段による放送録音再生シーケンスを示す図である。
【図２１】録音有無の放送種別に応じた音声蓄積手段の説明図である。
【図２２】録音有無の放送種別に応じた音声蓄積のシーケンス例を示す図である。
【図２３】指定回数再生放送する音声蓄積再生手段の説明図である。
【図２４】指定回数再生放送する音声蓄積再生のシーケンス例を示す図である。
【図２５】メールボックスに音声データを蓄積する音声蓄積手段の説明図である。
【図２６】メールボックスに音声データを蓄積する音声蓄積シーケンス例を示す図である。
【図２７】メールボックスに蓄積された音声データを再生するシーケンス例を示す図である。
【図２８】加入者端末装置に備えた音声蓄積手段の説明図である。
【図２９】加入者端末装置の音声蓄積シーケンス例を示す図である。
【図３０】優先順位を付したマルチキャストＩＰアドレス格納テーブル（ＴＢＬ３）の説明図である。
【図３１】先発放送を優先的に放送する実施形態の説明図である。
【図３２】受信対象加入者重複時の先発放送優先制御のフロー図である。
【図３３】後発放送を放送する実施形態の説明図である。
【図３４】受信対象加入者重複時の後発放送優先制御フロー図である。
【図３５】受信対象加入者重複時、後発放送を録音再生して放送するフロー図である。
【符号の説明】
１−１０加入者端末装置
１−１１アナログ電話機
１−１２放送用スピーカ
１−２０ゲートキーパＧＫ
１−３０マルチキャストサーバＭＳ
１−４０ＩＰネットワーク（ＬＡＮ）[0001]
BACKGROUND OF THE INVENTION
The present invention uses an IP (Internet Protocol) network. Multicast In particular, a multicast server for multicasting a specific unicast voice packet is provided on the IP network, and the voice packet is distributed from the multicast server to a plurality of subscriber terminal devices. Or it is suitable for regular broadcasts and emergency broadcasts in local governments Subscriber terminal device and multicast broadcasting method About.
[0002]
[Prior art]
A conventional broadcasting system is disclosed in, for example, Japanese Patent Application Laid-Open No. 11-88547. In a voice / data sharing communication system using a CATV network, this broadcasting system includes a terminal device at a subscriber's home, a center device at the center side, and a 1: n by using a TDMA (Time Division Multiple Access) system. Broadcast communication is performed.
[0003]
The broadcasting system using the TDMA system includes a communication channel for voice and a communication channel for data, and performs communication using the transmission band effectively. This system uses the TDMA method. Therefore, when an IP network is already constructed using a cable modem or the like as a LAN (Local Area Net Work), it is necessary to construct it as a system different from the existing IP network.
[0004]
As a system for handling voice on an IP network, ITU-T's H.264 standard. Although there is what is recommended as the H.323 protocol, this system is mainly groupware such as a video conference system, and the terminal devices of subscribers participating in the conference can be called and respond to calls. Must be something to do.
[0005]
Therefore, H.264 of ITU-T. A system based on the H.323 protocol is not suitable for a system that unilaterally transmits to a plurality of subscribers regardless of the recipient's intention, such as broadcast, and is a protocol for transmitting audio over an IP network as broadcast. Is not specifically recommended.
[0006]
[Problems to be solved by the invention]
A conventional cable broadcasting network system based on the TDMA system or the like has a problem that the network system has poor versatility, expandability, and flexibility because it is constructed by a specific technical system unique to the cable broadcasting network.
[0007]
The present invention realizes a system for broadcasting voice in a general-purpose IP network environment in the same manner as a conventional broadcasting system, simplifies system construction and expansion, and provides voice packet distribution service (VoIP service) on the same IP network. Multicast broadcast that can coexist with other IP communication services and can change functions and add functions flexibly Method and subscriber terminal device used to implement the method The purpose is to provide.
[0008]
In addition, the present invention can check the qualification of a sender who can broadcast, perform safe operation management of a broadcasting system, perform broadcasting of a plurality of broadcasting types, and receive a subscriber terminal device to be received from a multicast server. The broadcast receiver can confirm the broadcast sender, the broadcast sender can confirm the subscriber who received the broadcast, and the broadcast audio can be recorded as necessary. Multicast broadcast that can broadcast the same broadcast repeatedly and can perform priority control of duplicate broadcasts Method and subscriber terminal device used to implement the method The purpose is to provide.
[0009]
[Means for Solving the Problems]
The subscriber terminal device of the present invention is (1) connected to an IP network. Subscriber terminal equipment Have a multicast IP address A means for determining reception of a voice packet having a multicast IP address corresponding to a broadcast telephone number and stored in advance in the own device, and reception of a voice packet having the multicast IP address from the received packets And a means for turning on the speaker and emitting the voice of the received voice packet from the speaker. Features.
[0010]
In addition, (2) it has a voice data storage means for storing a broadcast telephone number and voice data included in the voice packet to be emitted.
[0011]
(3) When a reproduction telephone number of stored broadcast audio data is received from a connected analog telephone, the corresponding broadcast audio storage data is read out and reproduced, and sound is emitted from a speaker.
[0012]
(4) The speaker is turned off after the end of the sound emission by multicast, and the presence / absence of a recorded broadcast is displayed visually or audibly.
[0013]
(5) A multicast IP address storage table with priorities is provided, and multicast voice packets to be emitted are selected from a plurality of received multicasts according to the priorities.
[0014]
(6) Voice data storage means for storing multicast voice packets not selected because of low priority is provided, and the voice packets stored in response to the request are reproduced and emitted.
[0015]
(7) When multicast is being received, a message indicating that the voice packet is being received is returned to the multicast server that is the transmission source of the voice packet.
[0016]
(8) When an inquiry packet in a multi-packet reception state is received from a multicast server, a message indicating that it is being received is returned.
[0017]
(9) A table for storing the multicast IP address is provided, and the table is updated by an update table sent from the multicast server to the IP address of the own apparatus.
[0018]
Also, (10) when a telephone number for broadcasting is dialed out from a telephone connected to the own device and transmission is in progress, reception is performed so as not to receive a voice packet by the multicast IP address distributed from the IP network. A means for stopping the processing is provided.
[0019]
Further, (11) provided with means for displaying the broadcaster identification information when receiving the broadcaster identification information of the sender before receiving the voice packet having the multicast IP address.
[0020]
In addition, the multicast broadcasting method of the present invention includes (12) a subscriber terminal device connected to an IP network. A multicast broadcast method for delivering voice packets to , A step of transmitting a voice packet from a multicast server to a multicast IP address corresponding to a broadcast telephone number; and a received telephone packet having a multicast IP address in a subscriber terminal device, stored in advance in the own device, A step of determining reception of a voice packet having a multicast IP address corresponding to, and when determining reception of a voice packet having the multicast IP address, the speaker is turned on, and the voice of the received voice packet is transmitted from the speaker. A step of emitting sound, It is characterized by that.
[0029]
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 is a configuration diagram of a multicast broadcasting system according to the present invention. In the figure, 1-10 is a subscriber terminal, 1-11 is a telephone (analog telephone) connected to the subscriber terminal via an analog line, 1-12 is a broadcasting speaker provided in the subscriber terminal, 1-20 is a gatekeeper (GK), 1-30 is a multicast server (MS), 1-40 is an IP network such as a LAN connecting the subscriber terminal device, the gatekeeper (GK) and the multicast server (MS) to each other. .
[0030]
TBL1 is a telephone number-IP address correspondence table provided in the gatekeeper (GK), TBL2 is a broadcast telephone number-multicast IP address correspondence table provided in the multicast server (MS), and TBL3 is a multicast IP address storage table.
[0031]
The subscriber terminal device 1-10 stores the multicast IP that stores the IP address of the multicast packet received by itself from among the multicast packets distributed from the multicast server (MS) 1-30 via the IP network 1-40. It includes an address storage table TBL3, a speaker 1-12 that emits an audio signal of a received multicast packet, and an analog telephone 1-11 that transmits a broadcast audio signal.
[0032]
The gatekeeper (GK) 1-20 includes a telephone number-IP address correspondence table TBL1 in which subscriber telephone numbers are associated with IP addresses, and the multicast server (MS) 1-30 is provided for each broadcasting telephone number. A broadcast telephone number-multicast IP address correspondence table TBL2 associated with different multicast IP addresses is provided.
[0033]
FIG. 2 is a diagram for explaining the operation of the main part of the multicast broadcasting system of the present invention. A caller who intends to broadcast an announcement by voice off-hooks the analog telephone of the subscriber terminal device (2-1), and sends a broadcast telephone number by a dial signal (2-2).
[0034]
The subscriber terminal device of the caller sends an IP packet including data having the broadcast telephone number sent from the analog telephone as the incoming address information and the caller's telephone number as the outgoing address information, as a gatekeeper (GK) (2-3). The gatekeeper (GK) obtains the IP address of the multicast server (MS) from the telephone number for broadcasting as the destination address information included in the received IP packet, using the telephone number-IP address correspondence table (TBL1), and The IP address of the multicast server (MS) is notified to the caller's subscriber terminal (2-4), and the destination address information (telephone number for broadcasting) and caller address information (caller) are sent to the multicast server (MS). (2-5) is notified by IP packet.
[0035]
The multicast server (MS) uses the broadcast telephone number-multicast IP address correspondence table (TBL2) from the destination address information (broadcast telephone number) notified from the gatekeeper (GK), and multicast corresponding to the broadcast telephone number. An IP address is acquired (2-6), and a broadcast confirmation response packet is sent to the gatekeeper (GK) (2-7).
[0036]
The gatekeeper (GK) that has received the broadcast confirmation response packet similarly sends out the broadcast confirmation response packet to the subscriber terminal device (2-8), and the subscriber terminal device that has received the broadcast confirmation response packet. Sends a broadcast start instruction signal to the caller (2-9).
[0037]
The caller's voice is sent as an analog signal from the telephone to the subscriber terminal device (2-10), and the subscriber terminal device converts the analog voice signal into a voice packet, and the voice packet is converted into a multicast server (MS). Unicast transmission to the destination (2-11). The multicast server (MS) multicasts the voice IP packet received from the subscriber terminal device to the multicast IP address corresponding to the broadcast telephone number (2-12).
[0038]
The subscriber terminal device on the receiver side receives the packet addressed to the multicast IP address stored in the multicast IP address storage table (TBL3) of the own device from the multicast IP packets transmitted from the multicast server (MS). Then, the audio data of the packet is converted into an analog audio signal, the speaker is turned on, and the audio is emitted from the speaker (2-13).
[0039]
When the caller finishes the broadcast notification and on-hooks the analog telephone (2-14), the subscriber terminal device notifies the multicast server (MS) via the gatekeeper (GK) of the broadcast end message by unicast (2-15). , 2-16).
[0040]
The multicast server (MS) transmits a broadcast end message to the multicast IP address (2-17), and the subscriber terminal device receiving the packet of the multicast IP address turns off the speaker when receiving the broadcast end message. Thus, broadcasting ends (2-18). With the above system operation, an audio signal can be simultaneously delivered from the analog telephone of one subscriber terminal device to the speakers of a plurality of subscriber terminal devices over the IP network.
[0041]
An example of a protocol message for executing the multicast broadcast sequence described above is shown in FIG. In FIG. Although an example in which a message according to the H.323 protocol is used is shown, the present invention is not limited to this.
[0042]
H. In the H.323 protocol, an H.323 connection between a gatekeeper (GK) and a subscriber terminal device under the gatekeeper (GK). 225.0 RAS protocol message registration, participation, bandwidth reservation, H.264 225.0Q. Call control by messages of the 931 protocol; H.245 protocol message control (master / slave, call capability exchange, logical channel exchange), H.264 A voice stream is transmitted and received by the 225.0 RTP (Real Time Transport Protocol) protocol.
[0043]
In the sequence shown in FIG. 3, when the off-hook signal of the caller telephone is sent to the subscriber terminal device, the subscriber terminal device sends a dial tone (DT) to the telephone, and the caller sends the dial tone (DT). After listening, when the broadcast telephone number is dialed, the subscriber terminal device sends the H.264 to the gatekeeper (GK). An ARQ (Admission Request) that is a 225.0 RAS message is transmitted (3-1), and an ACF (Admission Confirmation) is returned (3-2) from the gatekeeper (GK).
[0044]
From the subscriber terminal that has received the ACF, 225.0Q. A SETUP message (source address information / destination address information), which is a 931 call control message, is transmitted to the multicast server (MS) via the gatekeeper (GK) (3-3).
[0045]
As shown in FIG. 225.0Q. Using the 931 call control message, CALLPROC, ALERT, and CONNECT messages are transmitted and received between the subscriber terminal device and the multicast server (MS) via the gatekeeper (GK) (3-4 to 3-8). A ringback tone (RBT) is sent from the caller terminal device to the caller telephone.
[0046]
H. When negotiation of master / slave, call capability exchange, and logical channel exchange is established between the subscriber terminal device and the multicast server (MS) by the H.245 protocol (3-9), the subscriber terminal device The transmission of the ring back tone (RBT) is stopped, and the subscriber terminal device sends H.264 to the multicast server (MS). An audio stream is transmitted by the 225.0 RTP protocol (3-10).
[0047]
The multicast server (MS) transmits an audio stream transmitted by unicast from a subscriber terminal device to H.264. Transmission is performed to the multicast IP address of the reception target subscriber terminal device using the 225.0 RTP protocol (3-11), and the reception subscriber terminal device turns on the speaker and plays broadcast audio.
[0048]
When the caller finishes the announcement broadcasting and on-hooks the handset, the subscriber terminal device makes an H.264 call. 225.0Q. A disconnection (DISC) message which is a 931 call control message is transmitted to the multicast server (MS) via the gatekeeper (GK) (3-12).
[0049]
The multicast server (MS) is H.264. An end (BYE) message is sent to the broadcast receiving subscriber terminal using RTCP (RTP control protocol), which can periodically send control packets to the subscriber terminal receiving a voice stream according to the 225.0 RTP protocol. Transmit (3-13).
[0050]
The subscriber terminal device that has received the end (BYE) message turns off the speaker and ends the broadcast. Also, the H.264 network is connected between the multicast server (MS) and the subscriber terminal of the broadcaster via the gatekeeper (GK). 225.0Q. The 931 call control message release (REL) message and release completion (RELCOMP) message are transmitted and received, and the broadcast sequence ends (3-14 to 3-15).
[0051]
By adding the functional configuration described below to the configuration of the basic function of the above-described multicast broadcasting system, the multicast broadcasting system of the embodiment with various modifications or improvements can be configured.
[0052]
First, as an embodiment for checking the broadcast qualification of the caller, the above-mentioned multicast server (MS) includes a broadcast permission / prohibition subscriber number table, and before performing multicast transmission, the broadcast qualification of the caller is checked by the table. However, it is possible to adopt a configuration in which multicast transmission is performed only when the sender is a broadcast qualified person.
[0053]
FIG. 4 is a block diagram of a multicast server (MS) having a broadcast availability subscriber number table. The multicast server (MS) includes a broadcast permission / prohibition subscriber number table 4-1 in which the calling address information is associated with broadcast permission / inhibition, and the multicast server (MS) transmits the received calling address information to the broadcast permission / prohibition subscriber number table. A check is made according to 4-1, and a means for determining whether or not the caller can broadcast is provided.
[0054]
When it is determined by this means that the caller can broadcast, as described above, the multicast IP address is determined using the broadcast telephone number-multicast IP address correspondence table (TBL2), and a broadcast confirmation response packet is obtained. To execute multicast transmission.
[0055]
On the other hand, when it is determined that the caller cannot broadcast, a voice packet reception rejection message is transmitted to the caller, and multicast transmission is not performed. In this way, it is possible to provide a function of giving broadcast qualification for each subscriber terminal device of the caller.
[0056]
An example of a protocol message of a broadcast sequence by multicast for determining broadcast qualification is shown in FIGS. 5 and FIG. FIG. 5 is a sequence in which broadcast permission is given to the caller, and FIG. 6 is a sequence in which broadcast permission is not given to the caller.
[0057]
5 and 6, when the multicast server (MS) receives the SETUP message (5-1), the broadcast permission / prohibition subscriber number table associating the received calling address information (caller's telephone number) with the broadcast permission / inhibition information. Then, the broadcasting qualification of the caller is checked (5-2).
[0058]
When the multicast server (MS) determines that the subscriber terminal device of the caller is capable of broadcasting, the multicast server (MS), as shown in FIG. 323Q. 931 call control messages CALLPROC, ALERT, CONNECT messages and H.323 call control messages. ARQ and ACF messages, which are 225.0 RAS messages, are transmitted to and received from the caller subscriber terminal device (5-3 to 5-7), and communication between the caller subscriber terminal and the multicast server (MS) is performed. Establish.
[0059]
When the multicast server (MS) determines that the subscriber terminal device of the caller cannot broadcast, the multicast server (MS) passes through the gatekeeper (GK) as shown in FIG. 323Q. CALPROC, DISC, REL, RELCOMP messages using H.931 call control messages 225.0RAS message ARQ and ACF messages are sent to and received from the caller's subscriber terminal (6-3 to 6-8), and a busy tone (BT) is sent to the caller's telephone, which cannot be broadcast. It becomes.
[0060]
Next, as an embodiment of a broadcasting system having a plurality of broadcasting types, a configuration is adopted in which a plurality of telephone numbers are assigned to the above-described broadcasting telephone numbers, and a different broadcasting type and multicast IP address are assigned to each broadcasting telephone number. Can do. FIG. 7 shows the structure of a table for assigning broadcast types for each broadcast telephone number.
[0061]
As shown in FIG. 7A, the gatekeeper (GK) sets a plurality of broadcast telephone numbers # 1 to #n as IP addresses of the multicast server (MS) in the telephone number-IP address correspondence table (TBL1). Store in association. Also, as shown in FIG. 7 (b), the multicast server (MS) individually enters the broadcast phone number-multicast IP address correspondence table (TBL2) for each broadcast phone number # 1 to #n. A multicast IP address and broadcast type information are stored in association with each other.
[0062]
The gatekeeper (GK) stores a plurality of broadcast telephone numbers # 1 to #n in association with the IP address of the multicast server (MS) to thereby store a plurality of different broadcast telephone numbers from the subscriber device of the caller. It can be received as destination address information and sent to a multicast server (MS).
[0063]
The multicast server (MS) associates a multicast IP address and broadcast type information with different broadcast telephone numbers # 1 to #n, respectively, so that a group of subscriber terminal devices that receive the broadcast (subscriber terminals to be received) Device) for each multicast IP address, and it is possible to select and broadcast a subscriber terminal device group to be broadcasted by a broadcast telephone number.
[0064]
Further, in the multicast server (MS), by associating the broadcast type information with each of the broadcast telephone numbers # 1 to #n, the caller sends out the broadcast telephone number of the desired broadcast type, and the multicast server (MS) Can be configured to perform different types of multicast transmission according to the received broadcast telephone number.
[0065]
As broadcast type information, whether broadcast audio data is stored in a multicast server (MS) and then played back and broadcast is “recorded” broadcast or broadcast audio data is not stored, “no record” broadcast It can be information such as “with urgency” or “without urgency” indicating the type or urgency of broadcasting. The broadcast type information can be identified by an additional number.
[0066]
FIG. 8 shows an example of a multicast broadcast sequence to which a plurality of broadcast telephone numbers are assigned. FIG. This is a broadcast sequence using a plurality of broadcast telephone numbers when the H.323 protocol is used. In the figure, the multicast server (MS) that has received SETUP (broadcast telephone number # 1 as the destination address) uses the broadcast telephone number-multicast IP address correspondence table (TBL2) shown in FIG. The IP address #A is extracted (8-1), and the packet voice from the caller is transmitted to the multicast IP address #A (8-2).
[0067]
When the multicast server (MS) receives the SETUP message (broadcast telephone number # 2 as the destination address) from another subscriber terminal device, the broadcast telephone number-multicast IP address correspondence table (b) in FIG. The multicast IP address #B is extracted from (TBL2) (8-3), and the packet voice from the caller is transmitted to the multicast IP address #b (8-4).
[0068]
Next, an embodiment in which the table in the subscriber terminal device is updated from the multicast server (MS) will be described. The broadcast telephone number-multicast IP address correspondence table (TBL2) provided in the above-described multicast server (MS) is, as shown in FIG. 9A, a reception target subscription for receiving the multicast for each multicast IP address. All the IP addresses of the user terminal devices are stored in association with each other.
[0069]
With this configuration, the multicast server (MS) can recognize which IP address of the subscriber terminal device receives the packet addressed to which multicast IP address, and the information shown in FIG. A multicast IP address storage table (TBL3) can be created for each IP address of the subscriber terminal as shown.
[0070]
The multicast server (MS) transmits the created multicast IP address storage table (TBL3) for each IP address of the subscriber terminal device to the IP address of each subscriber terminal device to be broadcast-received. With this configuration, it is possible to update the multicast IP address storage table (TBL3) provided in the broadcast receiving target subscriber terminal device on the IP network from the multicast server (MS).
[0071]
As another embodiment for updating the table in the subscriber terminal device from the multicast server (MS), the broadcast telephone number-multicast IP address correspondence table (TBL2) provided in the multicast server (MS) is shown in FIG. As shown in 10 (a), for each multicast IP address, all the subscriber telephone numbers of the reception target subscriber terminal devices that receive the multicast can be stored in association with each other.
[0072]
With this configuration, the multicast server (MS) can recognize which telephone number of the subscriber terminal device receives the packet addressed to which multicast IP address. A multicast IP address storage table (TBL3) can be created for each telephone number of a subscriber terminal device as shown.
[0073]
The multicast server (MS) transmits the created multicast IP address storage table (TBL3) for each telephone number of the subscriber terminal device to the IP address of each subscriber terminal device to be broadcast-received. At this time, the multicast server (MS) includes a telephone number-IP address correspondence table (equivalent to the table TBL1 provided in the above-mentioned gatekeeper (GK)), and the telephone number of each subscriber terminal device using the table. Is converted to an IP address and transmitted.
[0074]
Alternatively, the multicast server (MS) does not include a telephone number-IP address correspondence table, and each time the multicast server (MS) updates the multicast IP address storage table (TBL3) of the subscriber terminal device, the gatekeeper ( GK) is provided with means for inquiring the IP address corresponding to the telephone number, the latest subscriber terminal information is obtained from the telephone number-IP address correspondence table (TBL1) provided in the gatekeeper (GK), and from the multicast server (MS). It is also possible to update the multicast IP address storage table (TBL3) of the subscriber terminal device that is the target of broadcast reception on the IP network. In this case, the IP address information of the subscriber terminal device can be centrally managed by the gatekeeper (GK), and unmatching with the table of the subscriber terminal device can be prevented.
[0075]
FIG. 11 shows an example of a sequence of an embodiment in which a table is transmitted from a multicast server (MS) to a subscriber terminal device and updated. When the subscriber terminal device is powered on, a DHCP (Dynamic Host Configuration Protocol) server sends out the subscriber terminal device IP address, multicast server (MS) IP address, and other initial setting files.
[0076]
The subscriber terminal device that has received the initialization file stands up as a host existing on the LAN, and requests the multicast IP address storage table (TBL3) from the multicast server (MS) (TABLE REQUEST). The multicast server (MS) creates a multicast IP address storage table (TBL3) shown in FIG. 9 (b) for each subscriber terminal device, and applies the corresponding request to the subscriber terminal device that has transmitted the TABLE REQUEST request. A multicast IP address storage table (TBL3) is transmitted.
[0077]
The subscriber terminal device that has received the corresponding multicast IP address storage table (TBL3) As a terminal of the H.323 protocol, the H.323 protocol is used for the gatekeeper (GK). A 225.0 RAS message RRQ (Registration Request) is transmitted, and the gatekeeper (GK) transmits an RCF (Registration Confirmation) to the subscriber terminal device. The subscriber terminal device that has received the RCF becomes a broadcast terminal that can participate in a broadcast service based on IP multicast.
[0078]
FIG. 12 shows an example of a sequence of another embodiment in which a table is transmitted from a multicast server (MS) to a subscriber terminal device and updated. When the power of the subscriber terminal device is turned on, the DHCP server sends out the subscriber terminal IP address, the multicast server (MS) IP address, and other initial setting files.
[0079]
The subscriber terminal device that has received the initialization file stands up as a host existing on the LAN, and requests the multicast IP address storage table (TBL3) from the multicast server (MS) (TABLE REQUEST). The multicast server (MS) creates a multicast IP address storage table (TBL3) shown in FIG. 10 (b) for each subscriber terminal device, and sends the destination IP address to the gatekeeper (GK) as H.264. The gatekeeper (GK) is inquired about the IP address corresponding to the subscriber number by a 225.0 RAS message LRQ (Location Request).
[0080]
The gatekeeper (GK) that has received the LRQ notifies the IP address corresponding to the subscriber number by LCF (Location Confirmation). The multicast server (MS) that has recognized the destination IP address to which the multicast IP address storage table (TBL3) is transmitted by the LRQ, has created the multicast IP address storage table ( TBL3) is transmitted.
[0081]
The subscriber terminal that has received the multicast IP address storage table (TBL3) is H.264. As a H.323 protocol terminal, the H.323 protocol terminal is connected to the gatekeeper (GK). A 225.0 RAS message RRQ (Registration Request) is transmitted, and the gatekeeper (GK) transmits an RCF (Registration Confirmation) to the subscriber terminal device. The subscriber terminal device that has received the RCF becomes a broadcast terminal that can participate in the IP notification broadcast service.
[0082]
Next, an embodiment in which reverberation noise due to sound wraparound is prevented will be described. FIG. 13 shows multicast reception processing during broadcasting in the subscriber terminal device. The subscriber terminal device receives an IP packet corresponding to the multicast IP address stored in the multicast IP address storage table (TBL3) of the own device by the multicast receiver 13-1.
[0083]
However, when the broadcast audio transmission in-progress determination unit 13-2 determines whether broadcast audio is being transmitted from the analog telephone of its own device, and when it is determined that broadcast audio is not being transmitted, the multicast reception processing unit The process of receiving a multicast voice packet and emitting sound from the speaker is executed according to 13-3.
[0084]
On the other hand, when the broadcast audio transmission determining unit 13-2 recognizes that the broadcast audio is being transmitted from the subscriber terminal device, the multicast reception process canceling unit 13-4 stops the multicast reception process. By means of canceling the multicast reception process during transmission of the broadcast sound, the broadcast sound is prevented from being emitted from the speaker of the subscriber terminal device of the broadcaster, and reverberation due to the sound wrapping around from the speaker to the telephone Prevents sound quality degradation such as sound generation.
[0085]
FIG. 14 shows a sequence example in which the multicast reception processing is stopped at the subscriber terminal device of the broadcaster. FIG. This is a sequence example when the H.323 protocol is used. Voice from the caller is transmitted to the multicast server (MS) as packet voice at the subscriber terminal device (14-1).
[0086]
The multicast server (MS) converts the destination address into a multicast IP address and transmits the packet voice of the calling subscriber (14-2). The subscriber terminal device that is sending out the broadcast audio does not receive the multicast distributed from the IP network because the broadcast telephone number is dialed out from the telephone connected to the own device and is being transmitted. The reception process is stopped (14-3).
[0087]
Next, an embodiment for notifying broadcaster identification information will be described. The multicast server (MS) notifies broadcaster identification information such as the subscriber's subscriber telephone number to the multicast IP address based on the received caller address information before multicasting the voice of the caller who requested the broadcast. Means. By this means, the subscriber terminal device that receives the broadcast displays broadcaster identification information such as the subscriber's subscriber telephone number, and the broadcast receiver can recognize who the broadcast is from.
[0088]
FIG. It is an example of a broadcaster identification information notification sequence when the H.323 protocol is used. The broadcast telephone number from the caller is dialed out, and H.264 is transmitted between the caller's subscriber terminal and the multicast server (MS). When the H.245 negotiation is established (15-1), the multicast server (MS) multicasts all the subscriber terminal device information (originating address information) of the caller by RTCP (Real Time Transport Protocol), thereby receiving all broadcasts. Broadcaster identification information is notified to the subscriber terminal device (15-2).
[0089]
The multicast receiving subscriber terminal device displays the notified subscriber terminal device information (originating address information) on the own subscriber terminal device. Thereafter, the broadcaster's subscriber terminal device is connected to the multicast server (MS) by H.264. A voice stream by 225.0 RTP is transmitted, and the multicast server (MS) receives the voice stream and transmits it to the multicast IP address (15-3).
[0090]
Next, an embodiment in which multicast reception is notified from a subscriber terminal device will be described. Each subscriber terminal device includes means for notifying the multicast server (MS) that a broadcast is being received when a multicast packet is received from the multicast server (MS).
[0091]
By this means, the multicast server (MS) can grasp the broadcast reception status of all the subscriber terminal devices that are broadcast reception targets, and can confirm the subscriber terminal device that is receiving the broadcast with the multicast server (MS). It becomes possible.
[0092]
FIG. 16 shows an example of a sequence according to the embodiment for notifying the subscriber terminal device that multicast reception is in progress. From the subscriber terminal device of the caller to the multicast server (MS) When a voice stream by 225.0 RTP is transmitted and the voice stream is multicast-transmitted (16-1) from the multicast server (MS), each subscriber terminal device receiving the multicast receives the multicast server (MS). Then, an RTCP (Receiver Report) message indicating that multicast reception is in progress is transmitted (16-2).
[0093]
In the confirmation of the subscriber terminal device receiving the broadcast, the multicast server (MS) transmits the broadcast reception status inquiry packet to the multicast IP address and receives the broadcast reception status inquiry packet during the multicast transmission. The subscriber terminal device may be configured to return a broadcast reception state response packet to the multicast server (MS).
[0094]
A sequence example of this embodiment is shown in FIG. From the subscriber terminal device of the caller to the multicast server (MS) When a voice stream according to the 225.0 RTP protocol is transmitted and the voice stream is multicast-transmitted (17-1) from the multicast server (MS), each subscriber terminal device receiving the multicast from the multicast server (MS) On the other hand, a broadcast reception status inquiry packet RTCP (Send Report) is transmitted (17-2), and the subscriber terminal that has received the packet receives the RTCP (Receiver Report) indicating that multicast reception is in progress to the multicast server (MS). ) Reply the message (17-3).
[0095]
A conventional broadcasting system based on the TDMA system is of a multipath system in which a path is set for each subscriber terminal device, and in order to confirm reception for each subscriber terminal device, it is complicated and time-consuming as in the polling system. However, according to the present invention, reception confirmation can be easily performed by a general-purpose protocol of an IP network.
[0096]
Next, an embodiment for notifying broadcasters of identification information of broadcast receiving subscriber devices will be described. The multicast server (MS) that has confirmed the subscriber terminal device that is receiving the broadcast according to the above-described embodiment confirms the broadcast reception to the subscriber terminal device of the caller that requested the broadcast when the multicast transmission ends. Means for notifying the identification information. By this means, the broadcaster can confirm which subscriber terminal device has received the broadcast.
[0097]
FIG. 18 shows an example of a sequence for notifying broadcasters of identification information of broadcast receiving subscriber devices. From the calling subscriber terminal device to the multicast server (MS) When an audio stream according to the 225.0 RTP protocol is transmitted and multicast transmission (18-1) is performed from the multicast server (MS), RTCP (Receiver) indicating that multicast reception from the subscriber terminal is being performed. When the (Report) message is received (18-2), the multicast server (MS) recognizes the subscriber terminal device receiving the broadcast, and holds the identification information of the subscriber terminal device.
[0098]
Thereafter, the caller ends the broadcast, and H.264 is transmitted from the caller's subscriber terminal device. 323Q. When the disconnection (DISC) message by the 931 call control message is transmitted to the multicast server (MS) via the gatekeeper (GK) (18-3), the multicast server (MS) terminates at the receiving subscriber terminal ( (Bye) A message is transmitted (18-4), and a release (REL) message transmitted to the calling subscriber terminal device is notified with the identification information of the broadcast receiving subscriber terminal device recognized by the multicast server (MS). (18-5) The sender (broadcaster) can recognize the subscriber who has received the broadcast based on the identification information (18-6).
[0099]
Next, an embodiment having a voice storage function will be described. FIG. 19 is an explanatory diagram of the first embodiment in which the multicast data (MS) includes voice data storage means. When the multicast server (MS) receives the unicast IP packet including the broadcast phone number and the broadcast audio, the multicast server (MS) refers to the broadcast phone number-multicast IP address correspondence table (TBL2) and corresponds to the received broadcast phone number. The broadcast audio IP packet is multicast-transmitted to the multicast IP address, and the broadcast telephone number and broadcast audio data are stored in the audio data storage unit 19-1.
[0100]
Thereafter, when the reproduction telephone number of the broadcast audio data is received from the gatekeeper (GK), the multicast server (MS) searches the broadcast audio accumulation data corresponding to the received reproduction telephone number by the accumulation data retrieval unit 19-2. If the stored data exists, the broadcast audio data is packet-transmitted to the caller who has requested reproduction. Therefore, a subscriber who wants to listen to the broadcast again or at a later time can arbitrarily listen to the recorded broadcast by performing the dialing operation of the reproduction telephone number from the analog telephone.
[0101]
FIG. 20 shows a sequence example of the above-described embodiment. FIG. 3 shows a broadcast recording / playback sequence when the H.323 protocol is used. From the calling subscriber terminal device to the multicast server (MS) A voice stream based on the 225.0 RTP protocol is transmitted, and the multicast server (MS) multicasts the voice stream and simultaneously stores the packet voice data in the voice data storage unit in the multicast server (MS) (20-1). .
[0102]
When the broadcast telephone number for recording and broadcasting is dialed from any subscriber terminal device after the broadcast ends (20-2), the multicast server (MS) receives the SETUP message including the telephone number for reproduction in the destination address information. Then, (20-3), the multicast server (MS) transmits the packet voice stored therein to the subscriber terminal apparatus as a voice stream by the H225.0 RTP protocol (20-4), and the subscriber terminal apparatus Receives the audio stream in the same manner as multicast reception, turns on the speaker and broadcasts the reproduced sound (20-5).
[0103]
FIG. 21 is an explanatory diagram of an embodiment in which sound is stored according to the broadcast type with or without recording. When the multicast server (MS) receives the unicast IP packet including the broadcast telephone number and the broadcast audio, the multicast server (MS) refers to the broadcast telephone number-multicast IP address correspondence table (TBL2) and broadcast type of the received broadcast telephone number. Includes a recording presence / absence discriminating unit 21-1 that determines whether “recording is present” or “no recording”.
[0104]
When the broadcast type is “no recording”, the broadcast audio IP packet is simply multicast-transmitted to the multicast IP address corresponding to the received broadcast telephone number, and recording (accumulation of audio data) is not performed. On the other hand, when the broadcast type is “with recording”, the broadcast audio IP packet is multicast transmitted, and the broadcast telephone number and the broadcast audio data are stored in the audio data storage unit 21-2.
[0105]
That is, the audio data storage unit 21-2 stores only the broadcast audio data corresponding to the broadcast number of the broadcast type analyzed as “recorded” by the broadcast telephone number-multicast IP address correspondence table (TBL2). Therefore, recording / non-recording of the broadcast content broadcast by the user can be selected according to the intention of the sender who requested the broadcast.
[0106]
When the multicast server (MS) receives the reproduction telephone number from the gatekeeper (GK), the accumulated data retrieval unit 21-3 retrieves the broadcast audio accumulated data corresponding to the received reproduction telephone number, and the accumulated data is If it exists, the broadcast audio data is packet-transmitted to the caller who has requested reproduction.
[0107]
FIG. 22 shows a sequence example of the embodiment shown in FIG. The figure shows H.C. It is an example of a recording designation sequence when the H.323 protocol is used. The caller dials the broadcast telephone number of the broadcast type “with recording” (22-1), and the destination address information including the broadcast type “with recording” is included in the SETUP message from the subscriber terminal device as the multicast server (MS (22-2).
[0108]
From the subscriber terminal device of the caller to the multicast server (MS) When an audio stream according to the 225.0 RTP protocol is transmitted, the multicast server (MS) that receives the broadcast type “with recording” simultaneously transmits the audio stream and transmits the audio data in the multicast server (MS). The packet voice data is stored in the storage unit (22-3).
[0109]
FIG. 23 is an explanatory diagram of an embodiment of an audio data storage / reproduction means for reproducing and broadcasting a predetermined number of times. When the multicast server (MS) receives the unicast IP packet including the broadcast phone number and the broadcast audio, the broadcast type of the received broadcast phone number is set to “broadcast phone number-multicast IP address correspondence table (TBL2)”. A means 23-1 is provided for determining whether “recording is present” or “no recording” and determining the number of times of reproduction broadcast specified by the additional number of the broadcast telephone number.
[0110]
When the broadcast type is “no recording”, the broadcast audio data IP packet is simply multicasted to the multicast IP address corresponding to the received broadcast telephone number, and the recording (sound data accumulation) is not performed. On the other hand, when the broadcast type is “with recording”, the broadcast audio data IP packet is multicast-transmitted, and the broadcast telephone number, the broadcast audio data, and the number of reproductions are stored in the audio data storage unit 23-2.
[0111]
The audio data storage unit 23-2 reads the stored broadcast telephone number and broadcast audio data for the number of times designated as the number of reproductions, and sends the IP packet of the broadcast audio data to the multicast IP address corresponding to the broadcast telephone number. Is sent by multicast.
[0112]
Therefore, after the broadcast by the voice of the broadcaster is finished, the broadcast audio data stored in the multicast server (MS) is repeatedly transmitted as many times as specified by the broadcast telephone number, and the number of times intended by the sender who requested the broadcast is transmitted. Broadcast can be repeated automatically.
[0113]
FIG. 24 shows a sequence example of the embodiment shown in FIG. The figure shows H.C. An example of a broadcast sequence by specifying the number of times of reproduction when the H.323 protocol is used is shown. The caller dials the broadcast telephone number of the broadcast type designating the number of playback broadcasts (24-1), and the multicast server (MS) receives the destination address information including the broadcast type in the SETUP message from the subscriber terminal device. (24-2).
[0114]
From the subscriber terminal device of the caller to the multicast server (MS) When an audio stream according to the 225.0 RTP protocol is transmitted and the audio stream is multicast from the multicast server (MS), the multicast server (MS) stores the packet audio of the audio stream in an internal audio data storage unit. (24-3).
[0115]
After the broadcast by the sender, the multicast server (MS) sends the packet voice stored in the voice data storage unit to the same multicast IP address in accordance with the designated broadcast type and broadcast count. 225.0 RTP protocol audio stream (2 4 -4).
[0116]
Next, an embodiment of erasing stored voice in each of the above-described voice storage means will be described. If the audio data stored in the audio data storage unit described above is not transmitted from the analog telephone within a certain time after the broadcast ends, and the stored data is not read out for a predetermined time or longer, the multicast server (MS) includes means for erasing the broadcast audio data from the audio data storage unit. By this means, it is possible to prevent a situation in which the memory area of the audio data storage unit is insufficient when a large number of broadcasts of the “with recording” broadcast type are requested.
[0117]
Next, an embodiment in which voice data is stored in a mailbox will be described. As shown in FIG. 25, when receiving a unicast IP packet including a broadcast telephone number and broadcast audio data, the multicast server (MS) refers to the broadcast telephone number-multicast IP address correspondence table (TBL2) and receives it. The broadcast voice IP packet is multicast-transmitted to the multicast IP address corresponding to the broadcast telephone number, and the broadcast telephone number and broadcast voice data are stored in the mail box 25-1.
[0118]
In the mailbox 25-1, the storage area is divided for each subscriber terminal device, and broadcast audio data is individually stored in the mailbox area portion of each subscriber terminal device. The voice data of the caller who requested the broadcast is stored only in the mailbox area of each of the subscriber terminals to be multicast, and when the reproduction telephone number from the receiving subscriber is received from the gatekeeper (GK), the multicast server (MS ) Is a subscriber who has searched for and read out the broadcast audio storage data corresponding to the received telephone number for playback from the mailbox area of the receiving subscriber by the stored data search unit 25-2 in the mailbox. (F) Packet transmission of the broadcast audio.
[0119]
Further, the multicast server (MS) monitors the voice data accumulation state (presence / absence of broadcast voice data) in each mailbox, and the voice data accumulation state in the mailbox is transmitted by the mailbox accumulation state notification unit 25-3. To each subscriber terminal device, and the subscriber terminal device visually or audibly displays the notified voice data storage state of its own mailbox. By this means, the subscriber can recognize the presence or absence of the recorded broadcast stored in his / her mailbox.
[0120]
A sequence example of the above-described embodiment is shown in FIGS. The figure shows H.C. An example of a broadcast recording / playback sequence in a mailbox format using the H.323 protocol is shown. The caller dials the broadcast telephone number of the broadcast type “with recording”, and the destination address information including the broadcast type is transmitted to the multicast server (MS) in the SETUP message from the subscriber terminal device (26-1). ).
[0121]
From the subscriber terminal device of the caller to the multicast server (MS) When an audio stream according to the 225.0 RTP protocol is transmitted and the broadcast type is “recorded”, the multicast server (MS) multicasts the audio stream, and at the same time, in a mailbox for each subscriber inside the multicast server (MS). Packet voice is stored (26-2).
[0122]
In FIG. 26, it is assumed that packet voice is stored in the mailbox with the subscriber number # 3. As shown in FIG. 27, the multicast server (MS) notifies the subscriber terminal device with the subscriber number whose data is stored in the mailbox, as shown in FIG. 27 (27-1), and the broadcast is recorded. To the broadcast recipient by visual or audible indication.
[0123]
When a reproduction telephone number is dialed from the broadcast recipient's telephone (27-2), the subscriber terminal device transmits a SETUP message including the reproduction number in the destination address information to the multicast server (MS), The multicast server (MS) sends the packet voice addressed to the subscriber stored in the mailbox format therein as a voice stream by the H225.0 RTP protocol to the subscriber terminal device (27-3). In the subscriber terminal device, the speaker is turned on as in the case of multicast reception, and the reproduced recording broadcast is emitted (27-4).
[0124]
Next, an embodiment in which voice data storage means is provided in a subscriber terminal device will be described. As shown in FIG. 28, the subscriber terminal device includes means 28-1 for determining whether or not the IP address of the received packet matches the IP address stored in the multicast IP address storage table (TBL3). When the discrimination means 28-1 detects a match, the audio data of the packet is reproduced by the speaker reproducing unit 28-2 and emitted from the speaker, and the broadcast telephone number and audio data included in the packet are The data is stored in the audio data storage unit 28-3.
[0125]
After that, when the reproduction telephone number of the stored broadcast audio data is received from the analog telephone connected to the subscriber terminal device, the stored data retrieval unit 28-4 causes the broadcast audio accumulation data corresponding to the reproduction telephone number to be received. If the corresponding broadcast audio storage data exists, the stored audio data is read out and reproduced by the speaker. Part It reproduces by 28-2 and emits sound from the speaker.
[0126]
In addition, the subscriber terminal device includes a broadcast recording state display unit 28-5, and the broadcast recording state display unit 2 8 -5 displays whether or not there is broadcast audio data stored in the audio data storage unit 28-3.
[0127]
With such a configuration, only by improving the own subscriber terminal device, the subscriber who receives the broadcast can recognize the presence or absence of the recorded broadcast, and dial the playback telephone number from the analog telephone to listen to the recorded broadcast at any time. Can do.
[0128]
FIG. 29 shows a sequence example of the embodiment shown in FIG. When the subscriber terminal device receives the packet voice from the multicast server (MS) by the H225.0 RTP protocol (29-1), the subscriber terminal device emits the voice from the speaker and also stores the packet voice in the voice data storage unit inside the subscriber terminal device. (29-2).
[0129]
After the end of the multicast, the subscriber terminal device turns off the speaker and informs the subscriber of the presence or absence of the recorded broadcast by visual or audible display (29-3). By the terminal operation such as the subscriber pressing the play button, the subscriber terminal device reads the stored voice packet data, turns on the speaker, and plays the recorded broadcast (29-4).
[0130]
Next, an embodiment for selecting a multicast to be received according to priority will be described. As shown in FIG. 30, the multicast IP address storage table (TBL3) in the subscriber terminal device stores each multicast IP address with a priority according to its priority.
[0131]
When a broadcast telephone number is dialed from a plurality of broadcast request senders and a packet of a multicast IP address corresponding to each broadcast telephone number is simultaneously delivered from the multicast server (MS) to the IP network, the subscriber terminal device Referring to the multicast IP address storage table (TBL3) with priorities shown in FIG. 30, one multicast to be emitted is selected from a plurality of multicasts according to the priorities.
[0132]
Then, the selected multicast is immediately emitted from the speaker, and for the multicast that has not been selected with a low priority, it is stored using the voice data storage means shown in FIG. 27 or FIG. By playing and emitting sound, it is possible to listen to broadcasts distributed simultaneously without omission.
[0133]
Next, an embodiment for preferentially broadcasting a starting broadcast when a plurality of broadcast requests are generated in duplicate will be described. FIG. 31 is an explanatory diagram of an embodiment for preferentially broadcasting a starting broadcast. FIG. 31 (a) shows subscriber numbers # 4 to # 6 when the broadcast telephone number #A for subscriber numbers # 1 to # 3 is multicast as a starting broadcast. The case where the broadcast of the broadcast telephone number #B targeted for the receiver is multicast as a subsequent broadcast is shown.
[0134]
As a first embodiment in this case, the multicast server (MS) performs broadcast control unconditionally prioritizing the first broadcast, and the broadcast telephone number received by the multicast server (MS) as destination address information of the SETUP message. When #A and broadcast phone number #B overlap, the multicast server (MS) gives priority to the previously received broadcast phone number #A and rejects the call for the SETUP message of broadcast phone number #B. Make a response.
[0135]
Accordingly, the multicast server (MS) transmits a multicast corresponding to the broadcast telephone number #A over the IP network (LAN), and only broadcasts the broadcast telephone number #A to the subscribers with the subscriber numbers # 1 to # 3. Is sent by multicast.
[0136]
Next, a second embodiment that preferentially broadcasts the starting broadcast will be described. FIG. 31 (b) shows subscriber numbers # 3 to # 5 when the broadcast telephone number #A for subscribers # 1 to # 3 is multicast as a starting broadcast. The case where the broadcast of the broadcast telephone number #B targeted for the receiver is multicast as a subsequent broadcast is shown.
[0137]
When the multicast server (MS) receives the broadcast phone number #A and the broadcast phone number #B as the destination address information of the SETUP message, the multicast server (MS) receives the subscribers of the respective broadcast phone numbers. The terminal device is checked, and priority control is performed only when the subscriber terminal device is duplicated.
[0138]
Therefore, as shown in FIG. 31B, the multicast server (MS) broadcasts first when the subscriber number # 3 is the reception target of both the broadcast telephone numbers #A and #B. Priority is given to the broadcast telephone number #A, and the call is rejected for the SETUP message of the subsequent broadcast telephone number #B. The multicast server (MS) transmits the multicast corresponding to the broadcast telephone number #A to the IP network (LAN). Send on.
[0139]
However, as shown in FIG. 31 (a), when there is no receiving subscriber overlapping with the broadcast telephone number #A and the broadcast telephone number #B, the broadcast telephone number #A and the broadcast telephone number #A Both broadcasts of telephone number #B are multicast simultaneously.
[0140]
FIG. 32 shows the flow of the priority broadcast priority control when the reception target subscribers overlap. When the multicast server (MS) receives the broadcast telephone number (32-1), it checks whether multicast transmission is already in progress at that time (32-2). Whether or not there is an overlapping subscriber terminal device between the receiving subscriber terminal device and the subsequent broadcast receiving subscriber terminal device to be transmitted from now on (32-3), and the overlapping subscriber terminal device If there is a broadcast, the first broadcast is prioritized, and the broadcast request from the subscriber of the subsequent broadcast is canceled and the broadcast request is discarded (32-4).
[0141]
When there is no multicast transmission of the starting broadcast, or when there is no overlapping subscriber terminal device between the receiving subscriber terminal apparatus of the starting broadcast and the receiving subscriber terminal apparatus of the subsequent broadcasting, the multicast server (MS) As described above, the broadcast telephone number-multicast IP address correspondence table (TBL2) is referred to (32-5), and multicast transmission is executed (32-6).
[0142]
With such a configuration, when a broadcasting telephone number is dialed from a plurality of subscribers at the same time, it is possible to protect the interruption of the starting broadcast by giving priority to the starting broadcasting that is already being broadcast. it can.
[0143]
Next, an embodiment for broadcasting a subsequent broadcast will be described. FIG. 33A is an explanatory diagram of an embodiment for preferentially broadcasting a subsequent broadcast. As shown in the figure, when the subscriber number # 3 is the reception target of the advance broadcast telephone number #A and the subsequent broadcast telephone number #B, the broadcast of the advance broadcast telephone number #A is interrupted and the subsequent broadcast telephone number #A is interrupted. Broadcast with priority given to the broadcast telephone number #B.
[0144]
FIG. 34 shows a control flow in the multicast server (MS) prioritizing the subsequent broadcast. When receiving the broadcast telephone number (34-1), the multicast server (MS) checks the multicast transmission state being executed at that time (34-2). If multicast transmission is being executed, transmission is being executed. It is checked whether or not there is an overlapping subscriber terminal device between the receiving subscriber terminal device of the first broadcasting and the receiving subscriber terminal device of the subsequent broadcasting to be transmitted (34-3).
[0145]
If there are overlapping subscriber terminal devices, the broadcast telephone number-multicast IP address correspondence table (TBL2) is referred to (34-4), the first multicast is interrupted (34-5), and the second multicast is performed. Execute with priority on transmission (3 4 -6).
[0146]
When there is no multicast transmission of the starter broadcast or when there is no overlapping subscriber terminal device between the starter broadcast and the subsequent broadcast, the multicast server (MS) is set to the broadcast telephone number-multicast IP address correspondence table (TBL2). (3) 4 -7), execute multicast transmission (3 4 -8).
[0147]
With such a configuration, when a broadcast telephone number is dialed from a plurality of subscribers at the same time, it is possible to interrupt the first broadcast and give priority to the subsequent broadcast. In particular, when the broadcast type of the subsequent broadcast is a broadcast with a high degree of urgency, priority can be given to the subsequent broadcast so that a highly urgent notification content can be immediately broadcast to the receiving subscriber.
[0148]
FIG. 33B is an explanatory diagram of an embodiment in which a subsequent broadcast is recorded and the recorded data is reproduced and broadcast later. As shown in the figure, when the subscriber number # 3 is the reception target of the advance broadcast phone number #A and the subsequent broadcast phone number #B, the broadcast of the advance broadcast phone number #A is continued, Record the broadcast of broadcast telephone number #B. Then, after the broadcast of the preceding broadcast telephone number #A is finished, the recording of the subsequent broadcast telephone number #B is reproduced and broadcast.
[0149]
FIG. 35 shows a control flow in the multicast server (MS) of the embodiment shown in FIG. When receiving the broadcast telephone number (35-1), the multicast server (MS) checks the multicast transmission status being executed at that time (35-2). It is checked whether there is an overlapping subscriber terminal device between the broadcast receiving subscriber terminal device and the subsequent broadcast receiving subscriber terminal device to be transmitted (35-3).
[0150]
If there are overlapping subscriber terminal devices, the first broadcast is continuously transmitted by multicast, and the next broadcast request is made with reference to the broadcast telephone number-multicast IP address correspondence table (TBL2) (35-4). The person's voice is stored in the voice data storage means (35-5).
[0151]
Thereafter, it is checked whether or not the previous broadcast is still being transmitted by multicast (35-6). If multicast transmission is being performed, the predetermined timing is measured (35-7), and then the previous broadcast is being transmitted by multicast again. Is checked (35-6).
[0152]
When the end of the multicast transmission of the starting broadcast is detected, the audio data of the subsequent broadcaster stored in the multicast server (MS) is multicast transmitted (35-8). When there is no multicast transmission of the starting broadcast, or when there is no overlapping subscriber terminal device between the receiving subscriber terminal device of the starting broadcast and the receiving subscriber terminal device of the subsequent broadcasting, the multicast server (MS) Then, the broadcast telephone number-multicast IP address correspondence table (TBL2) is referred to (35-9), and multicast transmission is executed (35-10).
[0153]
With such a configuration, when a broadcast telephone number is dialed from a plurality of subscribers at the same time, the starter broadcast is not interrupted and the subsequent broadcast is not rejected. The person can be notified.
[0154]
【The invention's effect】
As described above, according to the present invention, a multicast server that executes multicast transmission by receiving a broadcast telephone number is installed on a general-purpose IP network, and packet audio transmitted from a broadcaster is multicast from the multicast server. By constructing a broadcast system that can distribute broadcast audio over a general-purpose IP network by transmitting, and that is easy to expand the system and can coexist with other IP communication services. Can do.
[0155]
In addition, by providing a common multicast server in the broadcast service on the IP network, each subscriber terminal device does not need to have a special multicast transmission function, and multicast transmitted on the IP network by one multicast server. Centralized management of broadcasting such as number and traffic control (priority control), recording, and reception confirmation can be performed.
[0156]
Further, according to the present invention, in the multicast server (MS), it is possible to perform safe operation management by providing means for checking the broadcast qualification of the caller from the caller address information. In addition, by providing the multicast server with a table storing multicast IP addresses corresponding to a plurality of broadcast telephone numbers, it is possible to broadcast a plurality of broadcast types.
[0157]
In addition, a storage table of received multicast IP addresses provided in each subscriber terminal device is created by the multicast server, and the table is transmitted from the multicast server to each subscriber terminal device, so that all subscribers can be remotely operated from the multicast server. The table of the user terminal device can be updated.
[0158]
In addition, by transmitting multicast address information of the broadcaster from the multicast server to the reception target subscriber terminal device, the reception target subscriber can recognize who the broadcaster is. Further, by receiving the reception status information from the reception target subscriber via the multicast server to the caller's subscriber terminal device, it is possible to easily confirm the reception using the general-purpose protocol of the IP network.
[0159]
In addition, by providing recording means in the multicast server, the receiving target subscriber can listen to repeated or later broadcast audio. In addition, a broadcast phone number is provided that indicates the type of broadcast with or without recording, and only when necessary broadcasts are recorded by recording broadcast audio only when a broadcast phone number with a recorded broadcast type is sent. Can be accumulated.
[0160]
Also, when multiple broadcasts are requested at the same time by the multicast server, the multicast server selects the multicast to be transmitted according to the priority and limits the number of transmissions, thereby adjusting the traffic load of the IP network by multicast at the multicast server Can do.
[0161]
In addition, when there are subscribers to be received that are duplicated in the multicast transmission broadcast simultaneously, the multicast server selects one broadcast according to the priority and does not send a wasteful multicast that the subscriber cannot listen to to the IP network. The traffic load on the IP network can be reduced.
[0162]
In addition, if there are subscribers that are duplicated in the multicast transmission that is broadcast at the same time, the subsequent broadcast is stored using the recording function, and after the previous broadcast ends, the subsequent broadcast is reproduced and broadcast, By sending out one broadcast at a time on the network, broadcast overlapping subscribers can listen to both the first and second broadcasts, and the traffic load on the LAN can be reduced.
[Brief description of the drawings]
FIG. 1 is a configuration diagram of a multicast broadcasting system according to the present invention.
FIG. 2 is a diagram illustrating an operation sequence of a main part of a multicast broadcasting system according to the present invention.
FIG. 3 is a diagram showing an example of a message sequence for executing broadcasting by multicast according to the present invention.
FIG. 4 is an explanatory diagram of a multicast server (MS) including a broadcast permission / prohibition subscriber number table.
FIG. 5 is a diagram illustrating an example of a multicast sequence for determining broadcast qualification.
FIG. 6 is a diagram showing an example of a multicast sequence for determining broadcast qualification.
FIG. 7 is an explanatory diagram of a table for assigning broadcast types for each broadcast telephone number.
FIG. 8 is a diagram showing an example of a multicast sequence in which a plurality of broadcast telephone numbers are assigned.
FIG. 9 is an explanatory diagram of a broadcast telephone number-multicast IP address correspondence table;
FIG. 10 is an explanatory diagram of a broadcast telephone number-multicast IP address correspondence table.
FIG. 11 is a diagram illustrating a sequence example for updating a table of a subscriber terminal device.
FIG. 12 is a diagram illustrating an example of a sequence for updating a table of a subscriber terminal device.
FIG. 13 is an explanatory diagram of multicast reception processing during broadcasting in a subscriber terminal device.
FIG. 14 is a diagram illustrating a sequence example of canceling a multicast reception process in a calling subscriber terminal device.
FIG. 15 is a diagram illustrating an example of a broadcaster identification information notification sequence.
FIG. 16 is a diagram illustrating a sequence example for notifying that multicast reception is in progress;
FIG. 17 is a diagram illustrating a sequence example for notifying that multicast reception is in progress;
FIG. 18 is a diagram illustrating a sequence example for notifying identification information of a broadcast receiving subscriber device.
FIG. 19 is an explanatory diagram of voice storage means provided in a multicast server (MS).
FIG. 20 is a diagram showing a broadcast recording / playback sequence by the audio data storage means.
FIG. 21 is an explanatory diagram of sound storage means according to the broadcast type with or without recording.
FIG. 22 is a diagram illustrating a sequence example of sound accumulation according to a broadcast type with or without recording.
FIG. 23 is an explanatory diagram of a sound storage / playback unit that plays and broadcasts a specified number of times.
FIG. 24 is a diagram showing an example of a sequence of audio accumulation / reproduction for a specified number of times of reproduction broadcast.
FIG. 25 is an explanatory diagram of voice storage means for storing voice data in a mailbox.
FIG. 26 is a diagram showing an example of an audio accumulation sequence for accumulating audio data in a mailbox.
FIG. 27 is a diagram showing a sequence example for reproducing audio data stored in a mailbox.
FIG. 28 is an explanatory diagram of voice storage means provided in a subscriber terminal device.
FIG. 29 is a diagram showing an example of a voice accumulation sequence of a subscriber terminal device.
FIG. 30 is an explanatory diagram of a multicast IP address storage table (TBL3) with priorities assigned thereto;
FIG. 31 is an explanatory diagram of an embodiment for preferentially broadcasting a starting broadcast.
FIG. 32 is a flow diagram of advanced broadcast priority control when reception target subscribers overlap.
FIG. 33 is an explanatory diagram of an embodiment for broadcasting a subsequent broadcast.
FIG. 34 is a flowchart of subsequent broadcast priority control when the reception target subscribers overlap.
FIG. 35 is a flowchart showing recording and reproduction of a subsequent broadcast when receiving subscribers overlap.
[Explanation of symbols]
1-10 Subscriber terminal device
1-11 Analog telephone
1-12 Broadcast speakers
1-20 Gatekeeper GK
1-30 Multicast server MS
1-40 IP network (LAN)

Claims

In a subscriber terminal connected to an IP network,
Means for determining reception of a voice packet having a multicast IP address corresponding to a broadcast telephone number and having a multicast IP address stored in advance in its own device, out of received packets having a multicast IP address;
Means for turning on a speaker when receiving a voice packet having the multicast IP address and emitting the voice of the received voice packet from the speaker;
A subscriber terminal device comprising:

2. The subscriber terminal apparatus according to claim 1, further comprising voice data storage means for storing a broadcast telephone number and voice data included in the voice packet to be emitted.

3. The subscription according to claim 2, wherein when a reproduction telephone number of the stored broadcast audio data is received from a connected analog telephone, the corresponding broadcast audio storage data is read out and reproduced and emitted from a speaker. Terminal device.

After receiving the audio packet having the multicast IP address, the speaker is turned off, and the presence / absence of the recorded broadcast is displayed visually or audibly depending on whether or not the audio data of the audio packet is stored in the audio data storage unit. subscriber terminal device according to claim 2, further comprising a means.

It provided a multicast IP address storage table prioritized to the plurality of multicast IP addresses, from among a plurality of multicast IP addresses for receiving, means for selecting a multicast voice packets sound in accordance with the priority The subscriber terminal device according to claim 1, further comprising:

According to claim 5, priority is characterized by comprising a voice data storage means for storing a multicast voice packets that were not chosen to be lower, and means for sound by reproducing stored the voice packet has been the Subscriber terminal equipment.

During reception of the voice packet with a multicast IP address, the multicast server which is the source of the voice packet, the subscriber terminal device according to claim 1, characterized in that to send a message back indicating that it is being received .

2. The subscriber terminal apparatus according to claim 1, further comprising means for returning a message indicating that the multicast packet is being received when the inquiry packet in the multicast packet reception state is received from the multicast server.

2. A multicast IP address storage table for storing the multicast IP address is provided, and the table is updated by a multicast IP address storage table sent from the multicast server to the IP address of the own apparatus. The subscriber terminal device according to 1.

Receive processing of voice packet having multicast IP address corresponding to broadcast telephone number distributed from IP network when broadcast telephone number is dialed out from telephone connected to own device and transmission is in progress 2. The subscriber terminal apparatus according to claim 1, further comprising means for canceling.

Before receiving the voice packet having the multicast IP address, receiving broadcast identification information of the caller, the subscriber according to claim 1, characterized in that a means for displaying the broadcast identification information Terminal device.

A multicast broadcast method for delivering voice packets to subscriber terminals connected to an IP network,
Transmitting a voice packet from a multicast server to a multicast IP address corresponding to a broadcast telephone number;
A step of determining reception of a voice packet having a multicast IP address corresponding to a broadcast telephone number stored in advance in the own device out of reception packets having a multicast IP address in the subscriber terminal device;
When it is determined to receive the voice packet having the multicast IP address, the steps of: turning on the speaker and sound is output from the speaker of the voice packets received,
A broadcast method using multicast, comprising :