まず、本発明の実施形態の概略を説明する。本発明の実施形態は、携帯電話端末を、トランシーバや無線機のように利用することを特徴としたコミュニケーション手段であるPoC(Push-to-Talk over Cellular)等の技術分野に好適な実施形態である。
具体的には、プッシュ・ツー・トーク通信を、従来型のプッシュ・ツー・トーク通信と同程度の大規模かつ広域での利用を可能としつつ、携帯電話端末及び携帯電話事業者網を用いてより低コストで提供可能なPoCグループ一斉音声通信を実現することを目的とする。
そのために、本実施形態における配信装置が、任意の送信元端末からのRTPパケットを、予め設定した端末のグループ情報及び端末の死活情報に従って、それぞれの送信先端末に向けた複数パケットに複製して配信する。
更に、本実施形態における配信装置が、RTPパケットを複製する際に、IPヘッダの送信元IPアドレス情報を、配信装置のIPアドレスに変換して配信するようにしても良い。
更に、送信元端末は、RTPパケットの送信元IDであるSSRC(Synchrozination Source)フィールドに送信元端末IDを付加して配信装置に通知するようにしても良い。
あるいは、送信元端末は、RTPパケットのRTP拡張ヘッダに、グループID・端末ID・特権者情報などの情報を付加して通知するようにしても良い。そして、本実施形態における配信装置は、これらの通知に基づいて送信先端末所属グループやその他の情報を認識して配信制御をするようにしても良い。
以上が本発明の概略である。
次に、本発明の実施の形態について図面を参照して詳細に説明する。
[構成の説明]
まず、本発明の実施形態である、配信システムS100の基本的構成について図1を参照して説明する。
図1を参照すると、配信システムS100は、配信装置E1、第1の端末T1乃至第nの端末Tn、ローカルエリアネットワークN1、専用線網N2及び事業者携帯電話用パケット通信網N3を含む。
ここで、配信装置E1は、PoCグループ一斉音声通信を実現するための装置である。
配信装置E1は、例えば本実施形態特有のプログラムを組み込んだサーバ装置により実現される。
また、第1の端末T1乃至第nの端末Tnは、ユーザが利用する通信端末である。第1の端末T1乃至第nの端末Tnは、例えば、携帯電話機により実現される。
また、ローカルエリアネットワークN1は、例えば配信装置E1を利用するユーザが使用するネットワークである。配信装置E1は、ローカルエリアネットワークN1に接続されている。
また、事業者携帯電話用パケット通信網N3は、例えば携帯電話機のキャリアが提供する通信網である。また、配信装置E1と事業者携帯電話用パケット通信網N3は、配信装置E1を利用するユーザ用に設けられた専用線網N2を介してネットワーク接続される。
そして、このネットワーク接続を利用して配信装置E1と、第1の端末T1乃至第nの端末Tnとは通信を行なう。
また、本実施形態では、第1の端末T1乃至第nの端末Tnは、それぞれが何れかのグループに所属しているものとする。ここでいう「グループ」とは、トランシーバの周波数や、無線機のチャネルに相当するものであり、通話先とする端末群を選択するために使用する。
グループの設定方法には種々の方法が考えられる。例えば、何れのグループに、何れの端末が所属しているのかを表す情報を予め配信装置E1に記憶させることにより、グループの設定を行なうようにしても良い。
また、そうではなく、ユーザの操作を端末で受け付けるようにし、この操作に応じてグループの設定を行なうようにしても良い。つまり、通話する端末群をユーザに選択させることにより、動的にグループの設定を行なうようにしても良い。
更に、これらを組み合わせて、予め配信装置E1に設定した範囲で、通話する端末群をユーザに動的に選択させるようにしても良い。例えば、予め或るユーザの端末を第1のグループと第2のグループに設定しておく。そして、この或るユーザに、通話対象とするグループを、第1のグループと第2のグループの何れかから選択させるようにしてもよい。
またそうではなく、例えば第1の端末T1、第2の端末T2、第3の端末T3及び第4の端末T4が或る1つのグループに所属するとして予め配信装置E1に設定しておく。そして、通信時に、発信元となる端末(例えば、第1の端末T1)のユーザにこの4台の端末の中の残りの3台(例えば、第2の端末T2、第3の端末T3及び第4の端末T4)から通話する端末群を選択させるようにしても良い。
また、以下の説明では、第1の端末T1、第3の端末T3及び第nの端末Tn等はグループG1に所属しており、第2の端末T2等はグループG2に所属しているものとする。
なお、上記の文章にて「・・・第nの端末Tn等」、とのように「等」との文言を付加している理由であるが、グループG1やグループG2に、図示を省略している他の端末が含まれても良いことを想定しているからである。
次に、図2を参照して、特に配信装置E1に含まれる機能ブロックについて説明する。
また、各機能ブロックによる処理又はデータの流れや、RTPパケットの流れについても説明する。なお、図3にも凡例として記載しているが、図3における実線による矢印は、各機能ブロックによる処理又はデータの流れを表している。また、図3における破線による矢印は、RTPパケットの流れを表している。また、機能ブロックの説明とは深く関係しない、ローカルエリアネットワークN1、専用線網N2及び事業者携帯電話用パケット通信網N3については図2での図示を省略する。
図2を参照すると配信システムS100は、配信装置E1、送信元端末S1、及び第1の送信先端末R1乃至第Nの送信先端末Rnを含む。
ここで、送信元端末S1と、第1の送信先端末R1乃至第Nの送信先端末Rnは、それぞれが図1に表される第1の端末T1乃至第nの端末Tnの何れかに相当するものである。また、各端末は、送信先及び送信元の役割が固定されているものではない。つまり、送信元端末S1は、第1の送信先端末R1乃至第Nの送信先端末Rnになり得る。同様に、第1の送信先端末R1乃至第Nの送信先端末Rnは送信元端末S1になり得る。なお、以下の説明において、第1の送信先端末R1乃至第Nの送信先端末Rnの何れかの端末を特定することなく指す場合には、単に「端末R」と記載する。
また、配信装置E1は、RTPパケット受信部M1、受信RTPパケット記憶部M2、送信元端末ID制御部M3、送信権取得制御部M4、RTPパケット複製部M5、送信RTPパケット記憶部M6、RTPパケット送信部M7、IPヘッダ制御部M8−1、UDPヘッダ制御部M8−2、RTPヘッダ制御部M8−3、RTP拡張ヘッダ制御部M8−4及びグループ所属端末群情報記憶部D1を含む。
RTPパケット受信部M1は、送信元端末S1が送信したRTPパケットを受信する。
受信RTPパケット記憶部M2は、RTPパケット受信部M1が受信したRTPパケットを一時的に記憶する。
送信元端末ID制御部M3は、RTPパケットに含まれるSSRC(送信元ID)フィールドから送信元端末IDを抽出して、抽出した送信元端末IDを送信権取得制御部M4やRTPパケット複製部M5に出力する。
送信権取得制御部M4は、送信元端末S1に送信権を与えるか否かを決定する。
RTPパケット複製部M5は、RTPパケットの複製を作成する。
送信RTPパケット記憶部M6は、RTPパケット複製部M5が作成したRTPパケットの複製を一時的に記憶する。
RTPパケット送信部M7は、送信RTPパケット記憶部M6が記憶しているRTPパケットの複製を、第1の送信先端末R1乃至第Nの送信先端末Rnの内の、送信先となる端末に対して送信する。
IPヘッダ制御部M8−1は、RTPパケット複製部M5が作成するRTPパケットの複製のIPヘッダに所定の情報を書き込む。また、UDPヘッダ制御部M8−2は、RTPパケット複製部M5が作成するRTPパケットの複製のUDPヘッダに所定の情報を書き込む。更に、RTPヘッダ制御部M8−3は、RTPパケット複製部M5が作成するRTPパケットの複製のRTPヘッダに所定の情報を書き込む。更に、RTP拡張ヘッダ制御部M8−4は、RTPパケット複製部M5が作成するRTPパケットの複製のRTP拡張ヘッダに所定の情報を書き込む。
グループ所属端末群情報記憶部D1は、各グループに所属する各端末の端末ID等が含まれた情報であるグループ所属端末群情報を記憶する。そして、送信権取得制御部M4や、RTPパケット複製部M5は、このグループ所属端末群情報を参照して処理を行なう。
ここで、グループ所属端末群情報記憶部D1が記憶するグループ所属端末群情報のより具体的な例について図3を参照して説明する。図3は、グループ所属端末群情報の一例を表す図である。
図3に表されるように、グループ所属端末群情報は、グループ所属端末群情報データベーステーブル及び端末情報テーブルの2つのテーブルを含む。
ここで、グループ所属端末群情報データベーステーブルは、グループIDをキーに検索されるテーブルである。グループ所属端末群情報データベーステーブルには、それぞれのグループIDに対応したそれぞれのグループに所属している所属端末を識別するための端末IDが格納されている。何れかのグループIDをキーとして検索することにより、このグループIDに対応するグループに所属している端末の端末IDを抽出することができる。また、各グループに所属している何れの端末が現在送信権を取得しているのかも抽出することができる。なお、送信権とは、RTPパケットの送信元となる権利である。送信権を取得している端末が、1対多の通信における、1となる。
ここで、送信元端末が所属しているグループに送信権を得ている端末が有るか否かを検索する方法について説明する。
例えば、送信元端末IDを検索キーとして端末情報テーブルを検索することにより、送信元端末S1が所属するグループのグループIDを取得する。そして、取得したグループIDで一意に識別されるグループ内に、送信権を取得している端末が有るか否かを確認する。このために、送信権の取得又は現在送信権を得ている端末が有るか否か、有るとすればどの端末であるか、という情報を、送信権の取得及び開放が行われるたびに、グループIDと紐付けて図3のように記憶しておく。
また、図3のようにグループIDと現在送信権を得ている端末を紐付けて記憶しておくのではなくて、送信権の取得及び開放が行われるたびに、現在送信権を得ている端末であるか否かを表す情報を各端末IDに紐づけておくようにしても良い。この場合には、送信元端末S1が所属するグループのグループIDを検索キーとして所属端末群情報データベーステーブルを検索することにより、送信元端末S1が所属するグループに所属している端末の端末IDを全て抽出する。そして、抽出した端末IDのそれぞれに紐付いている現在送信権を得ている端末であるか否かを表す情報を参照することにより、現在送信権を得ている端末が有るか否かを判定する。こうすることによっても、送信元端末S1が所属している所属グループで送信権を取得している端末が有るか否かを確認することができる。
なお、本実施形態では、音声通信を行なうことを想定していることから、送信権ではなく、送話権と表現しても良いが、本実施形態の適用範囲は必ずしも音声通信に限定されないことから、本明細書では、送信権との表現を用いる。また、本実施形態において、1つのグループに含まれる端末の台数に特に制限はない。
他方、端末情報テーブルは、端末IDをキーに検索されるテーブルである。端末情報テーブルには、それぞれの端末IDにより識別される各端末に関しての情報が格納されている。具体的には、端末のIPアドレス、特権者情報、選択可能グループ情報、選択グループ情報、死活状態が格納されている。
端末のIPアドレスは、各端末に割り当てられているIPアドレスである。
また、特権者情報とは、各端末が特権者として設定されているか否かを表す情報である。端末が特権者として設定されている場合には、値をTrueとし、端末が特権者として設定されていない場合には、値をfalseとする。特権者が具体的にどのようなものであるのかは、第1の変形例の説明として後述する。
選択可能グループ情報とは、各端末が、RTPパケットの送信先のグループとして選択できるグループが、どのグループであるかを表す情報である。選択可能グループ情報は、例えばビットマップインデックスにより管理されるようにすると良い。具体的には、配信システム100に含まれる全てのグループ毎に行を設け、各端末がそのグループを選択できるのであれば、値を「1」とし、各端末がそのグループを選択できるのであれば、値を「0」とするように管理する。送信権取得制御部M4や、RTPパケット複製部M5は、このビットマップインデックスを使用して検索することにより、各端末が選択できるグループであるか否かを判断することができる。
選択グループ情報は、各端末を使用するユーザが、選択したグループである。ここで、選択可能グループが1つしかない端末があったとすれば、その端末は、ユーザによる選択をされるまでもなく、その1つの選択可能グループが、そのまま選択グループとなる。一方で、選択可能グループが複数ある端末であれば、その端末のユーザは、この複数のグループのなかから送信先とするグループを選択する。つまり、この選択されたグループが選択グループとなる。そして、選択グループに含まれる各端末がRTPパケットの送信先となる。
死活状態は、現在その端末が通信可能な状態にあるか否かを表す情報である。端末が通信可能な状態であれば、値をActiveとする。一方で、端末が無線通信可能な範囲の圏外に在圏していたり、端末がバッテリ切れをおこしていたりするような状態であって、端末が通信できない状態であれば値をnonとする。
これらの情報の内、端末ID、IPアドレス、特権者情報及び選択可能グループ情報は、例えば予め配信装置E1を管理する保守者が入力しておくことで静的に設定される。
また、これらの情報の内、選択グループ情報は、例えば端末のグループ選択操作で動的に設定されるものとする。
更に、これらの情報の内、死活状態は、例えば端末と配信装置又は端末とは別途用意する死活監視サーバが各端末の死活監視を行い、この死活監視の結果を配信装置E1との間でやり取りすることで動的に設定されることとする。
また、これらの情報を他の情報で置き換えたり、これらの情報以外の他の情報を追加したりするようにしても良い。
例えば、ユーザが端末使用時に端末を認証するときに、ユーザにユーザIDを入力させるようにする。そして、特権者情報をユーザIDに関連付けた情報とするようにしても良い。つまり、端末ID毎に特権者情報を紐付けるのではなく、ユーザID毎に特権者情報を紐付けるようにしても良い。これにより、同じ端末であっても、使用するユーザにより、特権者情報の有無を異ならせることができる。
他にも、例えば盗難・亡失対策用に、盗難された端末又は亡失した端末を使用不可とするための盗難・亡失情報を設けてもよい。そして、盗難・亡失情報がfalseであれば、端末を通常通りに使用可能とする。一方で、ユーザから端末の盗難又は亡失の届けを受けた配信装置E1の保守者が、盗難された又は亡失した端末の盗難・亡失情報をtrueと設定した場合には、この盗難された又は亡失した端末を使用不可とするようにしても良い。
次に、送信元端末S1から送信されるRTPパケットや、RTPパケット複製部M5が複製することにより作成するRTPパケットのフォーマットについて図4−1及び図4−2を参照して説明する。かかるフォーマットは基本的にRTPに準拠するものである。
しかしながら、「信号送信時の設定内容」に〈書き換え〉と記載されている項目については、RTPパケット複製部M5がRTPパケットを複製する際に書き換えられる。具体的な、書き換え内容については後述する。
また、「信号送信時の設定内容」に[受信したパケットのまま]と記載されている項目については、RTPパケット複製部M5がRTPパケットを複製する際に書き換えられることはなく、送信元端末S1から受信したRTPパケットの値のまま複製される。
更に、「信号送信時の設定内容」に[受信したパケットのまま]及び〈本実施形態特有の情報〉と記載されている項目については、送信元端末S1から受信したRTPパケットの値のまま複製され、且つ、本実施形態特有の方法で利用される。本実施形態特有の方法で利用としては、例えば、送信元端末S1は、RTPパケットのSSRC(送信元ID)フィールドに、送信元端末S1を一意に識別するためのIDを格納して送信する、といった利用方法である。
更に、RTP拡張ヘッダを利用することも考えられる。そのため、図5では、RTP拡張ヘッダも使用する場合の例を記載している。具体的には、RTP拡張ヘッダの〈本実施形態特有の情報(例)〉と記載されている項目である。また、図2においてもRTP拡張ヘッダ制御部M8−4を記載している。
しかしながら、RTP拡張ヘッダを使用することは必須ではない。そこで、本実施形態の説明では、RTP拡張ヘッダは使用しないケースについて説明する。そして、RTP拡張ヘッダを使用するケースについては、本実施形態の変形例として後述する。なお、RTP拡張ヘッダは使用しないケースの場合には、RTP拡張ヘッダ制御部M8−4を省略することができる。
[動作の説明]
次に、図5のフローチャート等を参照して、本実施形態における配信装置E1の配信時の動作について詳細に説明する。なお、図5は配信装置E1の基本的動作を表すフローチャートである。
まず、送信元端末S1が、ユーザからのプッシュオン操作を受け付ける。プッシュオン操作を受け付けた送信元端末S1は、配信装置E1に対して、RTPパケットを送信する。そして、配信装置E1は、送信元端末S1が送信したRTPパケットをRTPパケット受信部M1によって受信する(ステップS11)。
なお、本明細書では、送話を開始するために、送信権取得要求するため操作を上記のように「プッシュオン操作」と表現する。また、これとは逆に送話を終了するために送信権開放要求するための操作を「プッシュオフ操作」と表現する。これは、「押して話す」という本来の「プッシュ・ツー・トーク」の語源に合わせた表現である。
実際の操作の受け付け方としては、例えば送信元端末S1に接続する外部の送話ボタンを設け、外部の送話ボタンを押した時点で送信権取得要求を意味し(つまり、プッシュオン操作が行われたと判断し)、押したままの間は送話中とし、放した時点で送信権開放要求を意味する(つまり、プッシュオフ操作が行われたと判断する)、というように語源通りにしてもよい。
しかしながら、必ずしも語源通りにする必要はなく、送話中に「押したままとする」という操作を要さないようにしても良い。例えば、端末上のディスプレイ上に表示した「送信権未取得状態」というアイコンに触れたら送信権取得要求を意味し(つまり、プッシュオン操作が行われたと判断し)、その後、何れのアイコンも触れられないのならば、送話中とし、端末上のディスプレイ上に表示した「送信権取得状態」というアイコンに触れたら送信権開放要求を意味する(つまり、プッシュオフ操作が行われたと判断する)、というようにしても良い。
次に、配信装置E1の受信RTPパケット記憶部M2が、RTPパケット受信部M1が受信したRTPパケットを記憶する(ステップS12)。
ここで、RTPパケット受信部M1が受信したRTPパケットが配信中の(すなわち、現在送話中の)送信元端末が送信したRTPパケットであるか否かを判定する(ステップS13)。例えば、RTPパケット受信部M1が送信権取得制御部M4から、現在送信権を得ている端末のIPアドレスを取得しておく。そして、RTPパケット受信部M1が受信したRTPパケットの送信元IPアドレスが、現在送話権を得て、配信中の(すなわち、現在送話中の)送信元端末のIPアドレスと同一であるか否かに基づいて判定をする。
RTPパケット受信部M1が受信したRTPパケットが、配信中の送信元端末が送信したものであれば(ステップS13においてYes)ステップS18の処理を行なうために、RTPパケットをRTPパケット複製部M5に渡す。なお、一般的な技術であることから詳細な説明は省略するが、ジッタバッファの制御等の、パケット通信における一般的な処理も受信RTPパケット記憶部M2で行う。
一方で、RTPパケット受信部M1が受信したRTPパケットが、配信中の送信元端末が送信したものでなく、他の端末が送信したものであれば(ステップS13においてNo)送信元端末ID制御部M3に処理を渡し、ステップS14に進む。
ステップS14において、送信元端末ID制御部M3は、RTPパケットのSSRC(送信元ID)フィールドから送信元端末IDを抽出する。そして、送信元端末ID制御部M3は、この抽出した送信元端末IDを送信権取得制御部M4に出力し、送信権取得制御部M4に処理を渡し、ステップS15に進む。
ステップS15において、送信権取得制御部M4は、送信元端末ID制御部M3から受信した送信元端末IDを検索キーとしてグループ所属端末群情報記憶部D1に記憶された端末情報テーブルを検索する。そして、端末情報テーブル内送信元端末S1の選択グループを参照することにより、送信元端末S1が所属している所属グループのグループIDを求める。
更に、送信権取得制御部M4は、このグループIDを検索キーとしてグループ所属端末群情報記憶部D1に記憶されたグループ所属端末群情報データベーステーブルを検索する。そして、送信元端末S1が所属している所属グループで送信権を取得している端末が有るか否かを確認する(ステップS15)。
ステップS15における確認の結果、送信元端末S1が所属するグループに送信権を取得している端末がなければ(ステップS15においてNo)、送信元端末S1に送信権を与える。そして、送信元端末S1に送信権を与えた場合は、RTPパケットをRTPパケット複製部M5に渡す(ステップS16)。また、グループ所属端末群情報データベーステーブルの送信権取得端末の項目を更新する。この場合に、送信元端末S1に送信権が与えられた旨を、送信元端末S1に対して通知してもよい。
ステップS15における確認の結果、送信元端末S1以外の端末が送信権を取得している場合には(ステップS15においてYes)、送信元端末S1に送信権を与えず、当該RTPパケットを破棄する(ステップS17)。また、送信元端末S1に送信権が与えられなかった旨を、送信元端末S1に対して通知してもよい。
送信元端末S1から送信されたRTPパケットが、RTPパケット複製部M5に渡された場合は(ステップS13においてYes、又はステップS15においてNo及びステップS16)、グループ所属端末群情報記憶部D1の情報に基づいて送信先送信元端末S1が所属する所属グループの各端末を特定する。そして、特定した各端末にRTPパケットを配信するために、RTPパケット複製部M5は、各端末宛にRTPパケットを複製する。また、RTPパケット複製部M5は、複製したRTPパケットを送信RTPパケット記憶部M6に渡す(ステップS18)。
ここで、RTPパケットの送信先について図6を参照して説明する。図6に表される第1の端末T1がプッシュ操作を受け付けた送信元端末S1に相当する。よって、第1の端末T1から配信装置E1に対してRTPパケットが送信される。
また、第1の端末T1はグループG1に所属する。そのため、第1の端末T1と同じグループG1に所属する第3の端末T3、第nの端末Tn等にはRTPパケットが配信される。一方で、第1の端末T1と異なるグループに所属する第3の端末T3等には配信されない。
このように配信先が決定される理由について説明する。それは、グループ所属端末群情報記憶部D1に、グループG1に所属する端末の情報として、第1の端末T1、第3の端末T3及び第nの端末Tn等の端末ID、並びに、これら端末IDのそれぞれに関連付いたIPアドレスの情報が、記憶されているからである。また、グループG2に所属する端末の情報として、第2の端末T2等の端末ID、並びに、第2の端末T2等の端末IDのそれぞれに関連付いたIPアドレスの情報が記憶されているからである。そして、RTPパケット複製部M5が、グループ所属端末群情報記憶部D1に記憶されているこれらの情報に基づいてRTPの複製及び配信先を決めているからである。
また、RTPパケット複製部M5は、送信元端末S1から受信したRTPパケットを単純に複製するだけではない。この点について、一般的な技術と比較しながら説明をする。
まず、一般的な技術によって、イーサネット(登録商標)上を流れる一般的なIPパケットを転送する際の様子について図7を参照して説明する。なお、図中において凡例として説明しているように、イーサネット上を流れるパケットの上段部にはIPパケットに関する情報を表す。具体的には、情報として宛先IPアドレス及び送信元IPアドレスを表す。また、下段側にはイーサネット・フレームに関する情報を表す。具体的には、情報として宛先MACアドレス及び送信元MACアドレスを表す。
イーサネット・フレームはルータで中継されるときに作り換えられる。そのとき、イーサネット・フレームに記載されている送信元のMACアドレスと宛先のMACアドレスが変わる。
一方で、IPパケットには送信元IPアドレスと宛先IPアドレスが書いてあるが、これらはルータで中継されたとしても、宛先に届くまで変わらない。この点について、図7の例にあてはめて説明する。
図7の例にあてはめると、パソコンAからサーバXにIPパケットが送られる場合、宛先MACアドレスは、ルータを中継する際に、ルータのネットワークセグメント1側のMACアドレスCからサーバXのMACアドレスEに変わる。また、パソコンAからサーバXにIPパケットが送られる場合、送信元MACアドレスは、パソコンAのMACアドレスAからルータのネットワークセグメント2側のMACアドレスDに変わる。しかし、IPアドレスは、宛先IPアドレスも送信元IPアドレスも変わらない。
ここで仮に、配信装置E1が図7に表されるルータと同様の動作をすると考える。そうすると、配信装置E1は、MACアドレスは書き換えるが、IPアドレスは書き換えないことになる。
しかし、配信装置E1から送信元IPアドレスを第1の端末T1のIPアドレスとして配信してしまうと問題が生じる可能性がある。例えば、第1の端末T1と第2の端末T2が同一のネットワークセグメントに存在していたとする。そして、配信装置E1は、これら2つの端末が存在するネットワークセグメントとは異なるネットワークセグメントに存在していたとする。
この場合、第1の端末T1のIPアドレスが送信元IPアドレスとなったIPパケットが、配信装置E1経由で、配信装置E1が存在するネットワークセグメントから第2の端末T2に届く。すると、第2の端末T2からみると、第1の端末T1が、第2の端末T2とは異なるネットワークセグメント(配信装置E1が存在するネットワークセグメント)に存在するかのように誤認する可能性がある。
このため、IPヘッダ制御部M8−1は、送信元IPアドレスを送信元端末S1のIPアドレスから配信装置E1のIPアドレスに書き換え、更に、宛先IPアドレスを、配信装置E1のIPアドレスから各送信先端末のIPアドレスに書き換えて送信する。そして、RTPパケット複製部M5は、この書き換えられたIPアドレスを使用してRTPパケットを複製する。複製したRTPパケットは、配信するために、送信RTPパケット記憶部M6に渡される(ステップS18)。
送信RTPパケット記憶部M6に格納されたRTPパケットは、RTPパケット送信部M7に渡され、実際に各送信先端末(第1の送信先端末R1乃至第nの送信先端末Rn)に配信する(ステップS19)。
以上説明した動作により、配信装置E1による配信が実現される。
なお、ステップS19でRTPパケット送信する方法として、2種類のRTPパケット送信方法を選択できる。
1つ目のRTPパケット送信方法は、RTPパケットがRTPパケット記憶部M6に格納された時点で、直ちにRTPパケットを配信する方法(以降、「即時送信方式」と記載する)である。
もう1つ目の送信方法は、RTPパケット記憶部M6に格納されたRTPパケットを、一定周期で配信する方法(以降、「定間隔送信方式」と記載する)である。ここで、一定周期とは、任意の周期であって良いが、例えば、20ミリ秒とすることが考えられる。
即時送信方式は、ネットワークのゆらぎが十分小さい場合に有利な方式である。即時送信方式では、直ちにRTPパケットが配信されることから通話の遅延をより少なくすることができる。
一方で、定間隔送信方式は、ネットワークのゆらぎが比較的大きい場合に有利な方式である。本実施形態では、端末同士が直接音声通信するのではなく、配信装置E1を介す。
そのため、上りのゆらぎと下りのゆらぎの両方のゆらぎの影響を受ける。そのため、一般的なジッタバッファではゆらぎを吸収しきれず、頻繁な音飛びにつながる可能性がある。
そこで、定間隔送信方式を採用することによって配信装置が一旦ゆらぎを吸収し、パケット送信間隔を一定間隔に整形して送信する。
ただし、ゆらぎの大きさに比例して、音声遅延が大きくなるという欠点もある。しかし、本実施形態のグループ一斉音声通信は、音声の片方向通信を前提としたものなので、通常の電話の同時双方向音声通信のようには遅延が問題とならない用途も多い。また、本実施形態のグループ一斉音声通信は、送話者がプッシュ操作をして切り替わるため、それまで蓄積した音声遅延が、送話者が切り替わるタイミングでリセットされる。つまり、本実施形態では、音声遅延がそれほど問題とならないことが多いので、ネットワークのゆらぎが比較的大きい場合には、定間隔送信方式を採用すると有益である。
なお、上述した実施形態は、本発明の好適な実施形態ではあるが、上記実施形態のみに本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において種々の変更を施した形態での実施が可能である。例えば、上記実施形態を、以下に説明する各変形例のように変形することが可能である。
[第1の変形例]
次に、上述した実施形態を変形した例の1つである、第1の変形例について説明する。
上述した実施形態では、送信元端末S1は、RTPパケットのSSRC(送信元ID)フィールドに、送信元端末S1を一意に識別するためのIDを格納して送信するが、RTP拡張ヘッダについては使用しない例について説明した。
第1の変形例ではRTP拡張ヘッダも使用する例について説明する。具体的には、図4−1及び図4−2を参照して説明したように、RTP拡張ヘッダに、送信元端末ID、グループID及び特権者情報等を格納するケースについて説明する。
なお、本変形例のように、RTP拡張ヘッダを使用すると、RTPパケットのサイズが増える。よって、RTPパケットを送受信するために、より多くのネットワーク帯域を必要とするというデメリットが発生する。しかし、このデメリットと引き換えに、RTP拡張ヘッダを使用すると、このデメリットと引き換えに、サーバの処理負荷を軽減したり、提供できるサービス機能が増したりするというメリットが発生する。そのため、これらのメリットを享受したい場合に、本変形例を採用すると有益である。
RTP拡張ヘッダの利用方法としては、まず、上述の実施形態のように送信元端末IDをSSRCフィールドに載せるのではなく、RTP拡張ヘッダに送信元端末IDを載せることが考えられる。RTPに準拠した場合には、SSRCフィールドのサイズは32ビット(=4バイト)となる。そのため、送信元端末IDをSSRCに載せる場合には、送信元端末IDを4バイトで表さないとならないという制限がある。しかしながら、SSRCフィールドではなくRTP拡張ヘッダに送信元端末IDを載せることによって、この制限を撤廃することができる。
このように4バイトの制限を撤廃することにより、端末IDに柔軟性を持たせることができる。具体例として、例えばMSISDN(国番号(81)+携帯電話番号から頭の「0」をとったもの)を使用することができる。MSISDNは、12桁であるが、バイナリ値で格納することによって、より少ないバイト数で載せることができる、MSISDNを端末IDとして使用することで、独自のIDを別途定義して使用する煩わしさや手間がなくなる。
また、RTP拡張ヘッダにグループIDを載せることも考えられる。このようにRTP拡張ヘッダにグループIDを載せることによって、RTP拡張ヘッダを参照すれば送信元端末S1の所属しているグループを識別することが可能となる。つまり、送信元端末S1の所属グループを求めるために、端末IDを検索キーとしたグループ所属情報端末群情報の検索を行わなくてもよくなる、というメリットが発生する。そして検索を行わなくてよい分、配信装置E1が他の処理に割ける処理能力が向上し、結果としてグループ内端末同時通信数等を増やすことができる。
更に、RTP拡張ヘッダに特権者情報を載せることも考えられる。このようにRTP拡張ヘッダに特権者情報を載せることによって、各端末のそれぞれを特権者とするか否かを設定することができる。
ここで、特権者がどのようなものであるかについて説明する。プッシュ・ツー・トークグループ一斉音声通信では、無線での使用を前提としているため、送信者が送信権を取得したまま、無線圏外に移動してしまったり、端末のバッテリの残量がなくなり、端末がバッテリ切れに陥ってしまったりして、送信者が通信をできない状況になってしまうことが想定される。
このような場合、送信権開放要求を配信装置E1等が受信することはできない。そのため、特定の端末が送信権を持ったままとなってしまう。このような状況の発生を避けるために、送信権開放要求の有無に関わらず、一定時間で送信権を強制解除する、という方法が考えられる。しかし、特定の送話者が長時間、音声情報を一方的に流したい用途も考えられ、この場合には、この一定時間で送信権を強制解除する、という方法では不都合が発生する。
そこで、本変形例では、特権者を設ける。そして、送信権取得制御手順M4は、特権者からのプッシュ操作(送信権取得要求)を受けた場合は、他の端末が送信権を取得していたとしても、強制的に送信権を取得する。そして、取得した送信権を特権者の端末に与えて、かかる特権者の端末が送信したRTPパケットを配信対象とする。こうすることにより、特権者以外の端末が送信権を取得中に無線圏外に移動してしまったり、端末のバッテリ切れに陥ってしまったりしたような場合であっても他の端末間での通信を継続することが可能となる。
また、特権者の端末が送信権を取得中に無線圏外に移動してしまったり、端末のバッテリ切れに陥ってしまったりすることも想定される。そのため、同一グループの特権者を1台に限定することなく、複数台を特権者として設定してもよい。
更に、RTP拡張ヘッダに送話終了フラグを載せることも考えられる。このようにRTP拡張ヘッダに送話終了フラグを載せることによって、送信権解放要求を明示的に通知することができる。
仮に、送話終了フラグを載せない場合、RTPパケットが一定時間受信されない場合には送話が終了したとみなし、送信権を開放することが考えられる。こうする場合、RTPパケットのネットワーク遅延をどこまで許すかによって、送話終了とみなすまでの時間が変わる。例えば、ネットワーク遅延が小さいことが予想されるような環境では、送話終了と判断するまでの時間を短くすることができるため、送話終了後、短時間で送話終了と判断することができる。しかしながら、ネットワーク遅延が大きくなることが予想される環境では、送話終了と判断するまでの時間を長くとる必要がある。なぜならば、一定時間RTPパケットが受信されない理由が、送信元からのRTPパケットの送信が終了したからなのか、送信元からのRTPパケットが遅延を受けていることから未だRTPパケットが到着していないのか、の何れなのかが区別できないからである。そのため、ネットワーク遅延が大きくなることが予想される環境では、送話終了してからしばらくしないと、送信先端末Rで送話終了を認識できなかったり、配信装置E1で送信権開放が行えなかったりする。
そこで、送信元端末S1がプッシュオフ操作を行ったタイミングで送信するRTPパケットのRTP拡張ヘッダに、送話終了を意味する送話終了フラグを載せる。加えて、また、送話終了フラグを含めて配信装置のRTPパケット複製部M5がRTPパケットを複製して受信端末に通知する。更に、配信装置E1及び受信端末が送話終了フラグを参照する。
このようにすることによって、配信装置E1及び受信端末は、送信元端末S1がプッシュオフ操作を行った後、直ちに送話終了を認識することができる。
[第2の変形例]
次に、上述した実施形態を変形した例の1つである、第2の変形例について説明する。
本変形例は、第1の変形例同様に、RTP拡張ヘッダを使用するものである。
まず、本変形例では、送信元端末S1の名称を送信先端末Rにて表示可能とする。そのために、配信装置E1が配信するRTPパケットのRTP拡張ヘッダに、送信元端末S1の端末名称情報を格納する。
具体的には、配信装置E1の、端末情報テーブルにて送信元端末S1の端末IDと送信元端末S1の端末名称情報を紐付けて記憶しておく。
そして、RTP拡張ヘッダ制御部M8−4は、送信元端末S1から受信したRTPパケットに含まれる送信元端末S1の端末IDを検索キーにして端末情報テーブルを検索することにより、予め設定しておいた端末IDに関連付けた端末名称情報を取得する。そして、RTP拡張ヘッダ制御部M8−4は、取得した端末名称情報から送信元端末名称を求める。そして、配信装置E1は、送信者が変わった際の最初のRTPパケットのRTPパケットのRTP拡張ヘッダに、送信元端末名称を含めて配信する。
配信を受けた送信先端末Rでは、RTP拡張ヘッダを参照することにより、送信元端末S1の名称を知ることができ、この送信元端末S1の名称を送信先端末Rの表示部に表示することが可能となる。
次に、RTP拡張ヘッダに、送信者名称情報を格納するケースについて説明する。
予め配信装置E1にユーザIDに関連付けたユーザ名称情報を設定しておく。
配信装置E1の、端末情報テーブルにてユーザIDと、このユーザIDに対応するユーザのユーザ名称情報を紐付けて記憶しておく。
また、送信元端末S1を使用時に、送信元端末S1に使用者を識別することが可能なユーザIDを登録する。
そして、送信元端末S1は、RTPパケットのRTP拡張ヘッダに、送信元端末S1に登録されたユーザIDを付加して配信装置E1に通知する。
RTP拡張ヘッダ制御部M8−4は、送信元端末S1から受信したRTPパケットに含まれるユーザIDをキー検索キーにして端末情報テーブルを検索することにより、予め設定しておいたユーザIDに関連付けたユーザ名称情報取得し、取得したユーザ名称情報から送信者名称情報を求める。そして、送信者が変わった際の最初のRTPパケットのRTPパケットのRTP拡張ヘッダに、送信者名称を含めて配信する。
これによって、送信先端末Rで送信者の名称を表示することが可能となる。
配信を受けた送信先端末Rでは、RTP拡張ヘッダを参照することにより、送信者の名称を知ることができ、この送信元端末S1の名称を送信先端末Rの表示部に表示することが可能となる。
本変形例では、端末名称情報や送信者名称情報を送信先端末Rにて表示することができるのみならず、通信データ量の増加を最低限に抑え、必要音声通信帯域に与える影響を抑えることができる。その理由は、端末名称情報や送信者名称情報といった名称情報を、送信者が変わった際の最初のRTPパケットに限定してRTPパケットのRTP拡張ヘッダ含めて配信するからである。
[第3の変形例]
次に、上述した実施形態を変形した例の1つである、第3の変形例について説明する。
本変形例は、第1の変形例同様に、RTP拡張ヘッダを使用するものであり、具体的にはRTP拡張ヘッダに、送信元端末S1の位置情報を格納する。位置情報は、送信元端末S1の位置を特定するための情報であれば良く、特に制限はないが、例えばGPS(Global Positioning System)により測位された座標を表す情報を位置情報として使用することができる。
まず、送信元端末S1がプッシュオン操作を受け付けると、送信者が変わって送信元端末S1が最初に送信するRTPパケットのRTP拡張ヘッダに送信元端末S1の位置情報(例えば、GPS情報等)を含めて、配信装置E1に対して送信する。
RTP拡張ヘッダ制御部M8−4は、送信元端末S1から受信したRTPパケットに含まれる位置情報を抽出し、外部のサーバに通知したりする。これによって、外部サーバに送信元端末S1の位置(すなわち、送信者の位置)をログとして残したり、地図検索表示システムなどと連携して、送信元端末S1の位置(すなわち、送信者の位置)を地図上に表示したりするといった応用が可能となる。
また、RTPパケット複製部M5が、位置情報を含めたままRTPパケットを複製して配信することにより、受信端末Rに送信元端末S1の位置(すなわち、送信者の位置)を知らせるようにしても良い。これによって、受信端末のディスプレイに送信者の位置を表示したりするといった応用が可能となる。
なお、送信する全てのRTPパケットのRTP拡張ヘッダに、送信元端末S1の位置情報(例えば、GPS情報等)を付加して配信装置E1に通知するようにしても良い。しかし、必ずしも全てのRTPパケットのRTP拡張ヘッダに位置情報(例えば、GPS情報等)を付加する必要はない。
例えば位置情報(例えば、GPS情報等)を付加するのは、送信元端末S1が送信権取得操作を行う毎に最初のRTPパケットのみに限定しても良い。他にも、送信元端末S1が送信権を得ている状態で予め設定した一定周期のタイミングに限定しても良い。他にも、送信元端末S1が送信権を得ている状態で、端末の位置が予め設定した距離以上を移動する毎のタイミングに限定しても良い。他にも、送信元端末S1が送信権を得ている状態で、ユーザから位置情報送信操作を受け付けたタイミングに限定しても良い。
このように、位置情報(例えば、GPS情報等)を付加するRTPパケットを限定することによって、通信データ量の増加を最低限に抑え、必要音声通信帯域に与える影響を抑えることが可能となる。
[第4の変形例]
次に、上述した実施形態を変形した例の1つである、第4の変形例について説明する。
本変形例では、RTP拡張ヘッダに載せていた送信元端末S1が所属又は選択したグループの情報を、UDPの宛先ポート番号及び送信元ポート番号の一方又は他方に置き換えて、送信元端末S1がRTPパケットを生成する。そして、生成したRTPパケットを、送信元端末S1が配信装置E1に対して送信する。
そして、配信装置E1のUDPヘッダ制御部M8−2は、受信したRTPパケットのUDPの宛先ポート番号又は送信元ポート番号から送信元端末S1が所属又は選択したグループ番号を識別する。
また、このような構成にするのではなく、以下のような構成にしても良い。
送信元端末S1が、送信元端末S1が所属又は選択したグループの情報を、例えばRTP拡張ヘッダに載せてRTPパケットを生成する。そして、生成したRTPパケットを、送信元端末S1が配信装置E1に対して送信する。
そして、配信装置E1のUDPヘッダ制御部M8−2は、受信したグループの情報を、RTPパケットのUDPの宛先ポート番号及び送信元ポート番号の一方又は他方に置き換える。
送信元端末S1が所属又は選択したグループの情報によって、RTPパケットのUDPの宛先ポート番号及び送信元ポート番号の一方又は他方を分ける。これにより、複数グループのRTPパケットを同一の受信端末に複数送ることができるから、受信端末側が複数グループの受話の同時再生に対応するような応用を実現することができる。
以上説明した実施形態及び各変形例をそれぞれ組み合わせるようにしても良い。例えば、変形例1のRTPパケットのSSRC(送信元ID)フィールドに、送信元端末S1を一意に識別するためのIDを格納するという構成と、変形例3の送信元端末S1の位置情報を格納するという構成の双方を組み合わせるようにしても良い。
次に、上述した実施形態及び各変形例を実現する場合の例である、実施例について説明する。
ここで、実際に上述した実施形態及び各変形例を実現する場合には、配信装置E1とは別に、グループ音声通信を制御(保守・端末の死活監視など)したり、端末を認証(端末の盗難・亡失対策を含む)したりするためのサーバが必要になるケースが多いと考えられる。この場合に、物理的に配信装置E1とサーバ装置の2つの装置を必ずしも設ける必要はなく、物理的にサーバ装置を配信装置E1に含めることも可能である。また、サーバの仮想化技術を利用することにより、単一の装置にてサーバ装置と配信装置E1を実現することも可能である。
ただし、配信装置E1の処理能力向上、特に、同時配信端末数を多くするためには、サーバを配信装置とは物理的に分け、配信装置は配信制御に特化させる構成としたほうが有利なケースが多いと考えられる。そして、ローカルエリアネットワークN1にこのようなサーバを配置し、配信装置E1と接続する。
また、サーバを用途に応じて複数設置することも考えられる。このようにサーバ群を設置する場合の配置例としては、保守者がデータを登録する用途のサーバは信頼性の高いローカルエリアネットワークN1側に配置し、端末と直接通信が必要な認証サーバ等は不正なアクセスを防止するためにDMZ(DeMilitarized Zone)に配置することなどが考えられる。
ただ、サーバ装置と配信装置E1を具体的にどのような装置にて実現するのかは、本実施例の要旨ではない。そこで、本実施例では、サーバ装置を制御サーバE2として、配信装置E1とは、別途の装置として実現する場合についてのみ説明し、これら装置の他の実現例や、設置場所については説明を省略する。
なお、以下では、図8乃至10を参照して説明する。ここで、図8は、携帯端末がプッシュオン操作を受け付けた際の動作を表すシーケンス図である。また、図9は、RTPパケットが、長時間未達時の動作を表すシーケンスである。更に、図10は、携帯端末がプッシュオフ操作を受け付けた際の動作を表すシーケンス図である。
ここで、図8乃至10に表されるように、本実施例は、第1の端末T1乃至第nの端末Tn、配信装置E1及び制御サーバE2を含む。
第1の端末T1乃至第nの端末Tnは、近年急激に普及しているスマートフォンで実現すること、あるいは、スマートフォンのOS(Operating System)上に搭載する専用アプリケーションで実現することを想定する。
なお、これらの図に表される制御サーバE2は、端末情報、ユーザ情報及びグループ所属端末群情報の管理更新をする。そして、制御サーバE2は、配信装置E1に更新したデータを通知する、という役割も果たす。これにより、配信装置E1が記憶する端末情報、ユーザ情報及びグループ所属端末群情報は最新の状態に保たれる。
また他にも、制御サーバE2は、各携帯端末の死活情報を監視及び管理する役割や、各携帯端末の位置情報を管理する役割などを持つものとする。
まず、図8を参照して端末がプッシュオフ操作を受け付けた場合の、各機器の動作について説明する。
制御サーバE2は、所定の周期で第1の端末T1〜第nの端末Tnの死活監視を行なう(A101)。死活監視は、任意の方法で行なうことができるが、例えばICMP(Internet Control Message Protocol)に準拠したpingにより行なう。
具体的には、制御サーバE2は、監視対象とする、第1の端末T1乃至第nの端末Tnに対して「echo request」パケットを送信する。第1の端末T1〜第nの端末Tnは、「echo request」パケットを受信すると、これの返信として「echo reply」を制御サーバE2に対して送信する。制御サーバE2は、「echo reply」が返信されてきた端末については、通信可能な状態にあると判断し、「echo reply」が返信されてこなかった端末については、通信不可能な状態にあると判断する。死活監視の結果は、配信装置E1に送信される。配信装置E1は、受信した死活監視の結果に応じて端末情報テーブル内の死活監視の項目を更新する。
次に、第1の端末T1乃至第nの端末Tnの何れかがユーザからプッシュオン操作を受け付ける。今回は、第1の端末T1が、ユーザからのプッシュオン操作を受け付けたと想定する。第1の端末T1は、ユーザからのプッシュオン操作を受け付けると、RTPパケットを配信装置E1に対して通知する(A102)。
RTPパケットを受信した端末は、配信装置E1は、これまでに説明したように、送信元端末、送信元端末の所属するグループ又は送信元端末のユーザが選択したグループを識別することより配信対象とするグループを特定する。そして、配信装置E1は、配信対象とするグループ内の各端末の死活状態を把握するため、グループ所属端末群情報記憶部D1を参照して、各端末についての死活監視情報(図中では「アクティブ端末情報」と表現)を取得する(A103)。
また、配信装置E1は、グループ所属端末群情報記憶部D1を参照して、配信対象とする端末が所属するグループのグループ所属端末群情報や送信権情報(図では「送話者情報」と表現)も取得する(A104)。そして、配信装置E1は、これら取得した情報に基づいて、送信元端末である第1の端末T1に送信権を付与するか否かを判断する。
判断の結果、第1の端末T1に送信権を付与した場合、配信装置E1は、送話者を特定する情報である送話者情報を更新する(A105)。また、配信装置E1は、第1の端末T1に送信権を付与した場合、制御サーバE2に対して、送信権を取得した端末の情報を送話開始情報として通知する(A106)。ここで、送話開始情報には、例えば、送信権を取得した第1の端末T1のIPアドレスと端末ID、第1の端末T1のユーザのユーザID、第1の端末T1からの送信先となるグループのグループID、及び第1の端末T1の位置を表す位置情報が含まれる。
送話開始情報通知を受けとった、制御サーバE2は、送話開始情報の内容をログに残す。また、制御サーバE2は、制御サーバE2の管理者等が参照するために、送話開始情報の内容を含んだログを出力する(A107)。なお、ログには送信端末の位置情報を含めても良い。
また、送話開始情報通知を受けとった、制御サーバE2は、送話開始情報の通知を受けとったことの応答として、送話開始情報応答を配信装置E1に返信する(A108)。送話開始情報応答が、どの送話開始情報通知に関しての応答であるのかが分かるように、送話開始情報応答には送話開始情報通知に含まれている端末ID等の情報を含ませるようにすると良い。
そして、配信装置E1は、第1の端末T1から受信したRTPパケットを複製し、複製されたRTPパケットを、配信先となる各端末(第2の端末T2乃至第nの端末Tn)に対して配信する(A109−1、A109−2及びA109−3)。なお、複製に際して、IPアドレスの書き換え等の加工が伴うことについては、実施形態の説明として上述した通りである。
また、複製されたRTPパケットを受信した配信先の端末では、RTPパケットを参照することにより、送話者の情報を取得し、取得した送話者の情報を端末の表示部に表示することが可能となる。また、併せて、配信先の端末は現在送信権を取得していないことも端末の表示部に表示することが可能となる。更に、複製されたRTPパケットを送信元端末(第1の端末T1)に送信することにより、送信元端末の表示部に、現在送信元端末が送信権を取得していることや、送話者が自端末であることを表示することが可能となる。
次に、図8の動作を行って、送信権を得て配信元端末となった第1の端末T1からのRTPパケットの配信が途切れた場合の動作について説明する。
ここで、第1の端末T1からのRTPパケットの送信が何らかの理由で途切れる理由としては、いくつかの場合が考えられる。例えば、第1の端末T1がプッシュオフ操作を受け付けた場合や、第1の端末T1が無線圏外へ移動した場合や、第1の端末T1がバッテリ切れとなった場合である。
まず、前提として制御サーバE2は、第1の端末T1〜第nの端末Tnの死活監視を行なう(A111)。これについては、図8を参照して説明しているので、ここでは説明を省略する。
次に、上述したような何らかの理由により、第1の端末T1からのRTPパケットの送信が途切れる(A112)。
ここで、配信装置E1は、送信権を得た第1の端末T1からのRTPパケットが一定時間途切れるか否かを監視する。ここで、一定時間は、想定されるネットワーク遅延等の環境に応じて任意に定めることが可能であるが、例えば、10秒とする。そして、第1の端末T1からのRTPパケットが一定時間途切れた場合には、第1の端末T1の送信権の強制解除を行なう(A113)。
また、配信先の各端末に第1の端末T1の送信権の強制解除が行われた旨を配信するために、図8を参照して説明したA103と同様に、グループ所属端末群情報記憶部D1を参照して、アクティブ端末情報を取得する(A114)。また、グループ所属端末群情報記憶部D1に格納されている送話者情報を書き換えることによって、第1の端末T1から送信権を剥奪し、第1の端末T1が所属しているグループで送信権を得ている端末がいない状態とする(A115)。つまり送信権を開放する。
また、配信装置E1は、第1の端末T1から送信権を剥奪した場合、制御サーバE2に対して、送信権を剥奪した端末の情報を送話終了情報として通知する(A116)。ここで、送話終了情報には、送話開始情報と同じように、第1の端末T1の端末ID等を含ませる。
送話終了情報通知を受けとった、制御サーバE2は、送話終了情報の内容をログに残す。また、制御サーバE2は、制御サーバE2の管理者等が参照するために、送話終了情報の内容を含んだログを出力する(A117)。なお、ログには送信端末の位置情報を含めても良い。
また、送話終了情報通知を受けとった、制御サーバE2は、送話終了情報の通知を受けとったことの応答として、送話終了情報応答を配信装置E1に返信する(A118)。送話終了情報応答が、どの送話終了情報通知に関しての応答であるのかが分かるように、送話終了情報応答には送話終了情報通知に含まれている端末ID等の情報を含ませるようにすると良い。
その後、各端末も送信権の強制解除を行なうが、これは、送信権の強制解除が行われた旨を配信装置E1が配信することにより行なわれても良いが、各端末が判断をすることにより行われても良い。
まず前者の場合について説明する。制御サーバE2は、第1の端末T1の送信権の強制解除が行われた旨を、配信先端末であった各端末(第2の端末T2乃至第nの端末Tn)及び送信元端末であった第1の端末T1に対して通知する(A119−1、A119−2及びA119−3)。かかる通知を受けた各端末は、送話者がいなくなった旨を端末の表示部に表示することが可能となる。また、第1の端末T1は、自端末が送信権を未取得の状態となったことを表示することが可能となる。
次に後者の場合について説明する。上述したように、A119−1、A119−2及びA119−3において、第1の端末T1の送信権の強制解除が行われた旨を送信するという処理を行わないようにしても良い。そして、各端末が、第1の端末T1の送信権の強制解除が行われたか否かを判定するようにしても良い。
つまり、配信先端末であった各端末(第2の端末T2乃至第nの端末Tn)の、それぞれが、送信権を得た第1の端末T1から送信され、配信装置E1により配信されるRTPパケットが一定時間途切れるか否かを監視する。そして、RTPパケットが一定時間途切れた場合には、第1の端末T1の送信権の強制解除が行われたと判断しても良い。これにより、各端末は、送話者がいなくなった旨を端末の表示部に表示することが可能となる。
また、更に第1の端末T1は、受信したRTPに含まれる端末IDが、第1の端末T1自身の端末IDでなくなった場合に、送信権の強制解除が行われたと判断しても良い。これによっても、第1の端末T1、送話者がいなくなった旨を端末の表示部に表示することが可能となる。
なお、第1の端末T1がRTPパケットを送信していても、特権者が送信権を強制的に取得したような場合にも、受信したRTPに含まれる端末IDが、第1の端末T1自身の端末IDでなくなる。第1の端末T1はこのような場合にも、送信権の強制解除が行われたと判断すると良い。
以上説明した動作により、送信元端末である第1の端末T1から配信装置へのRTPパケットや、配信装置E1から配信先端末へのRTPパケットが一定時間途絶えた場合、配信装置E1や、各端末は送信権の解放を行う。
なお、RTPパケットが一定時間途絶えてから送信権を解放すると判断するまでの時間を長くしてしまうと、送信元端末が送信権を持ったまま、無線圏外へ移動した場合やバッテリ切れとなった場合に、送信権を解放するまでの時間が長くなってしまう。そのため、他の端末が送信権を得るまでの時間も長くなってしまう。しかしながら、第1の変形例として説明したように、RTPパケットのRTP拡張ヘッダに特権者情報を含めることにより、RTPパケットが一定時間途絶える前であっても、特権者の端末が送信権を得ることができる。従って、他の端末が送信権を得るまでの時間も長くなってしまう、という問題を解決することができる。
次に、図8の動作を行って配信元端末となった第1の端末T1がプッシュオフ操作を受け付けた場合であって、RTPパケットのRTP拡張ヘッダに送話終了フラグを含める場合について図10を参照して説明する。送話終了フラグは第1の変形例の説明時に述べたように送信権解放要求を明示的に通知するためのものである。
まず、制御サーバE2は、第1の端末T1〜第nの端末Tnの死活監視を行なう(A131)。これについては、図8を参照して説明しているので、ここでは説明を省略する。
次に、現在配信元端末である第1の端末T1がプッシュオフ操作を受け付ける。すると、第1の端末T1は、プッシュオフ操作を受け付けたタイミングで送信するRTPパケットのRTP拡張ヘッダに、送話終了を意味する送話終了フラグを載せる。そして、第1の端末T1によるRTPパケットの送信が止まる。
ここで、図9を参照して説明した動作では、RTPパケットの送信が止まってから、一定期間の監視を行ってから送信権の開放を行っていた。しかし、本例では、一定期間の経過を待つ必要はない。配信装置E1は、受信したRTPパケットに含まれる送話終了フラグを確認すると、一定期間の経過を待つことなく送信権の開放を速やかに行なう。
そのために、配信装置E1は、送話終了フラグを含んだRTPパケットを各端末装置に対して送信する。まず、配信装置E1は、送話終了フラグを含んだRTPパケットを配信するために、図8を参照して説明したA103と同様に、グループ所属端末群情報記憶部D1を参照して、アクティブ端末情報を取得する(A133)。また、グループ所属端末群情報記憶部D1に格納されている送話者情報を書き換えることによって、第1の端末T1から送信権を剥奪し、第1の端末T1が所属しているグループで送信権を得ている端末がいない状態とする(A134)。つまり送信権を開放する。
また、配信装置E1は、第1の端末T1から送信権を剥奪し場合、制御サーバE2に対して、送信権を剥奪し端末の情報を送話終了情報として通知する(A135)。ここで、送話終了情報には、送話開始情報と同じように、第1の端末T1の端末ID等を含ませる。
送話終了情報通知を受けとった、制御サーバE2は、送話終了情報の内容をログに残す。また、制御サーバE2は、制御サーバE2の管理者等が参照するために、送話終了情報の内容を含んだログを出力する(A136)。なお、ログには送信端末の位置情報を含めても良い。
また、送話終了情報通知を受けとった、制御サーバE2は、送話終了情報の通知を受けとったことの応答として、送話終了情報応答を配信装置E1に返信する(A137)。送話終了情報応答が、どの送話終了情報通知に関しての応答であるのかが分かるように、送話終了情報応答には送話終了情報通知に含まれている端末ID等の情報を含ませるようにすると良い。
その後、制御サーバE2は、送話終了フラグを含んだRTPパケットを、配信先端末であった各端末(第2の端末T2乃至第nの端末Tn)及び送信元端末であった第1の端末T1に対して配信する(A119−1、A119−2及びA119−3)。かかる送話終了フラグを含んだRTPパケットを受信した各端末は、送話終了フラグを参照することにより、送話者がいなくなったことを把握できる。そして、その旨を端末の表示部に表示することが可能となる。また、第1の端末T1は、自端末が送信権を未取得の状態となったことを表示することが可能となる。
以上説明したように、RTPパケットに送話終了フラグを含めれば、一定時間の経過を待つ必要がなくなり、即座に送信権の開放を行なうことができる。これに伴い、配信先端末の表示を、送信権未取得及び送話者なしの表示に変更することが瞬時にできるようになる。また、制御サーバE2に送信権を解放した端末の情報を通知し、制御サーバはこれをログに残すことも瞬時にできる。
以上説明した本発明の実施形態及び各変形例は、以下に示すような多くの効果を奏する。
第1の効果は、PoCグループ一斉音声通信で、大規模かつ広域で提供したりする用途に適用できることである。
ここで、大規模とは、現在通信事業者が提供しているサービスを利用した場合であれば、例えば、端末にLTE(Long Term Evolution)に対応したスマートフォンを利用する状況を想定する。また、端末と配信装置間の回線は、バックボーンにNGN(Next Generation Network)を持つ高品質、高信頼の広域イーサネットサービスを利用して1Gbit/s程度の帯域を確保した状況を想定する。そして、大規模とは、このような状況において、グループ内端末同時通信数を、10,000端末程度までの規模に対応できる効果が期待できることを意味する。
このような第1の効果を奏する理由は、配信装置のRTPパケット複製部を、RTPパケットのペイロードの複製及びヘッダの加工のみを行なう、シンプルな構成としたことで、配信装置の必要なパケット複製能力(単位時間当たりの複製数)を確保することができるからである。ここで、シンプルな構成とは、複雑なソフトウェアロジックを必要とせず、ハードウェア、又は、OSレスレベルのソフトウェアの制御で実現可能なレベルの制御を指す。
また、第1の効果を奏する更なる理由は、RTPパケットのSSRC(送信元ID)フィールドに、送信元端末IDを含めるからである。又は、RTPパケットのRTP拡張ヘッダに、送信元端末ID・グループID・端末ID・特権者情報などのPoCグループ一斉音声通信を制御するための情報を付加して送受信するからである。そしてこのようにすることにより、PoCグループ一斉音声通信を制御するための必要最低限の情報を、送信元端末から配信装置との間、配信装置から受信端末との間で、RTPパケットのみで送受信することが可能となるからである。そして、結果として、別の制御パケットで送受信する必要がなくなり、必要パケット数を減らすことで必要帯域を削減できるからである。
また、第2の効果は、PoCグループ一斉音声通信で、プッシュオン操作を行って送信権を取得し、送話を開始できるようになるまでの送話者切り替え時間を短縮できることである。そして、結果として、通話の頭切れを防止できることである。
このような第2の効果を奏する理由は、RTPパケットのSSRC(送信元ID)フィールド、又は、RTPパケットのRTP拡張ヘッダに、送信元端末IDを含めることで、送信権制御用の別のパケットの送受信が不要となるからである。そしてこれにより、送信権制御用のパケットの到達遅延や処理遅延によって、送話者切り替えタイミングが遅れることがなくなるからである。
また、第2の効果を奏する更なる音声情報を含んだRTPパケットが到達した時点で、送信元IDが識別できるので、送信元端末の所属グループIDを識別することができ、所属グループIDから配信すべき受信端末群の情報を求めることや送信権取得制御を行なうことができるからである。
また、第2の効果を奏する更なるRTPパケットのRTP拡張ヘッダに、グループIDなどのPoCグループ一斉音声通信を制御するための情報を付加して送受信することで、送信元端末の所属グループIDの識別にかかる処理時間を更に短縮することができるからである。ここで、送信元端末の所属グループIDの識別にかかる処理時間とは、送信元端末IDをキーに送信元端末の所属又は選択グループIDのデータベース検索にかかる処理時間等のことである。
更に、第3の効果は、PoCグループ一斉音声通信で、送信端末のバッテリ切れや無線通信圏外への移動、送信者の送信終了操作忘れ時の対策が強化されることである。この効果は、同時片方向通信が前提のグループ一斉音声通信の、「送信端末が送信中に、受信端末は送信端末に対して音声で連絡できない」というデメリットを補うメリットも併せ持つ。
このような第3の効果を奏する理由は、RTPパケットのRTP拡張ヘッダに、特権者情報を含めたことで、送信権制御用の別のパケットの送受信が不要となるからである。また、先の送信端末が送信権を取得したままバッテリ切れや無線通信圏外への移動、送信者の送信終了操作忘れ時で、送信権を保有したままの状態になったときに、特権者の権限を持つ後の送信端末が強制的に送信権を得ることができるからである。
更に、第4の効果は、PoCグループ一斉音声通信で、提供できるサービス機能を拡張することができることである。
このような第4の効果を奏する理由について説明する。
仮に、一般的な技術によって送信者の情報を受信端末にリアルタイムに表示しようとすると、音声パケットとは別の制御パケットを用いて、グループに含まれる端末の一覧情報をサーバから端末にダウンロードしておいたり、一斉配信したりする必要がある。そのため、一般的な技術では、制御パケットの必要帯域や、端末情報を管理しているサーバの処理負荷等の物理的制約で、実際には実現が困難である。また、他の一般的な技術として、サーバから受信端末にダウンロードしておくことも考えられる。しかし、このような方法では、端末側からのダウンロード要求が送られてくるタイミングが、多くの複数端末から集中する可能性がある。そのため、必要となるサーバの処理能力やネットワーク帯域の算出や制御が困難になるという問題点もある。
しかしながら、本発明の実施形態では、配信装置が送信する、送信者が変わった際の最初に配信するRTPパケットのRTPパケットのRTP拡張ヘッダに、送信元端末名称又は送信端末のユーザ名称等を含める。そして、本発明の実施形態では、こうすることによって、送信先端末で送信元端末の端末名称やユーザ名称を表示することが可能となり、送信者がいちいち音声で名乗らなくても、受信者が送信者を認識することができる。このようにして、本発明の実施形態では、上記の第4の効果を奏することができる。
なお、上記の配信システムに含まれる、配信装置、各端末及び制御サーバの各々は、それぞれ、ハードウェア、ソフトウェア又はこれらの組み合わせにより実現することができる。また、上記の配信システムに含まれる、配信装置、各端末及び制御サーバの各々より行なわれる配信方法も、ハードウェア、ソフトウェア又はこれらの組み合わせにより実現することができる。ここで、ソフトウェアによって実現されるとは、コンピュータがプログラムを読み込んで実行することにより実現されることを意味する。
プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体(例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ)、光磁気記録媒体(例えば、光磁気ディスク)、CD−ROM(Read Only Memory)、CD−R、CD−R/W、半導体メモリ(例えば、マスクROM、PROM(Programmable ROM)、EPROM(Erasable PROM)、フラッシュROM、RAM(random access memory))を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
(付記1) 配信先の端末群を特定するための識別情報を、第1のプロトコルに準拠したヘッダに格納したパケットを受信し、
前記識別情報に基づいて、配信先の端末群に含まれる各端末それぞれの第2のプロトコルに準拠したアドレスを取得し、前記受信したパケットを複製し、該複製したパケットを、前記取得した各アドレス宛に送信することを特徴とする配信装置。
(付記2) 各端末それぞれの第2のプロトコルに準拠したアドレスと前記識別情報とを紐付けておき、前記パケットを受信したときに、該パケットに含まれている前記識別情報と前記紐付けられている前記アドレスを前記配信先の端末のアドレスとして取得することを特徴とする付記1に記載の配信装置。
(付記3) 前記配信先の端末群に含まれる各端末の何れにも送信権を付与していない場合に、前記パケットの送信元の端末に送信権を付与し、前記送信権を付与した端末が送信したパケットを、配信の対象とすることを特徴とする付記1又は2に記載の配信装置。
(付記4) 何れかの端末を特権者端末として扱い、前記特権者端末が送信したパケットを受信したならば、前記送信権を付与した端末から前記送信権を剥奪し、該剥奪した送信権を前記特権者端末に付与することによって、前記特権者端末が送信したパケットを配信の対象とすることを特徴とする付記3に記載の配信装置。
(付記5) 端末がパケットを受信可能な状態に有るか否かを所定の周期で監視し、該監視の結果に基づいて、配信先の端末群に含まれる端末であってパケットを受信可能な状態にある端末を、パケットを配信する対象とすることを特徴とする付記1乃至4の何れか1に記載の配信装置。
(付記6) 前記第1のプロトコルとはRTP(Real-time Transport Protocol)であり、前記識別情報は、RTPペイロードではなく、RTPヘッダのSSRC(Synchrozination Source)フィールド又はRTP拡張ヘッダに格納されることを特徴とする付記1乃至5の何れか1に記載の配信装置。
(付記7) 前記第2のプロトコルとは、IP(Internet Protocol)であり、前記受信したパケットを複製するときに、パケットの送信元IPアドレスをパケットの送信元の端末のIPアドレスから自配信装置のIPアドレスに書き換え、更に、パケットの宛先IPアドレスを、自配信装置のIPアドレスから配信先の端末のIPアドレスに書き換えることを特徴とする付記1乃至6の何れか1に記載の配信装置。
(付記8) 付記1乃至7の何れか1に記載の配信装置と、端末とを含む配信システムであって、
前記配信装置は、前記複製したパケットに、パケットの送信元の端末を表す情報又はパケットの送信元の端末のユーザを表す情報何れか又は双方を含ませ、
前記配信装置からパケットを配信された端末は、パケットに含まれているパケットの送信元の端末を表す情報又はパケットの送信元の端末のユーザを表す情報の何れか又は双方を出力する
ことを特徴とする配信システム。
(付記9) 付記1乃至7の何れか1に記載の配信装置と、端末とを含む配信システムであって、
前記配信装置は、前記配信先の端末群に含まれる各端末の何れにも送信権を付与していない場合に、前記パケットの送信元の端末に送信権を付与し、前記送信権を付与した端末が送信したパケットを配信の対象とし、
前記送信権を付与された端末は、ユーザの操作に基づいて、送信権開放要求をパケットに含ませて前記配信装置に送信し、
前記配信装置及び前記配信装置からパケットの配信を受けた端末は、前記パケットに前記送信権開放要求が含まれている場合に、前記送信権を付与された端末の送信権を剥奪することを特徴とする配信システム。
(付記10) 配信先の端末群を特定するための識別情報を、第1のプロトコルに準拠したヘッダに格納したパケットを受信し、
前記識別情報に基づいて、配信先の端末群に含まれる各端末それぞれの第2のプロトコルに準拠したアドレスを取得し、前記受信したパケットを複製し、該複製したパケットを、前記取得した各アドレス宛に送信する配信装置としてコンピュータを機能させることを特徴とする配信プログラム。
(付記11) 任意の送信元端末からのRTPパケットを受信するRTPパケット受信手段と、
グループに所属する端末群がどれかを識別するための情報を記憶するグループ所属端末群情報記憶手段と、
受信したRTPパケットを一時的に記憶するRTPパケット記憶手段と、
当該RTPパケットを送信してきた送信元端末に送信権を与えてよいかを判断する送信権取得制御手段と、
当該送信元端末に送信権を与えた場合に、受信したRTPパケットをグループ所属端末群情報に従って、当該グループに所属するそれぞれの送信先端末に向けたパケットに複製するRTPパケット複製手段と、
RTPパケット複製手段がRTPパケットを複製する際に、IPヘッダの送信元IPアドレスを自装置のIPアドレスに、IPヘッダの宛先IPアドレスを各送信先端末のIPアドレスに書き換えるIPヘッダ制御手段と、
RTPパケット複製手段が複製したRTPパケットを一時的に記憶する送信RTPパケット記憶手段と、
送信RTPパケット記憶手段が記憶しているRTPパケットを各送信先端末に送信するRTPパケット送信手段を具備する配信装置。
(付記12) グループ所属端末群情報に加えて、各端末の死活情報も加味してRTPパケットを送信すべき端末群を識別するRTPパケット複製手段を具備する、付記11記載の配信装置。
(付記13) RTPパケットのRTP拡張ヘッダに、送信元端末が送話終了操作を行ったことを示す、送話終了フラグを付加して配信装置に通知する送信元端末と、受信したRTPパケットのRTP拡張ヘッダに含まれた送話終了フラグを元に送信元端末IDを認識するRTP拡張ヘッダ制御手段と、送話終了を検知すると、RTPパケットの配信を終了するRTPパケット複製手段を具備する、付記11又は12記載の配信装置。
(付記14) RTPパケットのSSRC(送信元ID)情報に、送信元端末を一意に識別するための送信元端末IDを付加して配信装置に通知する送信元端末と、当該送信元端末IDをキーに送信元端末に送信権を与えてよいかを判断する送信権取得制御手段を具備する、付記11乃至13記載の配信装置。
(付記15) RTPパケットのSSRC(送信元ID)情報に、送信元端末を一意に識別するための送信元端末IDを付加して配信装置に通知する送信元端末と、受信したRTPパケットのSSRC(送信元ID)情報を元に送信元端末IDを認識するRTPヘッダ制御手段と、当該送信元端末IDをキーに送信先端末グループを求める送信元端末ID制御手段を具備する、付記11乃至14記載の配信装置。
(付記16) RTPパケットのRTP拡張ヘッダに、送信元端末を一意に識別するための送信元端末IDを付加して配信装置に通知する送信元端末と、受信したRTPパケットのRTP拡張ヘッダに含まれた送信元端末ID情報を元に送信元端末IDを認識するRTP拡張ヘッダ制御手段と、当該送信元端末IDをキーに送信先端末グループを求める送信元端末ID制御手段を具備する、付記11乃至15記載の配信装置。
(付記17) RTPパケットのRTP拡張ヘッダに、送信元端末が所属又は選択したグループを識別するためのグループIDの情報を付加して配信装置に通知する送信元端末と、受信したRTPパケットのRTP拡張ヘッダに含まれたグループID情報を元に送信元端末IDを認識するRTP拡張ヘッダ制御手段と、当該グループIDをキーに送信先端末グループを求めるRTP拡張ヘッダ制御手段を具備する、付記11乃至16記載の配信装置。
(付記18) RTPパケットのRTP拡張ヘッダに、送信元端末の特権者情報を付加して配信装置に通知する送信元端末と、受信したRTPパケットのRTP拡張ヘッダに含まれた特権者情報を元に特権者かどうかを認識するRTP拡張ヘッダ制御手段と、特権者として通知された場合に、他の端末が送信権を有している場合でも、強制的に特権者の送信元端末に送信権を与える送信権取得制御手段を具備する、付記11乃至17記載の配信装置。
(付記19) RTPパケット複製手段がRTPパケットを複製する際に、送信元端末の情報をキーに、予め設定しておいた端末IDに関連付けた端末名称情報から送信元端末名称情報を求め、送信者が変わった際の最初のRTPパケットのRTPパケットのRTP拡張ヘッダに、送信元端末名称を含めるRTP拡張ヘッダ制御手段を具備し、送信先端末で送信元端末の名称を表示することが可能なようにした、付記11乃至18記載の配信装置。
(付記20) 送信元端末を使用する際に、送信元端末に使用者を一意に識別することが可能なユーザIDを登録するようにしておいて、RTPパケットのRTP拡張ヘッダに、当該ユーザIDの情報を付加して配信装置に通知する送信元端末と、RTPパケット複製手段がRTPパケットを複製する際に、ユーザIDの情報をキーに、予め設定しておいたユーザ端末IDに関連付けたユーザ名称情報から送信元端末の使用者のユーザ名称(送信者名称)情報を求め、送信者が変わった際の最初のRTPパケットのRTPパケットのRTP拡張ヘッダに送信者名称を含めるRTP拡張ヘッダ制御手段を具備し、送信先端末で送信者の名称を表示することが可能なようにした、付記11乃至19記載の配信装置。
(付記21) RTPパケットのRTP拡張ヘッダに、送信元端末の位置情報(GPS情報等)を付加して配信装置に通知する送信元端末と、受信したRTPパケットのRTP拡張ヘッダに含まれた位置情報を元に送信元端末の位置情報を認識するRTP拡張ヘッダ制御手段を具備する、付記11乃至20記載の配信装置。
(付記22) RTPパケットのRTP拡張ヘッダに、送信元端末の位置情報(GPS情報等)を付加して配信装置に通知するのは、送信元端末が送信権取得操作を行う毎に最初のRTPパケットのみに限定した付記21記載の配信装置。
(付記23) RTPパケットのRTP拡張ヘッダに、送信元端末の位置情報(GPS情報等)を付加して配信装置に通知するのは、送信元端末が送信権を得ている状態で、予め設定した一定周期のタイミングに限定した付記21乃至22記載の配信装置。
(付記24) RTPパケットのRTP拡張ヘッダに、送信元端末の位置情報(GPS情報等)を付加して配信装置に通知するのは、送信元端末が送信権を得ている状態で、端末の位置があらかじめ設定した距離以上を移動する毎のタイミングに限定した付記21乃至23記載の配信装置。
(付記25)RTPパケットのRTP拡張ヘッダに、送信元端末の位置情報(GPS情報等)を付加して配信装置に通知するのは、送信元端末が送信権を得ている状態で、位置情報送信操作を行ったタイミングに限定した付記21乃至24記載の配信装置。
(付記26) 送信元端末が所属又は選択したグループの情報を、UDPの宛先ポート番号又は送信元ポート番号の片方又は両方に置き換えてRTPパケットを送信する送信元端末と、受信したRTPパケットのUDPの宛先ポート番号から送信元端末が所属又は選択したグループ番号を識別することが可能なUDPヘッダ制御手段を具備する、付記11乃至25記載の配信装置。
(付記27) 送信元端末が所属又は選択したグループの情報を送信する送信元端末と、受信したグループの情報を、RTPパケットのUDPの宛先ポート番号又は送信元ポート番号の片方又は両方に置き換えることが可能なUDPヘッダ制御手段を具備する、付記11乃至26記載の配信装置。
(付記28) 送信元端末又は送信先端末に、携帯電話、スマートフォン又はスマートフォン上に搭載するアプリケーションソフトを使用し、これらと組み合わせて動作する付記1乃至7記載の配信装置又は付記11乃至27記載の配信装置を利用したグループ一斉音声通信システム又はその制御方法。
(付記29) 送信元端末又は送信先端末と配信装置との間の通信網に、通信事業者が提供する携帯電話用パケット通信網を使用し、又は更に専用線網と組み合わせて動作する付記21記載の配信装置又は付記28記載の配信装置を利用したグループ一斉音声通信システム又はその制御方法。