JP4138746B2 - 会議システム - Google Patents

Description

本発明は、通信システムにおいて会議通話をセットアップする方法や装置に関し、特に限定するわけではないが、ことに無線通信システムに関係する。

会議通話のコンセプトは公衆交換電話網（PSDN）において良く知られている。PSTNによる会議は、通常、最初の参加者が特定の顧客サポート番号へ電話をかけ、会議ブリッジ番号とPINコードの供給を受けることによってセットアップされる。そして最初の参加者は、他の参加しそうな者へこの情報を教える。会議通話に参加したい者は、それぞれ会議ブリッジ番号に電話をかけ、要求に応じてPINコードを入力すると、会議通話への参加が認められる。

または、インターネットが会議通話を準備するために用いられうる。特定のウェブサイトが最初の参加者によってアクセスされ、ブリッジ番号やPINコードを入手しうる。そこで最初の参加者は詳しい情報を他の参加者へと教えることができる。

どちらのやり方によっても移動端末が会議通話に参加することが可能である。しかしながら、どちらの方法も主に２つの不便がある。第１に、会議通話は事前に計画されなければならない。いつ会議通話が行なわれるかを皆に知らせ、その時に皆が会議ブリッジ番号に電話をかけることができるように、いろいろな参加者が互いに連絡し合わなければならない、第２に、参加者自身が他の参加者に渡すべきブリッジ番号やPINコードを準備しなければならない。

第三世代インターネット・プロトコル・マルチメディア・サブシステム（IMS）無線通信システムにおいては、会議サービスを提供する様々なモデルが提案されてきている。例えば、J.Rosenberg、H.Schulzrinne著、「Models for Multi Party Conferencing in SIP」（IETFドラフト）。このドラフトの中のどのモデルもSIP（Session Initiation Protocol）メッセージングを用いている。SIPプロトコルはインターネット標準RFC3261とRFC2543で議論されている。いくつかのモデルを以下に簡単に説明する。

はじめのモデルは「エンド・システム・ミキシング」（end system mixing）として知られており、会議通話に参加する１つの端末が、その会議通話において他の端末に送受信される信号やメディアストリームをミックスする（マージする）というものである。図１ａは、このモデルを用いた三者通話の様子を描いた図である。この例では、ユーザーＡとＢが二者通話を行なっている。通話のある時点でユーザーＡがユーザーＣを通話に参加させようと決めたとする。これを行なうため、ユーザーＡは完全に別個のSIPコールによって、ユーザーＣに電話をかける。ＢとＣの間には通話のセットアップは行なわれない。その代わり、ＡはＢとＣからのメディアストリームを受信してミックスする。端末Ａは、端末Ａのストリームと端末Ｂのストリームとを含むストリームを端末Ｃに送信し、端末Ａのものと端末Ｃのものとを含むストリームを端末Ｂに送信する。このモデルにおいて、SIPの観点からみると、端末ＢとＣは二者以上が通話に参加していることに気づかない。

三台以上の端末が通話に参加する場合は、一台以上の端末が通話を維持するためにミキシングと信号伝達を行なう。例えば、上記の例の１つの拡張として、ユーザーＣが４番目のユーザーＤを会議通話に招くと決めたとする。ユーザーＣはユーザーＤに電話をかけ、端末Ｃは端末Ａから受信したストリームと自分のストリームをミックスして、混合ストリームをＤへと送信する。また自分のストリームとＤのストリームをミックスし、Ａへと送信する。このような構成が図１ｂに示される。

このモデルの非常に不便な点は、ミキシングを担当している端末が通話から離れると、会議通話も終了してしまうことと、ミキシング担当の端末に送信された伝達メッセージが、その端末だけに宛てられたものなのか、会議通話の全端末に宛てられたものなのかを、ミキシング担当端末が決定する手段が何もないことである。

別のモデルは、ダイヤルインの会議サーバーを用いた、上記のPSTNシステムを大きく真似たものである。一人の参加者が、会議通話を識別するためのURI（Uniform Resource Identifier）を定義し、他の参加者に送信する。参加者はそのURIを用いて各々サーバーへ電話をかけ、サーバーは電話をかけてきた個々の参加者とポイント・ツー・ポイントのSIP関係を維持する。サーバーが個々の参加者からのメディアを受け取り、ミックスし、適切な混合ストリームを個々の参加者にそれぞれ送信する。このモデルは図２に描かれており、４人のユーザーであるＡ〜Ｄが会議通話に参加している。

