(57)【要約】複数の端末と会議サーバーを有する通信システムにおいて会議を行なうリソースを管理する方法であって、会議通話を維持しうるリソースの要求を含む第１のメッセージを第１の端末からサーバーへと送信するステップと、会議通話を維持しうるリソースのアドレスを識別するネットワークアドレスをサーバーによって割り当てるステップと、サーバーから第１の端末へ該ネットワークアドレスを含む第２のメッセージを送信するステップと、を備える方法。
2005536166.tif 000002
【特許請求の範囲】
【請求項１】
複数の端末と会議サーバーを有する通信システムにおいて会議を行なうリソースを管理する方法であって、会議通話を維持しうるリソースの要求を含む第１のメッセージを第１の端末から該サーバーへと送信するステップと、会議通話を維持しうるリソースのアドレスを識別するネットワークアドレスを該サーバーによって割り当てるステップと、該サーバーから該第１の端末へ該ネットワークアドレスを含む第２のメッセージを送信するステップと、を備える方法。
【請求項２】
前記ネットワークアドレスを含む第３のメッセージを前記第１の端末から少なくとも１つの他の端末へ送信するステップをさらに備える、請求項１に記載の方法。
【請求項３】
前記第１の端末と前記他の端末との間で会議通話を確立するために、該第１の端末及び該他の端末から前記ネットワークアドレスへ接続を着手するステップをさらに備える、請求項２に記載の方法。
【請求項４】
前記第３のメッセージを送信するステップが、前記第１の端末から少なくとも２つの他の端末へ前記ネットワークアドレスを含む第３のメッセージを送信することを含み、前記着手するステップが、該第１の端末と該少なくとも２つの他の端末との間で会議通話を確立するために該第１の端末及び該少なくとも２つの他の端末から該ネットワークアドレスへ接続を着手することを含む、請求項３に記載の方法。
【請求項５】
前記メッセージがSIPメッセージである請求項１から４のいずれかに記載の方法。
【請求項６】
前記第１のメッセージはINVITEメッセージである請求項５に記載の方法。
【請求項７】
前記第２のメッセージはリダイレクト・メッセージである請求項５又は６に記載の方法。
【請求項８】
請求項２に記載されると共に請求項５から７に記載される方法であって、前記第３のメッセージはREFERメッセージである方法。
【請求項９】
前記ネットワークアドレスは、Uniform Resource Identifierである請求項１から８のいずれかに記載の方法。
【請求項１０】
前記ネットワークアドレスは、動的に生成されるUniform Resource
Identifierである請求項９に記載の方法。
【請求項１１】
前記会議通話の確立において、前記リソースは、該通話会議の参加者である前記端末の各々によってネットワークへ送信されるデータをまとめる、請求項１から１０のいずれかに記載の方法。
【請求項１２】
複数の端末を有する通信システムにおいて会議を行なうためのリソースを管理する会議サーバーであって、会議通話を維持しうるリソースの要求を含む第１のメッセージを第１の端末から受信する受信ユニットと、該会議通話を維持しうるリソースを識別するネットワークアドレスを割り当てる割り当てユニットと、該ネットワークアドレスを含む第２のメッセージを該第１の端末に送信する送信ユニットと、を備える会議サーバー。
【請求項１３】
請求項１２に記載される会議サーバーを備える通信システムであって、複数の端末に前記第１の端末を含む通信システム。
【請求項１４】
請求項１３に記載される通信システムであって、前記第１の端末は、前記ネットワークアドレスを含む第３のメッセージを、少なくとも１つの他の端末へ送信するように構成される、通信システム。
【請求項１５】
請求項１４に記載される通信システムであって、前記第１の端末と前記他の端末は、該第１の端末と該他の端末との間で会議通話を確立するために、該第１の端末及び該他の端末から前記ネットワークアドレスへ接続を着手するように構成される、通信システム。
【請求項１６】
請求項１５に記載される通信システムであって、前記第１の端末は、前記ネットワークアドレスを含む第３のメッセージを少なくとも２つの他の端末へ送信するように構成され、該第１の端末及び該少なくとも２つの他の端末は、該第１の端末と該少なくとも２つの他の端末との間で会議通話を確立するために該ネットワークアドレスへ接続を着手するように構成される、通信システム。
【請求項１７】
前記メッセージがSIPメッセージである請求項１３から１６のいずれかに記載の通信システム。
【請求項１８】
前記第１のメッセージはINVITEメッセージである請求項１７に記載の通信システム。
【請求項１９】
前記第２のメッセージはリダイレクト・メッセージである請求項１７又は１８に記載の通信システム。
【請求項２０】
請求項１４に記載されると共に請求項１７から１９記載される通信システムであって、前記第３のメッセージはREFERメッセージである通信システム。
【請求項２１】
前記ネットワークアドレスは、Uniform Resource Identifierである請求項１３から２０のいずれかに記載の通信システム。
【請求項２２】
前記ネットワークアドレスは、動的に生成されるUniform Resource Identifierである請求項２１に記載の通信システム。
【請求項２３】
前記会議通話の確立において、前記リソースは、該通話会議の参加者である前記端末の各々によってネットワークへ送信されるデータをまとめるように構成される、請求項１３から２２のいずれかに記載の通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムにおいて会議通話をセットアップする方法や装置に関し、特に限定するわけではないが、ことに無線通信システムに関係する。
【背景技術】
【０００２】
会議通話のコンセプトは公衆交換電話網（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メッセージ
【図１】
2005536166.tif 000003
【図２】
2005536166.tif 000004
【図３】
2005536166.tif 000005
【国際調査報告】
2005536166.tif 000006
2005536166.tif 000007
2005536166.tif 000008