既存のコールにSIP通信デバイスを参加させるための方法
実施形態の例は、SIP通信デバイスを既存のコールに参加させることができる方法および/またはネットワーク要素を提供している。一例の実施形態によれば、ネットワーク要素(115)は、コールを行っている通信デバイスからの着信コールを受信するステップ(S100)と、関連する通信デバイスの組の中の、コールを行っている通信デバイスと、少なくとも1つの関連する通信デバイスとの間で接続を確立するステップ(S300)とにより、SIP通信デバイスを参加させることができる。関連する通信デバイスの組は、その接続について通知されること(S400)が可能であり、また会議プロシージャは、多方向会議接続が、コールを行っている通信デバイスと、少なくとも1つの関連する通信デバイスと、少なくとも1つの接続されていなかった通信デバイスとの間で確立されるように、接続されていなかった通信デバイスがアクティブにされるのに応じて実行されること(S500)が、可能である。
【発明の詳細な説明】
【背景技術】
【0001】
本発明は、既存のコールにSIP通信デバイスを参加させるための方法に関する。
【技術分野】
【0002】
従来のインターネット・プロトコル・マルチメディア・サブシステム(Internet Protocol Multimedia Subsystem)(IMS)ネットワークは、インターネット・プロトコル(Internet Protocol)(IP)サービスを配信するためのアーキテクチャ・フレームワーク(architectural framework)である。従来のIMSネットワークは、シグナリング・プロトコル(signaling protocol)を実装して、様々な形態の通信を確立し、修正し、かつ/または終了することができる。1タイプのシグナリング・プロトコルは、セッション開始プロトコル(Session Initiation Protocol)(SIP)とすることができる。
【0003】
従来のIMS/SIPネットワークにおいては、1組のユーザ装置(user equipments)(UE)は、SIPを使用し、また共用の電話番号を有することができる。共用の電話番号を有する従来のUEの組のうちのそれぞれを区別するために、従来のUEの組は、登録プロシージャに着手することもできる。登録プロシージャにより、各UEは、固有の連絡アドレスを割り当てられることができるようになる可能性がある。従来のUEの組が同時に鳴るように、共用の電話番号に対して着信コールが存在するときに、従来のIMS/SIPネットワークにおけるネットワーク要素は、固有の連絡アドレスを使用して、従来の各UEに対して招待要求(INVITE request)を送信することができる。これにより、加入者は、従来のUEのうちの任意のUEにおいて、その着信コールに応答することができるようになる。
【0004】
それにもかかわらず、従来のIMS/SIPネットワークの欠点は、両方の従来のUEが共用の電話番号を有するという事実にもかかわらず、ひとたび着信コールが、第1の従来のUEにおいて第1の人によって応答された後には、第2の人は、第2の従来のUEを単にピックアップして、コールに参加することができないということである。その代わりに、第2の人は、第2の従来のUEからの特別なアクセス・コードをダイアルして、コールに参加しなければならない。この欠陥は、伝統的な公衆交換電話網(Public Switched Telephone Network)(PSTN)電話サービスと対照をなしており、この公衆交換電話網電話サービスの場合には、第2の人は、共用の電話番号を有する他の任意の電話においてハンドセットをピックアップして、直ちにコールに参加することができる。従来のIMS/SIPネットワークにおける電話技術デバイスによるオペレーションにおけるそのような違いは、PSTNからVoIPへと移行するときにフィーチャー・トランスペアレンシー(feature transparency)を期待する電気通信プロバイダとエンド・ユーザとにより、致命的な欠陥と見なされてしまう可能性がある。
【発明の概要】
【課題を解決するための手段】
【0005】
実施形態の例は、SIP通信デバイスを既存のコールに参加させることができる方法および/またはネットワーク要素を提供している。一例の実施形態によれば、ネットワーク要素は、コールを行っている通信デバイスからの着信コールを受信すること、および関連する通信デバイスの組の中の、コールを行っている通信デバイスと、少なくとも1つの関連する通信デバイスとの間で接続を確立することにより、SIP通信デバイスを参加させることができる。関連する通信デバイスの組は、その接続について通知されることが可能であり、また会議プロシージャは、多方向の会議接続が、コールを行っている通信デバイスと、少なくとも1つの関連する通信デバイスと、少なくとも1つの接続されていなかった通信デバイスとの間で確立されるように、接続されていなかった通信デバイスがアクティブにされるのに応じて実行されることが可能である。
【0006】
さらなる実施形態の例によれば、通知装置は、アプリケーション・サーバを含むことができる。アプリケーション・サーバは、コールを行っている通信デバイスからの着信コールを受信すること、関連する通信デバイスの組の中の、コールを行っている通信デバイスと、少なくとも1つの関連する通信デバイスとの間で接続を確立すること、その接続について少なくとも1つの接続されていなかった通信デバイスに通知すること、多方向の会議接続が、コールを行っている通信デバイスと、少なくとも1つの関連する通信デバイスと、少なくとも1つの接続されていなかった通信デバイスとの間で確立されるように、接続されていなかった通信デバイスがアクティブにされるのに応じて会議プロシージャを実行すること、および共用の回線が使用可能であるときに、関連する通信デバイスの組のうちのそれぞれにアイドル通知を送信することを行うように構成されることが可能である。
【0007】
添付の図面は、実施形態の例についてのさらなる理解を提供するために含められ、また本明細書に組み込まれ、また本明細書の一部分を構成する。
【図面の簡単な説明】
【0008】
【図1】一例の実施形態によるIMSネットワークを示す図である。
【図2】一例の実施形態による、既存のコールにSIP通信デバイスを参加させる方法を示す図である。
【図3】一例の実施形態による、図2のステップS100をさらに定義する信号フロー図である。
【図4】一例の実施形態による、図2のステップS200をさらに定義する信号フロー図である。
【図5】一例の実施形態による、図2のステップS300をさらに定義する信号フロー図である。
【図6】一例の実施形態による、図2のステップS400をさらに定義する信号フロー図である。
【図7A】一例の実施形態による、図2のステップS500をさらに定義する信号フロー図である。
【図7B】一例の実施形態による、図2のステップS500をさらに定義する信号フロー図である。
【図8A】一例の実施形態による、図2のステップS600をさらに定義する信号フロー図である。
【図8B】一例の実施形態による、図2のステップS600をさらに定義する信号フロー図である。
【図9】一例の実施形態による、図2のステップS700をさらに定義する信号フロー図である。
【発明を実施するための形態】
【0009】
以下の説明においては、説明の目的のために、また限定しない目的のために、実施形態の例の完全な理解を提供するために、特定のアーキテクチャ、インターフェース、技法など、特定の詳細が、説明される。しかしながら、開示された主題は、これらの特定の詳細を逸脱した他の例示の実施形態の中で実行されることが可能であることが当業者には明らかであろう。いくつかの例においては、よく知られているデバイスおよび/または方法の詳細な説明は、不必要な詳細を有する説明をあいまいにしないように省略される。すべての原理、態様、および実施形態、ならびにその特定の例は、本開示の主題についての構造的な同等物と、機能的な同等物との両方を包含するように意図される。さらに、そのような同等物は、現在知られている同等物と、同様に将来において開発される同等物との両方を含むことも、意図される。
【0010】
第1、第2などの用語を本明細書において使用して、様々な要素を説明することができるが、これらの要素は、これらの用語によって限定されるべきでないことが、理解されるであろう。これらの用語を使用して、ある要素を別の要素から区別するだけである。例えば、実施形態の例の範囲を逸脱することなく、第1の要素は、第2の要素と名づけられることが可能であり、また同様に、第2の要素は、第1の要素と名づけられることも可能である。本明細書において使用されるように、用語「および/または(and/or)」は、関連するリストアップされたアイテムのうちの任意のものと、関連するリストアップされたアイテムのうちの1つまたは複数についてのすべての組合せとを含む。
【0011】
いくつかの代替的実装形態においては、指摘される機能/動作は、図面の中で指摘される順序から外れて起こり得ることにも注意すべきである。例えば、連続して示される2つの図は、実際には、実質的に同時に実行されることが可能であり、または時には、関与する機能/動作に応じて逆の順序で実行されることも可能である。
【0012】
本明細書において使用されるように、用語「ユーザ装置(UE)」は、モバイル・ユーザ、ユーザ、加入者、ワイヤレス端末、および/またはリモート局に対する同義語とすることができ、またワイヤレス通信ネットワークにおけるワイヤレス・リソースのリモート・ユーザを説明することができる。
【0013】
以下の説明は、3GPP技術および/または関連技術に基づいたネットワークに関する。しかしながら、本明細書において示され、また説明される実施形態の例は、例示的にすぎず、またいかなる形でも限定することがないように意図されていることに注意すべきである。したがって、様々な修正は、上記以外の技術に基づいた通信システムまたはネットワークに対するアプリケーションについて、当業者には明らかになり、これらの技術は、開発の様々な段階にあり、また上記のネットワークまたはシステムについての将来の置き換え、あるいは上記のネットワークまたはシステムを伴う使用のために意図される可能性がある。
【0014】
現在のネットワーク・アーキテクチャは、モバイル/ユーザ・デバイスと、アクセス・ポイント/基地局との間の区別を考慮することができるが、以降に説明される実施形態の例は、例えば、アド・ホック・アーキテクチャ(ad hoc architecture)および/またはメッシュ・ネットワーク・アーキテクチャなど、その区別がそれほど明確でない場合のアーキテクチャに対して一般的に適用可能とすることができる。
【0015】
図1は、一例の実施形態によるIMSネットワーク100を示すものである。例示の目的のために、図1は、3つのUE(101、103、および105)を含んでいる。第1のユーザ装置(UE−1 101)は、コールを行っている通信デバイスとすることができるのに対して、第2のユーザ装置(UE−2 103)と、第3のユーザ装置(UE−3 105)とは、共用の識別子によって互いに関連づけられることが可能である。共用の識別子は、それだけには限定されないが、共用の電話番号および/または共用のユニフォーム・リソース・アイデンティファイア(Uniform Resource Identifier)(URI)フィールドとすることができる。関連するUE(UE−2 103およびUE−3 105)は、それぞれ個別にIMSネットワーク100に登録することができる。
【0016】
それらのUEは、SIPを使用して、コール・セッション制御機能(Call Session Control Function)(CSCF)109と通信する。CSCF109は、IMSネットワーク100においてSIPシグナリング・パケットを処理するために使用されるSIPのサーバおよび/またはプロキシの集まりとすることができる。CSCFは、プロキシ−CSCF(P−CSCF)と、サービング−CSCF(S−CSCF)と、問い合わせ−CSCF(I−CSCF)とを含むことができる。P−CSCFは、連絡の第1のポイントとすることができる。IMSネットワーク100においてUEによって送信されるメッセージおよび/または受信されるメッセージは、P−CSCFを通して伝搬する。S−CSCFは、SIPシグナリング・プレーンにおける中心ノードとすることができる。I−CSCFは、問い合わせ機能とすることができる。着信コール(例えば、SIP招待要求(SIP INVITE requests))は、I−CSCFを通して伝搬する。簡単にするために、S−CSCFだけが、より詳細に考察されることになる。IMSネットワーク100において、CSCF109は、S−CSCF111を含んでいる。S−CSCF111とのUEの通信は、下記でさらに考察される。
【0017】
UEと、S−CSCF111との間の通信は、様々なネットワーク要素107を横切る。しかしながら、様々なネットワーク要素107を構成する各中間要素は、明確さを向上するために示されてはいない。様々なネットワーク要素107は、それだけには限定されないが、(i)アクセス・ネットワーク(例えば、デジタル加入者回線アクセス・マルチプレクサなど)と、(ii)ゲートウェイ(例えば、境界ゲートウェイ、IMSゲートウェイ、シグナリング・ゲートウェイ、メディア・ゲートウェイなど)と、(iii)他の任意の中間のIMS要素(ネットワーク・アタッチメント・サブシステム(Network Attachment Subsystem)、オートメーション構築システム(Building Automation System)、アクセス・リソースおよびアドミッション機能、ポリシー決定機能、サービス・ベースのポリシー決定機能など)とを含むことができる。
【0018】
S−CSCF111は、SIPを利用して、アプリケーション・サーバ(AS)115と、メディア・リソース機能(Media Resource Function)(MRF)113と通信する。AS115は、UEに対して提供される様々なサービスを実行するSIPエンティティとすることができる。AS115はまた、関連するUE(UE−2 103およびUE−3 105)が、共用の識別子を有することを知っていることもできる。AS115は、関連するUEが、IMSネットワーク100に登録する場合に、またはそのときに、この事実を知るようになることができる。他方、MRF113は、メディアに関連した機能(例えば、多方向会議接続、メディア操作、アナウンスメントなど)を提供することができる。MRF113は、メディア・リソース機能コントローラ(Media Resource Function Controller)(MRFC)と、メディア・リソース機能プロセッサ(Media Resource Function Processor)(MRFP)とを含むことができる。MRFCは、S−CSCF111に対するSIPユーザ・エージェントとしての機能を果たすことができる。MRFPは、実際のメディアに関連した機能を実装することができる。
【0019】
図2は、一例の実施形態による、既存のコールにSIP通信デバイスを参加させる方法を示すものである。説明の目的のために、図2に説明される方法は、図1に示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけには限定されることはない。したがって、図1からの参照番号は、必ずしも図2において使用されるとは限らない。
【0020】
ステップS100において、コールを行っているUEからの着信コールが、受信される。コールは、ASによって受信されることが可能である。ひとたび、コールが受信された後に、関連するUEは、ステップS200を通じて、着信コールが、到着していることを警告される。次に、ステップS300において、コールを行っているUEと、少なくとも1つの関連するUEとの間の接続が、確立される。ステップS300は、接続されていなかった関連するUEとのコール・セッションを終了することを含むこともできる。ひとたび、接続が確立された後に、関連するUEは、ステップS400を通じて接続について通知される。ステップS500において、会議プロシージャは、接続されていなかったUEがアクティブにされるのに応じて、実行される。会議プロシージャは、コールを行っているUEと、関連する少なくとも1つの接続されたUEと、最初に接続されていなかったUEとを多方向会議コールに自動的に追加することができる。多方向会議コールが、終了するときに、コールは、ステップS600を通じて終了されることが可能である。最後に、ステップS700において、関連するUEは、もう一度、回線がアイドル状態であることを通知される。
【0021】
図3は、一例の実施形態による、図2のステップS100をさらに定義する信号フロー図である。説明の目的のために、図3において説明される方法は、図1に示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけには限定されてはいない。したがって、図1からの参照番号は、必ずしも図3において使用されるとは限らない。
【0022】
図3において、コールを行っているUE(UE−1)は、ステップS101において招待要求をS−CSCFに対して送信する。招待要求は、着信コールとすることができる。招待要求の宛先アドレスは、共用の識別子とすることができる。次に、ステップS103において、S−CSCFは、招待要求をASに対して転送する。図1を考察するときに上記で示されるように、共用の識別子を有する関連するUE(UE−2およびUE−3)は、ASに登録することができる。したがって、関連するUEのそれぞれは、固有公共識別情報(unique public identity)を割り当てられることが可能である。固有公共識別情報はまた、URIフィールドとすることもできる。それに応じて、ステップS105において、ASは、関連するUE−2によって受信されるように意図されるS−CSCFに対して招待要求を転送することができる。招待要求は、UE−2に対応する固有公共識別情報を含むことができる。S−CSCFは、招待要求が、固有公共識別情報に基づいてUE−2に進むように意図されることを知っていることができる。それゆえに、S−CSCFは、ステップS107を通じて、招待要求を関連するUE−2に対して転送する。同様に、ステップS109において、ASは、関連するUE−3要求に対応する固有公共識別情報を含む招待要求をS−CSCFに対して転送する。S−CSCFは、ステップS111を通じて、招待要求を関連するUE−3に対して転送する。ステップS105、S107、S109、およびS111は、同時に実行され得ることに注意すべきである。また、次いで、ASは、関連するUE(UE−2およびUE−3)に送信される顕著な招待要求を追跡することができる。
【0023】
図4は、一例の実施形態による、図2のステップS200をさらに定義する信号フロー図である。説明の目的のために、図4において説明される方法は、図1に示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけには限定されていない。したがって、図1からの参照番号は、必ずしも図4において使用されるとは限らない。
【0024】
ひとたび、関連するUEが、図3において上記で考察されるように招待要求を受信した後に、関連するUEは、リンギング警報(ringing alerts)をASに対して送信することができる。より詳細には、関連するUE−2は、ステップS201において、リンギング警報をS−CSCFに対して送信する。S−CSCFは、このリンギング警報をASに対して転送する。ひとたび、ASによって受信された後に、ASは、ステップS205に示されるように、関連するUE−2のリンギング警報をS−CSCFに対して転送する。ASによって転送されるリンギング警報は、ステップS207を通じて、コールを行っているUE−1によって受信されるように意図される。次いで、このプロセスは、関連するUE−3に関して反復されることが可能である。より詳細には、ステップS209において、関連するUE−3は、それ自体のリンギング・アナウンスメントをS−CSCFに対して送信する。リンギング・アナウンスメントは、ステップS211を通じて、S−CSCFからASへと転送される。次いで、ASは、リンギング・アナウンスメントをUE−1(図示されず)へと転送することができる。
【0025】
図5は、一例の実施形態による、図2のステップS300をさらに定義する信号フロー図である。説明の目的のために、図5において説明される方法は、図1に示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけには限定されていない。したがって、図1からの参照番号は、必ずしも図5において使用されるとは限らない。
【0026】
最終的には、リンギング警報が、関連するUEによって送信された後に、加入者は、少なくとも1つの関連するUEをアクティブにする(例えば、コールに応答する)ことになる。ステップS301において、関連するUE−2は、コールに応答し、また応答確認をS−CSCFに対して送信する。図5において、応答確認は、「OK」メッセージである。OKメッセージは、ストリーミング・メディア初期化パラメータ(例えば、セッション記述プロトコル応答(Session Description Protocol answer)を記述するためのフォーマットにおける応答を含むことができる。S−CSCFは、ステップS303において、OKメッセージをASに対して転送する。ステップS305において、ASは、UE−2識別子を有するOKメッセージをS−CSCFに対して転送する。UE−2識別子は、UE−2からのSDP応答を含むことができる。ステップS307において、S−CSCFは、UE−2識別子と一緒に、OKメッセージをUE−1に対して転送する。上記で述べられるように、UE−1は、コールを行っているUEである。それに応じて、UE−1と、UE−2との間の接続が、ステップS309を通じて、その後に確立される。
【0027】
また、関連するUE−3(接続されていなかった関連するUE)を伴うコール・セッションも終了されることが可能である。より詳細には、ASは、接続されていなかった関連するUE−3を伴う顕著な招待(INVITE)をキャンセルすることができる。ステップS311において、ASは、キャンセル・メッセージ(cancellation message)をS−CSCFに対して送信する。キャンセル・メッセージは、SIPキャンセル・メッセージ(SIP CANCEL message)とすることができる。キャンセル・メッセージは、ステップ313において、S−CSCFによりUE−3に対して転送される。それに応じて、接続されていなかった関連するUE−3は、ステップS315を通じて、キャンセルの肯定応答(ACK)をS−CSCFに対して返信する。キャンセルの肯定応答は、SIP OKキャンセル・メッセージ(SIP OK CANCEL message)とすることができる。S−CSCFは、ステップS317においてキャンセルをASに対して転送する。また、接続されていなかった関連するUE−3は、ステップS319を通じて、同様にセッション終了メッセージ(session termination message)をS−CSCFに対して送信する。セッション終了メッセージは、顕著な招待に対応するセッションが、終了されることを確認することができる。ステップS321において、S−CSCFは、セッション終了メッセージをASに対して転送する。次いで、ASは、ACKをS−CSCFに対して返信すること(ステップS323)によって応答し、S−CSCFは、このACKを接続されていなかった関連するUE−3に対して転送する(ステップS325)。図6は、一例の実施形態による、図2のステップS400をさらに定義する信号フロー図である。説明の目的のために、図6に説明される方法は、図1に示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけには限定されていない。したがって、図1からの参照番号は、必ずしも図6において使用されるとは限らない。
【0028】
ひとたび、コールが、図5を通じて応答された後に、ASは、コールを行っているUE−1と、関連するUE−2との間の接続についてすべての関連するUEに通知することができる。図6は、この通知するプロシージャを示すものである。より詳細には、ステップS401において、ASは、コール通知メッセージ(call notification message)をS−CSCFに対して送信する。コール通知メッセージは、SIP通知要求(SIP NOTIFY request)とすることができる。コール通知メッセージは、回線が、込んでおり、かつ/またはアクティブであることを加入者に通知するために、接続されていなかったUE−3によって使用されることも可能である。例えば、コール通知メッセージを使用して、従来のPSTN電話に類似した光源および/または何らかの他のコンピュータ化された形態の加入者通知(例えば、「使用中」の光、または「コールが進行中」の光)をアクティブにすることができる。
【0029】
ステップS403において、S−CSCFは、コール通知メッセージを接続されていなかった関連するUE−3に対して転送する。しかしながら、ASは、コール通知メッセージを接続された関連するUE−2(図示されず)に対して転送することもできる。それに応じて、ステップS405において、接続されていなかったUE−3は、確認OK通知メッセージ(confirmation OK NOTIFY message)をS−CSCFに対して送信する。S−CSCFは、ステップS407を通じて、OK通知メッセージをASに対して転送する。
【0030】
図7A〜7Bは、一例の実施形態による、図2のステップS500をさらに定義する信号フロー図である。説明の目的のために、図7A〜7Bにおいて説明される方法は、図1において説明されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけに限定されていない。したがって、図1からの参照番号は、必ずしも図7A〜7Bにおいて使用されるとは限らない。
【0031】
ひとたび、接続されていなかったUE−3が、コール通知メッセージを受信した後に、接続されていなかったUE−3は、アクティブにされることが可能である(例えば、ユーザは、UE−3のハンドセットをピックアップする)。会議プロシージャは、UE−3がアクティブにされた後に、自動的に開始されることが可能である。図7Aにおいて、ステップS501は、接続されていなかったUE−3によりS−CSCFに対して送信されている参加コール要求(join call request)を示している。参加コール要求は、ユーザおよび/または加入者によってピックアップされているUE−3に応じて送信される。参加コール要求は、SIP招待要求とすることができる。また、SIP招待要求は、SIP URIフィールドの中に特別な値を含むこともできる。次いで、S−CSCFは、ステップS503において、参加コール要求をASに対して転送する。
【0032】
ASが、参加コール要求を受信する場合、またはそのときに、ASは、コールを行っているUE−1と、共用の識別子を有するすべての関連するUEとを参加させる会議プロシージャをアクティブにすることができる。会議は、すべてのパーティが、参加させられ得るような多方向会議接続とすることができる。パーティは、MRFを使用して参加させられることが可能である。図7AのステップS505において、招待メッセージは、ASからMRFへと送信される。招待メッセージは、UE−3識別子を有する、会議接続に参入すべき提案を含んでいる。その提案は、UE−3からのSDP提案とすることができる。MRFは、招待メッセージの確認を送信することにより応答することができる。図7Aにおいて、確認は、ステップS507を通じて、ASに対して送信されるOK招待メッセージ(OK INVITE message)である。OK招待は、MRFからのSDP応答を含むことができる。次に、ステップS509において、ASは、MRFからS−CSCFへとOK招待を転送する。S−CSCFは、ステップS511を通じて、OK招待を接続されていなかった関連するUE−3に対して転送する。接続されていなかった関連するUE−3は、ACKをS−CSCFに対して返信すること(ステップS513)により応答し、次いでこのACKは、ASに対して転送される(ステップS515)。ステップS517において、ASは、ACKをMRFに対して転送する。その結果として、以前には接続されていなかったUE−3は、今や、ステップS519を通じて、多方向会議接続に参加させられる。
【0033】
次に、コールを行っているUE−1と、接続された関連するUE−2とはまた、図7Bに示されるように、多方向会議接続に参加させられることも可能である。より詳細には、ASは、ステップS521を通じて、再招待メッセージ(REINVITE message)をS−CSCFに対して送信する。再招待メッセージは、SDPメッセージを含んでいなくてもよい。ステップS523において、S−CSCFは、再招待メッセージを接続された関連するUE−2に対して転送する。UE−2は、再招待メッセージの確認を送信することにより応答することができる。図7Bにおいて、確認は、ステップS525に示されるように、S−CSCFに対して送信されるOK再招待メッセージ(OK REINVITE message)である。OK再招待は、SDP提案を含むことができる。次いで、S−CSCFは、ステップS527を通じて、OK再招待をASに対して転送する。次に、ステップS529において、ASは、接続された関連するUE−2からの提案を有する招待メッセージをMRFに対して送信する。MRFは、ステップS531に示されるように、ASに対して送信されるOK招待メッセージを用いて応答することにより招待を確認する。その後に、ASは、ACKをS−CSCFに対して送信し(ステップS533)、このACKは、S−CSCFにより、接続された関連するUE−2に対して転送される(ステップS535)。ASはまた、ステップS537を通じて、ACKをMRFに対して送信する。このようにして、接続された関連するUE−2はまた、ステップS539に示されるように、以前には接続されていなかった関連するUE−3と一緒に、多方向会議接続に参加させられる。
【0034】
コールを行っているUE−1は、接続された関連するUE−2の方法と同じ方法で、多方向会議接続に参加させられることが可能である。ステップS541において、ASは、再招待メッセージをS−CSCFに対して送信し、この再招待メッセージは、その後にステップS543において、S−CSCFにより、コールを行っているUE−1に対して転送される。再招待メッセージは、SDPメッセージを含んでいなくてもよい。再招待メッセージの受信のすぐ後に、コールを行っているUE−1は、OK再招待メッセージをS−CSCFに対して送信すること(ステップS545)によって応答し、このOK再招待メッセージは、S−CSCFによりASに対して転送される(ステップS547)。次に、ステップS549において、ASは、コールを行っているUE−1からの提案を有する招待メッセージをMRFに対して送信する。MRFは、ステップS551に示されるようにASに対して送信されるOK招待メッセージを用いて応答することにより招待を確認する。ASは、ACKをS−CSCFに対して送信し(ステップS553)、このACKは、S−CSCFにより、接続された関連するUE−2に対して転送される(ステップS555)。ASはまた、ステップS557を通じて、ACKをMRFに対して送信する。このようにして、コールを行っているUE−1はまた、ステップS559に示されるように、接続された関連するUE−2と、以前には接続されていなかった関連するUE−3と一緒に多方向会議接続に参加させられる。
【0035】
図8A〜8Bは、一例の実施形態による、図2のステップS600をさらに定義する信号フロー図である。説明の目的のために、図8A〜8Bにおいて説明される方法は、図1において示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけに限定されていない。したがって、図1からの参照番号は、必ずしも図8A〜8Bにおいて使用されるとは限らない。
【0036】
上記に説明される多方向会議接続の終了時に、次いで多方向会議接続は、終了されることが可能である。関連するUEのそれぞれは、同時に、または異なる間隔で接続を切ることができる。例えば、接続されたUE−2は、多方向会議接続からの接続を切ることができるが、コールを行っているUE−1と、以前には接続されていなかったUE−3とは、多方向会議接続に留まることができる。代替的な一実施形態においては、コールを行っているUE−1と、以前には接続されていなかったUE−3とは、接続されたUE−2が、接続を切るときに多方向会議接続以外の接続に対して転送されることも可能である。
【0037】
図8Aは、コールを行っているUE−1と、以前には接続されていなかったUE−3とが、多方向会議接続の中に留まる間に、多方向会議接続からの接続を切る、接続されたUE−2についての一例の実施形態を示している。より詳細には、接続された関連するUE−2(今や終了しようとしている関連するUE−2)は、受話器を置き、ステップS601に示されるように、さようならメッセージ(BYE message)が、関連するUE−2からS−CSCFへと送信されるようにしている。ステップS603において、S−CSCFは、さようならメッセージをASに対して転送する。ASは、終了しようとしている関連するUE−2が、多方向会議接続からの接続を切るように意図していることを通知されて、ステップS605に示されるように、さようならメッセージをMRFに対して転送する。さようならメッセージは、終了しようとしている関連するUE−2に対応する情報を含むことができる。図8Aにおいて、対応する情報は、終了しようとしている関連するUE−2からMRFへのダイアログ(dialog)である。MRFは、ステップS607において、確認OKさようならメッセージ(confirmation OK BYE message)をASに対して送信することにより、応答し、ASは、ステップS609においてこの確認OKさようならメッセージをS−CSCFに対して転送する。S−CSCFは、ステップS611において、同様に、終了しようとしている関連するUE−2に対して確認OKさようならメッセージを転送する。確認OKさようならメッセージの受信のすぐ後に、終了しようとしている関連するUE−2は、ステップS613に示されるように、コールを行っているUE−1と、以前には接続されていなかった関連するUE−3とだけが、多方向会議接続に留まるように、多方向会議接続からの接続を切られる。それに応じて、多方向会議接続は依然として存在するので、すべての接続されていなかった関連するUEは、依然として回線がアクティブのままであることを通知されることが可能である。
【0038】
最終的に、多方向会議接続は、多方向会議接続の中の残りのUEによって完全に終了させられることが可能である。図8Bにおいて、以前には接続されていなかったUE−3(今や終了しようとしている関連するUE−3)は、ステップ615において、受話器を置き、さようならメッセージが、S−CSCFに対して送信されるようにしている。S−CSCFは、ステップS617に示されるように、さようならメッセージをASに対して転送する。次いで、ASは、ステップS619に示されるように、終了しようとしている関連するUE−3からのダイアログと一緒に、さようならメッセージをMRFに対して転送する。MRFは、ステップS621において、確認OKさようならメッセージをASに対して送信することによって応答し、ASは、ステップS623において、この確認OKさようならメッセージをS−CSCFに対して転送する。S−CSCFは、ステップS627において、同様に、終了しようとしている関連するUE−3に対して確認OKさようならメッセージを転送する。確認OKさようならメッセージの受信のすぐ後に、終了しようとしている関連するUE−3は、ステップS629に示されるように多方向会議接続からの接続を切られる。
【0039】
コールを行っているUE−1は、上記に説明される終了しようとしている関連するUEと同様なやり方で、多方向会議接続からの接続を切られることが可能である。しかしながら、コールを行っているUE−1は、多方向会議接続において最後に残っているUEであるので、ASは、終了プロセスを開始することができる。より詳細には、ASは、ステップS631に示されるように、コールを行っているUE−1からのダイアログを有するさようならメッセージをMRFに対して送信する。MRFは、ステップS633において、確認OKさようならメッセージをASに対して送信することによって応答する。ASは、コールを行っているUE−1に関して、コール終了プロセスを開始したので、ステップS635において、ASは、S−CSCFに対してさようならメッセージを送信し、S−CSCFは、ステップS637において、コールを行っているUE−1に対してこのさようならメッセージを転送する。さようならメッセージの受信のすぐ後に、コールを行っているUE−1は、ステップS639において、それ自体の確認OKさようならメッセージをS−CSCFに対して送信し、S−CSCFは、ステップS643において、この確認OKさようならメッセージをASに対して転送する。コールを行っているUE−1はまた、ステップS641において、多方向会議接続が、終了されるように、多方向会議接続からの接続を切る。
【0040】
図9は、一例の実施形態による、図2のステップS700をさらに定義する信号フロー図である。説明の目的のために、図9において説明される方法は、図1に示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけに限定されていない。したがって、図1からの参照番号は、必ずしも図9において使用されるとは限らない。
【0041】
UE接続(例えば、多方向会議接続)が、切り離された後に、関連するUEは、共用の電話番号に対応する回線が、アイドル状態であることを通知されることが可能である。例えば、図9のステップS701において、ASは、回線−アイドル通知(line−idle notification)をS−CSCFに対して送信し、ステップS703において、S−CSCFは、この回線−アイドル通知を関連するUE−2に対して転送する。図8Aに関して上記で考察されるように、次いで、現在アイドル状態である関連するUE−2は、確認メッセージを用いて応答することができる。例えば、図9において、関連するUE−2は、ステップS705において、OK通知メッセージ(OK NOTIFY message)をS−CSCFに対して送信することによって応答する。次いで、S−CSCFは、ステップS707を通じて、OK通知メッセージをASに対して転送する。
【0042】
やはり現在はアイドル状態である関連するUE−3に通知する同じプロセスが、反復されることも可能である。より詳細には、ステップS709において、ASは、回線−アイドル通知をS−CSCFに対して送信し、ステップS711において、S−CSCFは、この回線−アイドル通知を関連するUE−3に対して転送する。ステップS713において、関連するUE−3は、OK通知メッセージをS−CSCFに対して送信することによって応答し、次いで、S−CSCFは、ステップS715を通じてこのOK通知メッセージをASに対して転送する。それに応じて、すべての関連するものは、共用の電話番号に対応する回線がアイドル状態であることを通知される。
【0043】
実施形態の例が、このようにして説明されており、同じことが、多数のやり方で変化させられ得ることが、明らかであろう。そのような、変形形態は、開示された主題からの逸脱と見なされるべきではなく、またすべてのそのような修正形態は、本開示の主題の範囲内に含められるように意図される。
【背景技術】
【0001】
本発明は、既存のコールにSIP通信デバイスを参加させるための方法に関する。
【技術分野】
【0002】
従来のインターネット・プロトコル・マルチメディア・サブシステム(Internet Protocol Multimedia Subsystem)(IMS)ネットワークは、インターネット・プロトコル(Internet Protocol)(IP)サービスを配信するためのアーキテクチャ・フレームワーク(architectural framework)である。従来のIMSネットワークは、シグナリング・プロトコル(signaling protocol)を実装して、様々な形態の通信を確立し、修正し、かつ/または終了することができる。1タイプのシグナリング・プロトコルは、セッション開始プロトコル(Session Initiation Protocol)(SIP)とすることができる。
【0003】
従来のIMS/SIPネットワークにおいては、1組のユーザ装置(user equipments)(UE)は、SIPを使用し、また共用の電話番号を有することができる。共用の電話番号を有する従来のUEの組のうちのそれぞれを区別するために、従来のUEの組は、登録プロシージャに着手することもできる。登録プロシージャにより、各UEは、固有の連絡アドレスを割り当てられることができるようになる可能性がある。従来のUEの組が同時に鳴るように、共用の電話番号に対して着信コールが存在するときに、従来のIMS/SIPネットワークにおけるネットワーク要素は、固有の連絡アドレスを使用して、従来の各UEに対して招待要求(INVITE request)を送信することができる。これにより、加入者は、従来のUEのうちの任意のUEにおいて、その着信コールに応答することができるようになる。
【0004】
それにもかかわらず、従来のIMS/SIPネットワークの欠点は、両方の従来のUEが共用の電話番号を有するという事実にもかかわらず、ひとたび着信コールが、第1の従来のUEにおいて第1の人によって応答された後には、第2の人は、第2の従来のUEを単にピックアップして、コールに参加することができないということである。その代わりに、第2の人は、第2の従来のUEからの特別なアクセス・コードをダイアルして、コールに参加しなければならない。この欠陥は、伝統的な公衆交換電話網(Public Switched Telephone Network)(PSTN)電話サービスと対照をなしており、この公衆交換電話網電話サービスの場合には、第2の人は、共用の電話番号を有する他の任意の電話においてハンドセットをピックアップして、直ちにコールに参加することができる。従来のIMS/SIPネットワークにおける電話技術デバイスによるオペレーションにおけるそのような違いは、PSTNからVoIPへと移行するときにフィーチャー・トランスペアレンシー(feature transparency)を期待する電気通信プロバイダとエンド・ユーザとにより、致命的な欠陥と見なされてしまう可能性がある。
【発明の概要】
【課題を解決するための手段】
【0005】
実施形態の例は、SIP通信デバイスを既存のコールに参加させることができる方法および/またはネットワーク要素を提供している。一例の実施形態によれば、ネットワーク要素は、コールを行っている通信デバイスからの着信コールを受信すること、および関連する通信デバイスの組の中の、コールを行っている通信デバイスと、少なくとも1つの関連する通信デバイスとの間で接続を確立することにより、SIP通信デバイスを参加させることができる。関連する通信デバイスの組は、その接続について通知されることが可能であり、また会議プロシージャは、多方向の会議接続が、コールを行っている通信デバイスと、少なくとも1つの関連する通信デバイスと、少なくとも1つの接続されていなかった通信デバイスとの間で確立されるように、接続されていなかった通信デバイスがアクティブにされるのに応じて実行されることが可能である。
【0006】
さらなる実施形態の例によれば、通知装置は、アプリケーション・サーバを含むことができる。アプリケーション・サーバは、コールを行っている通信デバイスからの着信コールを受信すること、関連する通信デバイスの組の中の、コールを行っている通信デバイスと、少なくとも1つの関連する通信デバイスとの間で接続を確立すること、その接続について少なくとも1つの接続されていなかった通信デバイスに通知すること、多方向の会議接続が、コールを行っている通信デバイスと、少なくとも1つの関連する通信デバイスと、少なくとも1つの接続されていなかった通信デバイスとの間で確立されるように、接続されていなかった通信デバイスがアクティブにされるのに応じて会議プロシージャを実行すること、および共用の回線が使用可能であるときに、関連する通信デバイスの組のうちのそれぞれにアイドル通知を送信することを行うように構成されることが可能である。
【0007】
添付の図面は、実施形態の例についてのさらなる理解を提供するために含められ、また本明細書に組み込まれ、また本明細書の一部分を構成する。
【図面の簡単な説明】
【0008】
【図1】一例の実施形態によるIMSネットワークを示す図である。
【図2】一例の実施形態による、既存のコールにSIP通信デバイスを参加させる方法を示す図である。
【図3】一例の実施形態による、図2のステップS100をさらに定義する信号フロー図である。
【図4】一例の実施形態による、図2のステップS200をさらに定義する信号フロー図である。
【図5】一例の実施形態による、図2のステップS300をさらに定義する信号フロー図である。
【図6】一例の実施形態による、図2のステップS400をさらに定義する信号フロー図である。
【図7A】一例の実施形態による、図2のステップS500をさらに定義する信号フロー図である。
【図7B】一例の実施形態による、図2のステップS500をさらに定義する信号フロー図である。
【図8A】一例の実施形態による、図2のステップS600をさらに定義する信号フロー図である。
【図8B】一例の実施形態による、図2のステップS600をさらに定義する信号フロー図である。
【図9】一例の実施形態による、図2のステップS700をさらに定義する信号フロー図である。
【発明を実施するための形態】
【0009】
以下の説明においては、説明の目的のために、また限定しない目的のために、実施形態の例の完全な理解を提供するために、特定のアーキテクチャ、インターフェース、技法など、特定の詳細が、説明される。しかしながら、開示された主題は、これらの特定の詳細を逸脱した他の例示の実施形態の中で実行されることが可能であることが当業者には明らかであろう。いくつかの例においては、よく知られているデバイスおよび/または方法の詳細な説明は、不必要な詳細を有する説明をあいまいにしないように省略される。すべての原理、態様、および実施形態、ならびにその特定の例は、本開示の主題についての構造的な同等物と、機能的な同等物との両方を包含するように意図される。さらに、そのような同等物は、現在知られている同等物と、同様に将来において開発される同等物との両方を含むことも、意図される。
【0010】
第1、第2などの用語を本明細書において使用して、様々な要素を説明することができるが、これらの要素は、これらの用語によって限定されるべきでないことが、理解されるであろう。これらの用語を使用して、ある要素を別の要素から区別するだけである。例えば、実施形態の例の範囲を逸脱することなく、第1の要素は、第2の要素と名づけられることが可能であり、また同様に、第2の要素は、第1の要素と名づけられることも可能である。本明細書において使用されるように、用語「および/または(and/or)」は、関連するリストアップされたアイテムのうちの任意のものと、関連するリストアップされたアイテムのうちの1つまたは複数についてのすべての組合せとを含む。
【0011】
いくつかの代替的実装形態においては、指摘される機能/動作は、図面の中で指摘される順序から外れて起こり得ることにも注意すべきである。例えば、連続して示される2つの図は、実際には、実質的に同時に実行されることが可能であり、または時には、関与する機能/動作に応じて逆の順序で実行されることも可能である。
【0012】
本明細書において使用されるように、用語「ユーザ装置(UE)」は、モバイル・ユーザ、ユーザ、加入者、ワイヤレス端末、および/またはリモート局に対する同義語とすることができ、またワイヤレス通信ネットワークにおけるワイヤレス・リソースのリモート・ユーザを説明することができる。
【0013】
以下の説明は、3GPP技術および/または関連技術に基づいたネットワークに関する。しかしながら、本明細書において示され、また説明される実施形態の例は、例示的にすぎず、またいかなる形でも限定することがないように意図されていることに注意すべきである。したがって、様々な修正は、上記以外の技術に基づいた通信システムまたはネットワークに対するアプリケーションについて、当業者には明らかになり、これらの技術は、開発の様々な段階にあり、また上記のネットワークまたはシステムについての将来の置き換え、あるいは上記のネットワークまたはシステムを伴う使用のために意図される可能性がある。
【0014】
現在のネットワーク・アーキテクチャは、モバイル/ユーザ・デバイスと、アクセス・ポイント/基地局との間の区別を考慮することができるが、以降に説明される実施形態の例は、例えば、アド・ホック・アーキテクチャ(ad hoc architecture)および/またはメッシュ・ネットワーク・アーキテクチャなど、その区別がそれほど明確でない場合のアーキテクチャに対して一般的に適用可能とすることができる。
【0015】
図1は、一例の実施形態によるIMSネットワーク100を示すものである。例示の目的のために、図1は、3つのUE(101、103、および105)を含んでいる。第1のユーザ装置(UE−1 101)は、コールを行っている通信デバイスとすることができるのに対して、第2のユーザ装置(UE−2 103)と、第3のユーザ装置(UE−3 105)とは、共用の識別子によって互いに関連づけられることが可能である。共用の識別子は、それだけには限定されないが、共用の電話番号および/または共用のユニフォーム・リソース・アイデンティファイア(Uniform Resource Identifier)(URI)フィールドとすることができる。関連するUE(UE−2 103およびUE−3 105)は、それぞれ個別にIMSネットワーク100に登録することができる。
【0016】
それらのUEは、SIPを使用して、コール・セッション制御機能(Call Session Control Function)(CSCF)109と通信する。CSCF109は、IMSネットワーク100においてSIPシグナリング・パケットを処理するために使用されるSIPのサーバおよび/またはプロキシの集まりとすることができる。CSCFは、プロキシ−CSCF(P−CSCF)と、サービング−CSCF(S−CSCF)と、問い合わせ−CSCF(I−CSCF)とを含むことができる。P−CSCFは、連絡の第1のポイントとすることができる。IMSネットワーク100においてUEによって送信されるメッセージおよび/または受信されるメッセージは、P−CSCFを通して伝搬する。S−CSCFは、SIPシグナリング・プレーンにおける中心ノードとすることができる。I−CSCFは、問い合わせ機能とすることができる。着信コール(例えば、SIP招待要求(SIP INVITE requests))は、I−CSCFを通して伝搬する。簡単にするために、S−CSCFだけが、より詳細に考察されることになる。IMSネットワーク100において、CSCF109は、S−CSCF111を含んでいる。S−CSCF111とのUEの通信は、下記でさらに考察される。
【0017】
UEと、S−CSCF111との間の通信は、様々なネットワーク要素107を横切る。しかしながら、様々なネットワーク要素107を構成する各中間要素は、明確さを向上するために示されてはいない。様々なネットワーク要素107は、それだけには限定されないが、(i)アクセス・ネットワーク(例えば、デジタル加入者回線アクセス・マルチプレクサなど)と、(ii)ゲートウェイ(例えば、境界ゲートウェイ、IMSゲートウェイ、シグナリング・ゲートウェイ、メディア・ゲートウェイなど)と、(iii)他の任意の中間のIMS要素(ネットワーク・アタッチメント・サブシステム(Network Attachment Subsystem)、オートメーション構築システム(Building Automation System)、アクセス・リソースおよびアドミッション機能、ポリシー決定機能、サービス・ベースのポリシー決定機能など)とを含むことができる。
【0018】
S−CSCF111は、SIPを利用して、アプリケーション・サーバ(AS)115と、メディア・リソース機能(Media Resource Function)(MRF)113と通信する。AS115は、UEに対して提供される様々なサービスを実行するSIPエンティティとすることができる。AS115はまた、関連するUE(UE−2 103およびUE−3 105)が、共用の識別子を有することを知っていることもできる。AS115は、関連するUEが、IMSネットワーク100に登録する場合に、またはそのときに、この事実を知るようになることができる。他方、MRF113は、メディアに関連した機能(例えば、多方向会議接続、メディア操作、アナウンスメントなど)を提供することができる。MRF113は、メディア・リソース機能コントローラ(Media Resource Function Controller)(MRFC)と、メディア・リソース機能プロセッサ(Media Resource Function Processor)(MRFP)とを含むことができる。MRFCは、S−CSCF111に対するSIPユーザ・エージェントとしての機能を果たすことができる。MRFPは、実際のメディアに関連した機能を実装することができる。
【0019】
図2は、一例の実施形態による、既存のコールにSIP通信デバイスを参加させる方法を示すものである。説明の目的のために、図2に説明される方法は、図1に示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけには限定されることはない。したがって、図1からの参照番号は、必ずしも図2において使用されるとは限らない。
【0020】
ステップS100において、コールを行っているUEからの着信コールが、受信される。コールは、ASによって受信されることが可能である。ひとたび、コールが受信された後に、関連するUEは、ステップS200を通じて、着信コールが、到着していることを警告される。次に、ステップS300において、コールを行っているUEと、少なくとも1つの関連するUEとの間の接続が、確立される。ステップS300は、接続されていなかった関連するUEとのコール・セッションを終了することを含むこともできる。ひとたび、接続が確立された後に、関連するUEは、ステップS400を通じて接続について通知される。ステップS500において、会議プロシージャは、接続されていなかったUEがアクティブにされるのに応じて、実行される。会議プロシージャは、コールを行っているUEと、関連する少なくとも1つの接続されたUEと、最初に接続されていなかったUEとを多方向会議コールに自動的に追加することができる。多方向会議コールが、終了するときに、コールは、ステップS600を通じて終了されることが可能である。最後に、ステップS700において、関連するUEは、もう一度、回線がアイドル状態であることを通知される。
【0021】
図3は、一例の実施形態による、図2のステップS100をさらに定義する信号フロー図である。説明の目的のために、図3において説明される方法は、図1に示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけには限定されてはいない。したがって、図1からの参照番号は、必ずしも図3において使用されるとは限らない。
【0022】
図3において、コールを行っているUE(UE−1)は、ステップS101において招待要求をS−CSCFに対して送信する。招待要求は、着信コールとすることができる。招待要求の宛先アドレスは、共用の識別子とすることができる。次に、ステップS103において、S−CSCFは、招待要求をASに対して転送する。図1を考察するときに上記で示されるように、共用の識別子を有する関連するUE(UE−2およびUE−3)は、ASに登録することができる。したがって、関連するUEのそれぞれは、固有公共識別情報(unique public identity)を割り当てられることが可能である。固有公共識別情報はまた、URIフィールドとすることもできる。それに応じて、ステップS105において、ASは、関連するUE−2によって受信されるように意図されるS−CSCFに対して招待要求を転送することができる。招待要求は、UE−2に対応する固有公共識別情報を含むことができる。S−CSCFは、招待要求が、固有公共識別情報に基づいてUE−2に進むように意図されることを知っていることができる。それゆえに、S−CSCFは、ステップS107を通じて、招待要求を関連するUE−2に対して転送する。同様に、ステップS109において、ASは、関連するUE−3要求に対応する固有公共識別情報を含む招待要求をS−CSCFに対して転送する。S−CSCFは、ステップS111を通じて、招待要求を関連するUE−3に対して転送する。ステップS105、S107、S109、およびS111は、同時に実行され得ることに注意すべきである。また、次いで、ASは、関連するUE(UE−2およびUE−3)に送信される顕著な招待要求を追跡することができる。
【0023】
図4は、一例の実施形態による、図2のステップS200をさらに定義する信号フロー図である。説明の目的のために、図4において説明される方法は、図1に示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけには限定されていない。したがって、図1からの参照番号は、必ずしも図4において使用されるとは限らない。
【0024】
ひとたび、関連するUEが、図3において上記で考察されるように招待要求を受信した後に、関連するUEは、リンギング警報(ringing alerts)をASに対して送信することができる。より詳細には、関連するUE−2は、ステップS201において、リンギング警報をS−CSCFに対して送信する。S−CSCFは、このリンギング警報をASに対して転送する。ひとたび、ASによって受信された後に、ASは、ステップS205に示されるように、関連するUE−2のリンギング警報をS−CSCFに対して転送する。ASによって転送されるリンギング警報は、ステップS207を通じて、コールを行っているUE−1によって受信されるように意図される。次いで、このプロセスは、関連するUE−3に関して反復されることが可能である。より詳細には、ステップS209において、関連するUE−3は、それ自体のリンギング・アナウンスメントをS−CSCFに対して送信する。リンギング・アナウンスメントは、ステップS211を通じて、S−CSCFからASへと転送される。次いで、ASは、リンギング・アナウンスメントをUE−1(図示されず)へと転送することができる。
【0025】
図5は、一例の実施形態による、図2のステップS300をさらに定義する信号フロー図である。説明の目的のために、図5において説明される方法は、図1に示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけには限定されていない。したがって、図1からの参照番号は、必ずしも図5において使用されるとは限らない。
【0026】
最終的には、リンギング警報が、関連するUEによって送信された後に、加入者は、少なくとも1つの関連するUEをアクティブにする(例えば、コールに応答する)ことになる。ステップS301において、関連するUE−2は、コールに応答し、また応答確認をS−CSCFに対して送信する。図5において、応答確認は、「OK」メッセージである。OKメッセージは、ストリーミング・メディア初期化パラメータ(例えば、セッション記述プロトコル応答(Session Description Protocol answer)を記述するためのフォーマットにおける応答を含むことができる。S−CSCFは、ステップS303において、OKメッセージをASに対して転送する。ステップS305において、ASは、UE−2識別子を有するOKメッセージをS−CSCFに対して転送する。UE−2識別子は、UE−2からのSDP応答を含むことができる。ステップS307において、S−CSCFは、UE−2識別子と一緒に、OKメッセージをUE−1に対して転送する。上記で述べられるように、UE−1は、コールを行っているUEである。それに応じて、UE−1と、UE−2との間の接続が、ステップS309を通じて、その後に確立される。
【0027】
また、関連するUE−3(接続されていなかった関連するUE)を伴うコール・セッションも終了されることが可能である。より詳細には、ASは、接続されていなかった関連するUE−3を伴う顕著な招待(INVITE)をキャンセルすることができる。ステップS311において、ASは、キャンセル・メッセージ(cancellation message)をS−CSCFに対して送信する。キャンセル・メッセージは、SIPキャンセル・メッセージ(SIP CANCEL message)とすることができる。キャンセル・メッセージは、ステップ313において、S−CSCFによりUE−3に対して転送される。それに応じて、接続されていなかった関連するUE−3は、ステップS315を通じて、キャンセルの肯定応答(ACK)をS−CSCFに対して返信する。キャンセルの肯定応答は、SIP OKキャンセル・メッセージ(SIP OK CANCEL message)とすることができる。S−CSCFは、ステップS317においてキャンセルをASに対して転送する。また、接続されていなかった関連するUE−3は、ステップS319を通じて、同様にセッション終了メッセージ(session termination message)をS−CSCFに対して送信する。セッション終了メッセージは、顕著な招待に対応するセッションが、終了されることを確認することができる。ステップS321において、S−CSCFは、セッション終了メッセージをASに対して転送する。次いで、ASは、ACKをS−CSCFに対して返信すること(ステップS323)によって応答し、S−CSCFは、このACKを接続されていなかった関連するUE−3に対して転送する(ステップS325)。図6は、一例の実施形態による、図2のステップS400をさらに定義する信号フロー図である。説明の目的のために、図6に説明される方法は、図1に示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけには限定されていない。したがって、図1からの参照番号は、必ずしも図6において使用されるとは限らない。
【0028】
ひとたび、コールが、図5を通じて応答された後に、ASは、コールを行っているUE−1と、関連するUE−2との間の接続についてすべての関連するUEに通知することができる。図6は、この通知するプロシージャを示すものである。より詳細には、ステップS401において、ASは、コール通知メッセージ(call notification message)をS−CSCFに対して送信する。コール通知メッセージは、SIP通知要求(SIP NOTIFY request)とすることができる。コール通知メッセージは、回線が、込んでおり、かつ/またはアクティブであることを加入者に通知するために、接続されていなかったUE−3によって使用されることも可能である。例えば、コール通知メッセージを使用して、従来のPSTN電話に類似した光源および/または何らかの他のコンピュータ化された形態の加入者通知(例えば、「使用中」の光、または「コールが進行中」の光)をアクティブにすることができる。
【0029】
ステップS403において、S−CSCFは、コール通知メッセージを接続されていなかった関連するUE−3に対して転送する。しかしながら、ASは、コール通知メッセージを接続された関連するUE−2(図示されず)に対して転送することもできる。それに応じて、ステップS405において、接続されていなかったUE−3は、確認OK通知メッセージ(confirmation OK NOTIFY message)をS−CSCFに対して送信する。S−CSCFは、ステップS407を通じて、OK通知メッセージをASに対して転送する。
【0030】
図7A〜7Bは、一例の実施形態による、図2のステップS500をさらに定義する信号フロー図である。説明の目的のために、図7A〜7Bにおいて説明される方法は、図1において説明されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけに限定されていない。したがって、図1からの参照番号は、必ずしも図7A〜7Bにおいて使用されるとは限らない。
【0031】
ひとたび、接続されていなかったUE−3が、コール通知メッセージを受信した後に、接続されていなかったUE−3は、アクティブにされることが可能である(例えば、ユーザは、UE−3のハンドセットをピックアップする)。会議プロシージャは、UE−3がアクティブにされた後に、自動的に開始されることが可能である。図7Aにおいて、ステップS501は、接続されていなかったUE−3によりS−CSCFに対して送信されている参加コール要求(join call request)を示している。参加コール要求は、ユーザおよび/または加入者によってピックアップされているUE−3に応じて送信される。参加コール要求は、SIP招待要求とすることができる。また、SIP招待要求は、SIP URIフィールドの中に特別な値を含むこともできる。次いで、S−CSCFは、ステップS503において、参加コール要求をASに対して転送する。
【0032】
ASが、参加コール要求を受信する場合、またはそのときに、ASは、コールを行っているUE−1と、共用の識別子を有するすべての関連するUEとを参加させる会議プロシージャをアクティブにすることができる。会議は、すべてのパーティが、参加させられ得るような多方向会議接続とすることができる。パーティは、MRFを使用して参加させられることが可能である。図7AのステップS505において、招待メッセージは、ASからMRFへと送信される。招待メッセージは、UE−3識別子を有する、会議接続に参入すべき提案を含んでいる。その提案は、UE−3からのSDP提案とすることができる。MRFは、招待メッセージの確認を送信することにより応答することができる。図7Aにおいて、確認は、ステップS507を通じて、ASに対して送信されるOK招待メッセージ(OK INVITE message)である。OK招待は、MRFからのSDP応答を含むことができる。次に、ステップS509において、ASは、MRFからS−CSCFへとOK招待を転送する。S−CSCFは、ステップS511を通じて、OK招待を接続されていなかった関連するUE−3に対して転送する。接続されていなかった関連するUE−3は、ACKをS−CSCFに対して返信すること(ステップS513)により応答し、次いでこのACKは、ASに対して転送される(ステップS515)。ステップS517において、ASは、ACKをMRFに対して転送する。その結果として、以前には接続されていなかったUE−3は、今や、ステップS519を通じて、多方向会議接続に参加させられる。
【0033】
次に、コールを行っているUE−1と、接続された関連するUE−2とはまた、図7Bに示されるように、多方向会議接続に参加させられることも可能である。より詳細には、ASは、ステップS521を通じて、再招待メッセージ(REINVITE message)をS−CSCFに対して送信する。再招待メッセージは、SDPメッセージを含んでいなくてもよい。ステップS523において、S−CSCFは、再招待メッセージを接続された関連するUE−2に対して転送する。UE−2は、再招待メッセージの確認を送信することにより応答することができる。図7Bにおいて、確認は、ステップS525に示されるように、S−CSCFに対して送信されるOK再招待メッセージ(OK REINVITE message)である。OK再招待は、SDP提案を含むことができる。次いで、S−CSCFは、ステップS527を通じて、OK再招待をASに対して転送する。次に、ステップS529において、ASは、接続された関連するUE−2からの提案を有する招待メッセージをMRFに対して送信する。MRFは、ステップS531に示されるように、ASに対して送信されるOK招待メッセージを用いて応答することにより招待を確認する。その後に、ASは、ACKをS−CSCFに対して送信し(ステップS533)、このACKは、S−CSCFにより、接続された関連するUE−2に対して転送される(ステップS535)。ASはまた、ステップS537を通じて、ACKをMRFに対して送信する。このようにして、接続された関連するUE−2はまた、ステップS539に示されるように、以前には接続されていなかった関連するUE−3と一緒に、多方向会議接続に参加させられる。
【0034】
コールを行っているUE−1は、接続された関連するUE−2の方法と同じ方法で、多方向会議接続に参加させられることが可能である。ステップS541において、ASは、再招待メッセージをS−CSCFに対して送信し、この再招待メッセージは、その後にステップS543において、S−CSCFにより、コールを行っているUE−1に対して転送される。再招待メッセージは、SDPメッセージを含んでいなくてもよい。再招待メッセージの受信のすぐ後に、コールを行っているUE−1は、OK再招待メッセージをS−CSCFに対して送信すること(ステップS545)によって応答し、このOK再招待メッセージは、S−CSCFによりASに対して転送される(ステップS547)。次に、ステップS549において、ASは、コールを行っているUE−1からの提案を有する招待メッセージをMRFに対して送信する。MRFは、ステップS551に示されるようにASに対して送信されるOK招待メッセージを用いて応答することにより招待を確認する。ASは、ACKをS−CSCFに対して送信し(ステップS553)、このACKは、S−CSCFにより、接続された関連するUE−2に対して転送される(ステップS555)。ASはまた、ステップS557を通じて、ACKをMRFに対して送信する。このようにして、コールを行っているUE−1はまた、ステップS559に示されるように、接続された関連するUE−2と、以前には接続されていなかった関連するUE−3と一緒に多方向会議接続に参加させられる。
【0035】
図8A〜8Bは、一例の実施形態による、図2のステップS600をさらに定義する信号フロー図である。説明の目的のために、図8A〜8Bにおいて説明される方法は、図1において示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけに限定されていない。したがって、図1からの参照番号は、必ずしも図8A〜8Bにおいて使用されるとは限らない。
【0036】
上記に説明される多方向会議接続の終了時に、次いで多方向会議接続は、終了されることが可能である。関連するUEのそれぞれは、同時に、または異なる間隔で接続を切ることができる。例えば、接続されたUE−2は、多方向会議接続からの接続を切ることができるが、コールを行っているUE−1と、以前には接続されていなかったUE−3とは、多方向会議接続に留まることができる。代替的な一実施形態においては、コールを行っているUE−1と、以前には接続されていなかったUE−3とは、接続されたUE−2が、接続を切るときに多方向会議接続以外の接続に対して転送されることも可能である。
【0037】
図8Aは、コールを行っているUE−1と、以前には接続されていなかったUE−3とが、多方向会議接続の中に留まる間に、多方向会議接続からの接続を切る、接続されたUE−2についての一例の実施形態を示している。より詳細には、接続された関連するUE−2(今や終了しようとしている関連するUE−2)は、受話器を置き、ステップS601に示されるように、さようならメッセージ(BYE message)が、関連するUE−2からS−CSCFへと送信されるようにしている。ステップS603において、S−CSCFは、さようならメッセージをASに対して転送する。ASは、終了しようとしている関連するUE−2が、多方向会議接続からの接続を切るように意図していることを通知されて、ステップS605に示されるように、さようならメッセージをMRFに対して転送する。さようならメッセージは、終了しようとしている関連するUE−2に対応する情報を含むことができる。図8Aにおいて、対応する情報は、終了しようとしている関連するUE−2からMRFへのダイアログ(dialog)である。MRFは、ステップS607において、確認OKさようならメッセージ(confirmation OK BYE message)をASに対して送信することにより、応答し、ASは、ステップS609においてこの確認OKさようならメッセージをS−CSCFに対して転送する。S−CSCFは、ステップS611において、同様に、終了しようとしている関連するUE−2に対して確認OKさようならメッセージを転送する。確認OKさようならメッセージの受信のすぐ後に、終了しようとしている関連するUE−2は、ステップS613に示されるように、コールを行っているUE−1と、以前には接続されていなかった関連するUE−3とだけが、多方向会議接続に留まるように、多方向会議接続からの接続を切られる。それに応じて、多方向会議接続は依然として存在するので、すべての接続されていなかった関連するUEは、依然として回線がアクティブのままであることを通知されることが可能である。
【0038】
最終的に、多方向会議接続は、多方向会議接続の中の残りのUEによって完全に終了させられることが可能である。図8Bにおいて、以前には接続されていなかったUE−3(今や終了しようとしている関連するUE−3)は、ステップ615において、受話器を置き、さようならメッセージが、S−CSCFに対して送信されるようにしている。S−CSCFは、ステップS617に示されるように、さようならメッセージをASに対して転送する。次いで、ASは、ステップS619に示されるように、終了しようとしている関連するUE−3からのダイアログと一緒に、さようならメッセージをMRFに対して転送する。MRFは、ステップS621において、確認OKさようならメッセージをASに対して送信することによって応答し、ASは、ステップS623において、この確認OKさようならメッセージをS−CSCFに対して転送する。S−CSCFは、ステップS627において、同様に、終了しようとしている関連するUE−3に対して確認OKさようならメッセージを転送する。確認OKさようならメッセージの受信のすぐ後に、終了しようとしている関連するUE−3は、ステップS629に示されるように多方向会議接続からの接続を切られる。
【0039】
コールを行っているUE−1は、上記に説明される終了しようとしている関連するUEと同様なやり方で、多方向会議接続からの接続を切られることが可能である。しかしながら、コールを行っているUE−1は、多方向会議接続において最後に残っているUEであるので、ASは、終了プロセスを開始することができる。より詳細には、ASは、ステップS631に示されるように、コールを行っているUE−1からのダイアログを有するさようならメッセージをMRFに対して送信する。MRFは、ステップS633において、確認OKさようならメッセージをASに対して送信することによって応答する。ASは、コールを行っているUE−1に関して、コール終了プロセスを開始したので、ステップS635において、ASは、S−CSCFに対してさようならメッセージを送信し、S−CSCFは、ステップS637において、コールを行っているUE−1に対してこのさようならメッセージを転送する。さようならメッセージの受信のすぐ後に、コールを行っているUE−1は、ステップS639において、それ自体の確認OKさようならメッセージをS−CSCFに対して送信し、S−CSCFは、ステップS643において、この確認OKさようならメッセージをASに対して転送する。コールを行っているUE−1はまた、ステップS641において、多方向会議接続が、終了されるように、多方向会議接続からの接続を切る。
【0040】
図9は、一例の実施形態による、図2のステップS700をさらに定義する信号フロー図である。説明の目的のために、図9において説明される方法は、図1に示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけに限定されていない。したがって、図1からの参照番号は、必ずしも図9において使用されるとは限らない。
【0041】
UE接続(例えば、多方向会議接続)が、切り離された後に、関連するUEは、共用の電話番号に対応する回線が、アイドル状態であることを通知されることが可能である。例えば、図9のステップS701において、ASは、回線−アイドル通知(line−idle notification)をS−CSCFに対して送信し、ステップS703において、S−CSCFは、この回線−アイドル通知を関連するUE−2に対して転送する。図8Aに関して上記で考察されるように、次いで、現在アイドル状態である関連するUE−2は、確認メッセージを用いて応答することができる。例えば、図9において、関連するUE−2は、ステップS705において、OK通知メッセージ(OK NOTIFY message)をS−CSCFに対して送信することによって応答する。次いで、S−CSCFは、ステップS707を通じて、OK通知メッセージをASに対して転送する。
【0042】
やはり現在はアイドル状態である関連するUE−3に通知する同じプロセスが、反復されることも可能である。より詳細には、ステップS709において、ASは、回線−アイドル通知をS−CSCFに対して送信し、ステップS711において、S−CSCFは、この回線−アイドル通知を関連するUE−3に対して転送する。ステップS713において、関連するUE−3は、OK通知メッセージをS−CSCFに対して送信することによって応答し、次いで、S−CSCFは、ステップS715を通じてこのOK通知メッセージをASに対して転送する。それに応じて、すべての関連するものは、共用の電話番号に対応する回線がアイドル状態であることを通知される。
【0043】
実施形態の例が、このようにして説明されており、同じことが、多数のやり方で変化させられ得ることが、明らかであろう。そのような、変形形態は、開示された主題からの逸脱と見なされるべきではなく、またすべてのそのような修正形態は、本開示の主題の範囲内に含められるように意図される。
【特許請求の範囲】
【請求項1】
コールを行っている通信デバイスからの着信コールを受信するステップ(S100)と、
関連する通信デバイスの組の中の、前記コールを行っている通信デバイスと、少なくとも1つの関連する通信デバイスとの間で接続を確立するステップ(S300)と、
前記接続について、関連する通信デバイスの前記組に通知するステップ(S400)と、
接続されていなかった通信デバイスがアクティブにされるのに応じて、多方向会議接続が、前記コールを行っている通信デバイスと、前記少なくとも1つの関連する通信デバイスと、前記少なくとも1つの接続されていなかった通信デバイスとの間で確立されるように、会議プロシージャを実行するステップ(S500)と
を備える通知方法。
【請求項2】
前記確立するステップは、
前記少なくとも1つの関連する通信デバイスからの応答確認を受信するステップと、
前記コールを行っている通信デバイスが、前記少なくとも1つの関連する通信デバイスとの前記接続を確立するように、前記応答確認を前記コールを行っている通信デバイスに対して転送するステップと
を含む、請求項1に記載の方法。
【請求項3】
前記通知するステップは、
コール通知を前記少なくとも1つの接続されていなかった通信デバイスに対して送信するステップと、
前記通知の肯定応答を受信するステップと
を含み、前記コール通知は、前記少なくとも1つの接続されていなかった通信デバイスに、共用の回線が現在前記少なくとも1つの関連する通信デバイスに割り付けられていることを通知する、請求項1に記載の方法。
【請求項4】
前記実行するステップは、
前記少なくとも1つの接続されていなかった通信デバイスがアクティブにされることを示す参加コール要求を前記少なくとも1つの接続されていなかった通信デバイスから受信するステップと、
前記少なくとも1つの接続されていなかった通信デバイスと、前記少なくとも1つの関連する通信デバイスと、前記コールを行っている通信デバイスとを前記参加コール要求を受信するステップに応じて会議コールに参加させるステップと
を含む、請求項1に記載の方法。
【請求項5】
前記追加するステップは、
メディア・リソース機能に対して、前記参加コール要求を受信するとすぐに、前記メディア・リソース機能が、前記少なくとも1つの接続されていなかった通信デバイスを前記会議コールに追加するように、前記少なくとも1つの接続されていなかった通信デバイスに対応する識別情報を有する第1の招待を送信するステップと、
前記メディア・リソース機能が、前記少なくとも1つの関連する通信デバイスを前記会議コールに追加するように、前記少なくとも1つの関連する通信デバイスに対応する識別情報を有する第2の招待を送信するステップと、
前記メディア・リソース機能が、前記コールを行っている通信デバイスを前記会議コールに追加するように、前記コールを行っている通信デバイスに対応する識別情報を有する第3の招待を送信するステップと
を含む、請求項4に記載の方法。
【請求項6】
前記コールを行っている通信デバイスと、前記少なくとも1つの関連する通信デバイスと、前記少なくとも1つの接続されていなかった通信デバイスとのうちの少なくとも1つについての前記多方向会議接続を終了させるステップ
をさらに備える、請求項1に記載の方法。
【請求項7】
前記終了させるステップは、
前記コールを行っている通信デバイスと、前記少なくとも1つの関連する通信デバイスと、前記少なくとも1つの接続されていなかった通信デバイスとの間の会議コールを終わらせるステップと、
アイドル通知を関連する通信デバイスの組のそれぞれに対して送信するステップと
を含む、請求項7に記載の方法。
【請求項8】
前記アイドル通知は、共用の回線が現在では使用可能であることを関連する通信デバイスの前記組に通知する、請求項7に記載の方法。
【請求項9】
コールを行っている通信デバイスからの着信コールを受信し、関連する通信デバイスの組の中の、前記コールを行っている通信デバイスと、少なくとも1つの関連する通信デバイスとの間で接続を確立すること、
前記接続について少なくとも1つの接続されていなかった通信デバイスに通知すること、
接続されていなかった通信デバイスがアクティブにされるのに応じて、多方向会議接続が、前記コールを行っている通信デバイスと、前記少なくとも1つの関連する通信デバイスと、前記少なくとも1つの接続されていなかった通信デバイスとの間で確立されるように、会議プロシージャを実行すること、および
共用の回線が使用可能であるときに、アイドル通知を関連する通信デバイスの前記組のそれぞれに対して送信すること
を行うように構成されたアプリケーション・サーバ(115)
を備える通知装置。
【請求項10】
前記コールを行っている通信デバイスと、前記少なくとも1つの関連する通信デバイスと、前記少なくとも1つの接続されていなかった通信デバイスとを含む会議コールを確立する際に、前記アプリケーション・サーバと対話するように構成されたメディア・リソース機能(113)
をさらに備える、請求項9に記載の通知装置。
【請求項1】
コールを行っている通信デバイスからの着信コールを受信するステップ(S100)と、
関連する通信デバイスの組の中の、前記コールを行っている通信デバイスと、少なくとも1つの関連する通信デバイスとの間で接続を確立するステップ(S300)と、
前記接続について、関連する通信デバイスの前記組に通知するステップ(S400)と、
接続されていなかった通信デバイスがアクティブにされるのに応じて、多方向会議接続が、前記コールを行っている通信デバイスと、前記少なくとも1つの関連する通信デバイスと、前記少なくとも1つの接続されていなかった通信デバイスとの間で確立されるように、会議プロシージャを実行するステップ(S500)と
を備える通知方法。
【請求項2】
前記確立するステップは、
前記少なくとも1つの関連する通信デバイスからの応答確認を受信するステップと、
前記コールを行っている通信デバイスが、前記少なくとも1つの関連する通信デバイスとの前記接続を確立するように、前記応答確認を前記コールを行っている通信デバイスに対して転送するステップと
を含む、請求項1に記載の方法。
【請求項3】
前記通知するステップは、
コール通知を前記少なくとも1つの接続されていなかった通信デバイスに対して送信するステップと、
前記通知の肯定応答を受信するステップと
を含み、前記コール通知は、前記少なくとも1つの接続されていなかった通信デバイスに、共用の回線が現在前記少なくとも1つの関連する通信デバイスに割り付けられていることを通知する、請求項1に記載の方法。
【請求項4】
前記実行するステップは、
前記少なくとも1つの接続されていなかった通信デバイスがアクティブにされることを示す参加コール要求を前記少なくとも1つの接続されていなかった通信デバイスから受信するステップと、
前記少なくとも1つの接続されていなかった通信デバイスと、前記少なくとも1つの関連する通信デバイスと、前記コールを行っている通信デバイスとを前記参加コール要求を受信するステップに応じて会議コールに参加させるステップと
を含む、請求項1に記載の方法。
【請求項5】
前記追加するステップは、
メディア・リソース機能に対して、前記参加コール要求を受信するとすぐに、前記メディア・リソース機能が、前記少なくとも1つの接続されていなかった通信デバイスを前記会議コールに追加するように、前記少なくとも1つの接続されていなかった通信デバイスに対応する識別情報を有する第1の招待を送信するステップと、
前記メディア・リソース機能が、前記少なくとも1つの関連する通信デバイスを前記会議コールに追加するように、前記少なくとも1つの関連する通信デバイスに対応する識別情報を有する第2の招待を送信するステップと、
前記メディア・リソース機能が、前記コールを行っている通信デバイスを前記会議コールに追加するように、前記コールを行っている通信デバイスに対応する識別情報を有する第3の招待を送信するステップと
を含む、請求項4に記載の方法。
【請求項6】
前記コールを行っている通信デバイスと、前記少なくとも1つの関連する通信デバイスと、前記少なくとも1つの接続されていなかった通信デバイスとのうちの少なくとも1つについての前記多方向会議接続を終了させるステップ
をさらに備える、請求項1に記載の方法。
【請求項7】
前記終了させるステップは、
前記コールを行っている通信デバイスと、前記少なくとも1つの関連する通信デバイスと、前記少なくとも1つの接続されていなかった通信デバイスとの間の会議コールを終わらせるステップと、
アイドル通知を関連する通信デバイスの組のそれぞれに対して送信するステップと
を含む、請求項7に記載の方法。
【請求項8】
前記アイドル通知は、共用の回線が現在では使用可能であることを関連する通信デバイスの前記組に通知する、請求項7に記載の方法。
【請求項9】
コールを行っている通信デバイスからの着信コールを受信し、関連する通信デバイスの組の中の、前記コールを行っている通信デバイスと、少なくとも1つの関連する通信デバイスとの間で接続を確立すること、
前記接続について少なくとも1つの接続されていなかった通信デバイスに通知すること、
接続されていなかった通信デバイスがアクティブにされるのに応じて、多方向会議接続が、前記コールを行っている通信デバイスと、前記少なくとも1つの関連する通信デバイスと、前記少なくとも1つの接続されていなかった通信デバイスとの間で確立されるように、会議プロシージャを実行すること、および
共用の回線が使用可能であるときに、アイドル通知を関連する通信デバイスの前記組のそれぞれに対して送信すること
を行うように構成されたアプリケーション・サーバ(115)
を備える通知装置。
【請求項10】
前記コールを行っている通信デバイスと、前記少なくとも1つの関連する通信デバイスと、前記少なくとも1つの接続されていなかった通信デバイスとを含む会議コールを確立する際に、前記アプリケーション・サーバと対話するように構成されたメディア・リソース機能(113)
をさらに備える、請求項9に記載の通知装置。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7A】
【図7B】
【図8A】
【図8B】
【図9】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7A】
【図7B】
【図8A】
【図8B】
【図9】
【公表番号】特表2013−513334(P2013−513334A)
【公表日】平成25年4月18日(2013.4.18)
【国際特許分類】
【出願番号】特願2012−543131(P2012−543131)
【出願日】平成22年11月17日(2010.11.17)
【国際出願番号】PCT/US2010/056941
【国際公開番号】WO2011/071665
【国際公開日】平成23年6月16日(2011.6.16)
【出願人】(391030332)アルカテル−ルーセント (1,149)
【Fターム(参考)】
【公表日】平成25年4月18日(2013.4.18)
【国際特許分類】
【出願日】平成22年11月17日(2010.11.17)
【国際出願番号】PCT/US2010/056941
【国際公開番号】WO2011/071665
【国際公開日】平成23年6月16日(2011.6.16)
【出願人】(391030332)アルカテル−ルーセント (1,149)
【Fターム(参考)】
[ Back to top ]