ダイヤルインの会議サーバーは、予め準備された会議にも、アド・ホックな会議に使えるので融通がきく。しかしこのモデルは、同じURIが１つ以上の会議通話に用いられる可能性があるという事に問題がある。これは、電話会議に混信を生ずるかもしれない。

本発明の１つの目的は、上記に述べた問題のうちの１つ又はそれ以上に対する解決法を提供することである。
J.Rosenberg、H.Schulzrinne著、「Models for Multi PartyConferencing in SIP」（IETFドラフト）

本発明の第１の側面によると、複数の端末と会議サーバーを有する通信システムにおいて会議を行なうリソースを管理する方法であって、会議通話を維持しうるリソースの要求を含む第１のメッセージを第１の端末からサーバーへと送信するステップと、会議通話を維持しうるリソースのアドレスを識別するネットワークアドレスをサーバーによって割り当てるステップと、サーバーから第１の端末へ該ネットワークアドレスを含む第２のメッセージを送信するステップと、を備える方法が提供される。

この方法では有利なことに、アド・ホックに開催されるべき会議について、事前に準備される必要がない。さらに、会議同士が重なり合う問題を防ぐことができる。この問題は、サーバーに会議のためのリソースと、そのリソースに対応するアドレスを割り当てる手段とを与えることで、克服される。このようにして、あるアドレスは、ある時点における特定の会議通話の固有のアドレスとなることができる。

本発明の別の有利なことは、会議通話を確立するために、標準のSIPメッセージを使うことが許されることである。さらに、会議を行なうためのリソースの割り当てにおいて、特別のユーザー構成を必要としない。

ユーザーは、該ネットワークアドレスを、会議通話に参加しそうな他のユーザーの端末へ第１の端末から送信することが好ましい。また、会議通話を確立するために、それぞれの接続は、それぞれの端末と該ネットワークアドレスとの間で着手されることが好ましい。
本発明の第２の側面によると、複数の端末を有する通信システムにおいて会議を行なうためのリソースを管理する会議サーバーであって、会議通話を維持しうるリソースの要求を含む第１のメッセージを第１の端末から受信する受信ユニットと、会議通話を維持しうるリソースを識別するネットワークアドレスを割り当てる割り当てユニットと、該ネットワークアドレスを含む第２のメッセージを該第１の端末に送信する送信ユニットと、を備える会議サーバーが提供される。

該受信ユニットは、会議通話を維持しうるリソースの要求を含む第１のメッセージを第１の端末から受信するように構成されることが好ましい。該割り当てユニットは、会議通話を維持しうるリソースを識別するネットワークアドレスを割り当てるように構成されることが好ましい。該送信ユニットは、該ネットワークアドレスを含む第２のメッセージを該第１の端末に送信するように構成されることが好ましい。

該サーバーは単一の場所に設けられるものであってもよいが、その機能が２つかそれ以上の地点に分散されたものであってもよい。

本発明の第３の側面によると、通信システムであって、複数の端末を有する通信システムにおいて会議を行なうためのリソースを管理するための会議サーバーと、第１の端末を含む複数の端末を備え、該会議サーバーはさらに、会議通話を維持しうるリソースの要求を含む第１のメッセージを第１の端末から受信する受信ユニットと、会議通話を維持しうるリソースを識別するネットワークアドレスを割り当てる割り当てユニットと、該ネットワークアドレスを含む第２のメッセージを第１の端末に送信する送信ユニットと、を備える通信システムが提供される。

次に、本発明の実施例を、添付図面を参照して説明する。

以下、本発明は実施態様を参照して説明されるが、その実施態様は本発明を限定するものではない。特に、本発明は3G IMS移動通信ネットワークにおけるSIPの伝達に関して説明されるが、本発明はそのような信号伝達やネットワークに限定されるものではない。

図３を参照すると、２つのユーザー・エージェントが描かれている。ユーザー・エージェント１０を用いる第１のユーザーは、ユーザー・エージェント１１が参加した会議通話を始めることを欲し、会議プロセスに着手するためオペレーターにとって既知のURIへSIP INVITEメッセージ２１を送信する。そのURIはユーザー・エージェントに保管されたものであってもよい。INVITEメッセージ２１は、ユーザー・エージェント１０が会議を始めることを望んでいる旨を示し、また、要求するURIは、次のような形をとることが適当と言えるだろう。

sip:conferences@sonera.fi

INVITEメッセージは、所望のデータレートなど、要求された会議のタイプの詳細情報を含むことができる。これらの詳細情報は、INVITEメッセージ２１のSDP（Session
Description Protocol）ペイロード中にリストアップされたメディアコンポーネントに含まれることができる。

メッセージ２１は、好ましくは一般的なユーザー・エージェント・サーバーである会議サーバー１２に受信される。ここでサーバー１２は、ユーザー名やパスワードなどの詳細情報を要求する確認要求を含んだSIPメッセージをユーザー・エージェント１０に送信し、会議要求を認証することができる。この場合ユーザーは、会議要求が認証されるためには、例えば有効な認証証明などの詳細情報を提供しなければならないだろう。

ユーザー・エージェント１０からの有効な認証情報か受信メッセージ２１に応えて、サーバー１２は要求された会議で用いられるべきダイナミックSIP URIを割り当てる。ダイナミックURI（動的に生成されるURI）は、第１のユーザーによってINVITEメッセージ２１にリストされた要求仕様に従った会議通話に対応するために用いられうるリソース１３を特定している。ネットワークは、そのリソース又はそのリソースを提供する装置へ、そのアドレスへ向かう通信をルーティングできるように構成される。このことを容易とするため、サーバーは予め定められたパターンのセットから会議のためのアドレスを割り当てるように構成されることが好ましい。そうすれば、そのセットのアドレスは、全て会議を行なうための適当なリソースを参照するだろう。サーバー１２は、そのリソースを使用可能としておくために、要求された会議が始まるまでそのリソースを取っておくかもしれない。または、サーバー１２によってどんなリソースも予約されておくことはないが、その代わりに、要求された会議が着手された時に使用可能なリソースを決めるようにしてもよいだろう。該リソースは、会議通話の参加者の端末のそれぞれとポイント・ツー・ポイントの接続を確立することができる。また、それぞれの端末から受信したトラフィック信号をまとめ、まとめた信号を会議通話の参加者である他の端末に送信することができる。それらのトラフィック信号は、音声データの他、ビデオや画像データ（例えばホワイトボードのデータ）などを運ぶことができる。上記のリソースとは、データを取り扱い能力や通信帯域など、会議通話を維持するための如何なるリソースを指していてもよい。また、該リソースはサーバーの一部のような物理的な装置によって構成されることができる。

ダイナミックURIは、SIPメッセージ２２に含まれて会議サーバー１２からユーザー・エージェント１０へと送信される。メッセージ２２は３００番台のコードであるリダイレクト・メッセージであり、URIはメッセージのコンタクト・フィールドに格納されることが好ましい。コンタクト・フィールドが取りうる適切な形の一例は次のようなものである。

Contact: <sip:DKLSKX87KKJ989SHFKJH@conference.sonera.fi>

割り当てられたURIを含むリダイレクト・メッセージを受信すると、ユーザー・エージェント１０はINVITEメッセージ２３をそのURIに送信する。そのURIは予約された会議リソース１３を特定している。そしてINVITEメッセージ２３の受信に応答して、リソース１３は200 OKメッセージ２４のような承認をユーザー・エージェント１０に送信する。

ユーザー・エージェント１０が一旦200 OKメッセージを受信すると、第１のユーザーは、ユーザー・エージェント１１を使っている第２のユーザーに、割り当てられたURIのことを言うことができる。そのURIを含むSIP REFERメッセージ２５のような、さらなるメッセージがユーザー・エージェント１０からユーザー・エージェント１１へと送信される。REFERメッセージは次のような形をとることが適当と言えるだろう。

REFER sip:user_b@pp.radioliznja.fi SIP/2.0

また、次のようなヘッダーが付く。

Refer-To: sip:DKLSKX87KKJ989SHFKJH@conference.sonera.fi;
Method=INVITE

または、URIは第１のユーザーから第２のユーザーへ別の方法で送られてもよい。

上記の機構により、ユーザーは会議リソースをすぐさま予約することができる。そのユーザーの側で特段の情報提供をすることなく、他の参加者は会議通話を形成するために一緒に接続することが可能となる。

ユーザー・エージェント１０からのREFERメッセージの受信に応答して、ユーザー・エージェント１１は202 Acceptedメッセージのような承認を、ユーザー・エージェント１０へと返信する。

ここで、ユーザー・エージェント１１はINVITEメッセージ２７のような要求メッセージを予約されたリソース１３へと送信する。するとそれに応答して、リソース１３は200 OKメッセージ２８のような承認をユーザー・エージェント１１に送信する。サーバー１２とリソース１３は互いに通信することが可能である。それでサーバーはリソースがユーザーから得た認証情報を手に入れることができ、それによって個々のユーザーは会議に参加する前に認証を受けることができる。例えば、あるユーザーが会議に参加が可能になる申し込みをしているか否かを確認することは望ましいであろう。申し込みの詳細は認証情報に含まれることができる。その他、又は上記に加え、セキュリティ上の理由で彼の識別情報を確認するため、ユーザーはリソース１３への送信にPINコードの入力を要求されるかもしれない。

メッセージ２８に続き、応答コード200 OK を持つNOTIFYメッセージ２９のような承認が、ユーザー・エージェント１１からユーザー・エージェント１０へと送信され、会議が開始するだろう。

明らかなように、ユーザー・エージェント１０は、他のたくさんのユーザーが会議に参加できるように、彼らにダイナミックURIを送信したり教えたりすることができる。他の変形としては、REFERメッセージ２５が会議URIに向けられることができる。言い換えれば、ユーザーBが会議のことを照会するのではなく、会議がユーザーBに照会するようにすることができる。上記と同じセットのメッセージが用いられることができるが、この場合はダイヤルアウト・セマンティックと共に用いられる。

本発明の好適な実施態様に従って会議をセットアップするために必要なメッセージは「符号の説明」にまとめられている。

上に説明されたメカニズムはまた、ダイヤルイン会議通話を容易にすることができる。ダイヤルインの場合も、URIが参加予定者に異なる方法で届けられるだろうことを除けば、このメカニズムは結局のところ上記と同じように機能することができる。届ける方法は、REFERメッセージによる招待よりも、例えばインスタントメッセージやＥメールによるだろう。

出願人は次のような事実に注目する。即ち、本発明は、ここに暗示的に若しくは明示的に開示された如何なる特徴も、これらの組み合わせも、さらにこれらを一般化したものでも、上に述べられたどんな定義の範囲も制限することなく、包含しうるだろう。前述の説明を考慮すれば、本発明の範囲を逸脱することなく様々な変形が可能であることは、当業者ならば明らかである。

会議通話システムの先行モデルを示した図である。 先行技術のダイヤルイン会議通話システムを示した図である。 本発明に従う会議通話システムを示したものである。

符号の説明

２１ SIP:conferences@sonera.fiへのINVITEメッセージ
２２ ダイナミックURIを含む300番台のリダイレクト・メッセージ
２３ URIへのINVITEメッセージ
２４ 200 OK
２５ ユーザー・エージェント１１へのREFERメッセージ
２６ 202 accepted
２７ URIへのINVITEメッセージ
２８ 200 OK
２９ 応答コード“200 OK”を含むNOTIFYメッセージ

Claims (21)

1. 複数の端末と会議サーバーを有する通信システムにおいて会議通話を行なうリソースを管理する方法であって、
   会議通話を維持しうるリソースの要求を含む第１のメッセージを第１の端末から該サーバーへと送信するステップと、
   会議通話を維持しうるリソースのアドレスを識別するネットワークアドレスを該サーバーによって割り当てるステップと、
   該サーバーから該第１の端末へ該ネットワークアドレスを含む第２のメッセージを送信するステップと、
   前記会議通話が確立した後に、前記リソースが、該通話会議の参加者である前記端末の各々によってネットワークへ送信される音声データをまとめるステップと、
   を備える方法。
2. 前記ネットワークアドレスを含む第３のメッセージを前記第１の端末から少なくとも１つの他の端末へ送信するステップをさらに備える、請求項１に記載の方法。
3. 前記第１の端末と前記他の端末との間で会議通話を確立するために、該第１の端末及び該他の端末から前記ネットワークアドレスへ接続を着手するステップをさらに備える、請求項２に記載の方法。
4. 前記第３のメッセージを送信するステップが、前記第１の端末から少なくとも２つの他の端末へ前記ネットワークアドレスを含む第３のメッセージを送信することを含み、前記着手するステップが、該第１の端末と該少なくとも２つの他の端末との間で会議通話を確立するために該第１の端末及び該少なくとも２つの他の端末から該ネットワークアドレスへ接続を着手することを含む、請求項３に記載の方法。
5. 前記メッセージがSIPメッセージである請求項２に記載の方法。
6. 前記第１のメッセージはINVITEメッセージである請求項５に記載の方法。
7. 前記第２のメッセージはリダイレクト・メッセージである請求項５又は６に記載の方法。
8. 請求項５から７のいずれかに記載される方法であって、前記第３のメッセージはREFERメッセージである方法。
9. 前記ネットワークアドレスは、Uniform Resource Identifierである請求項１から８のいずれかに記載の方法。
10. 前記ネットワークアドレスは、動的に生成されるUniform Resource Identifierである請求項９に記載の方法。
11. 第１の端末を含む複数の端末を有する通信システムにおいて会議通話を行なうためのリソースと、前記リソースを管理する会議サーバーと備える通信システムであって、
    前記会議サーバーは、会議通話を維持しうるリソースの要求を含む第１のメッセージを前記第１の端末から受信する受信ユニットと、該会議通話を維持しうるリソースを識別するネットワークアドレスを割り当てる割り当てユニットと、該ネットワークアドレスを含む第２のメッセージを該第１の端末に送信する送信ユニットとを備え、
    前記リソースは、前記会議通話が確立すると、該通話会議の参加者である前記端末の各々によってネットワークへ送信される音声データをまとめるように構成される、
    通信システム。
12. 請求項１１に記載される通信システムであって、前記第１の端末は、前記ネットワークアドレスを含む第３のメッセージを、少なくとも１つの他の端末へ送信するように構成される、通信システム。
13. 請求項１２に記載される通信システムであって、前記第１の端末と前記他の端末は、該第１の端末と該他の端末との間で会議通話を確立するために、該第１の端末及び該他の端末から前記ネットワークアドレスへ接続を着手するように構成される、通信システム。
14. 請求項１３に記載される通信システムであって、前記第１の端末は、前記ネットワークアドレスを含む第３のメッセージを少なくとも２つの他の端末へ送信するように構成され、該第１の端末及び該少なくとも２つの他の端末は、該第１の端末と該少なくとも２つの他の端末との間で会議通話を確立するために該ネットワークアドレスへ接続を着手するように構成される、通信システム。
15. 前記メッセージがSIPメッセージである請求項１２に記載の通信システム。
16. 前記第１のメッセージはINVITEメッセージである請求項１５に記載の通信システム。
17. 前記第２のメッセージはリダイレクト・メッセージである請求項１５又は１６に記載の通信システム。
18. 請求項１５から１７のいずれかに記載される通信システムであって、前記第３のメッセージはREFERメッセージである通信システム。
19. 前記ネットワークアドレスは、Uniform Resource Identifierである請求項１１から１８のいずれかに記載の通信システム。
20. 前記ネットワークアドレスは、動的に生成されるUniform Resource Identifierである請求項１９に記載の通信システム。
21. 請求項１１〜２０の通信システムにおける会議サーバーであって、会議通話を維持しうるリソースの要求を含む第１のメッセージを前記第１の端末から受信する受信ユニットと、該会議通話を維持しうるリソースを識別するネットワークアドレスを割り当てる割り当てユニットと、該ネットワークアドレスを含む第２のメッセージを該第１の端末に送信する送信ユニットとを備える、会議サーバー。
    。