ＲＴＣＰ接続メッセージを用いるＰｏＣアドホックグループセッション情報処理方法及びシステム
【課題】グループ招待者情報を受信側ＰｏＣクライアントに伝達するための方法及びシステムを提供する。
【解決手段】ＰｏＣシステムにおいて、受信側ＰｏＣユーザー端末機とＰｏＣサーバとの間で事前設定セッション及び自動応答モードが設定された場合には、受信側ＰｏＣユーザーがアドホックグループセッション招待者情報の取得を可能にし、選好度に従ってＰｏＣセッションを選択的に確立する方法を開示する。特に、受信側ＳＩＰセッション設定を効率的に活用するために、ユーザープレーンシグナリングを介してグループ通話に参加するものと予想される他のユーザーに関連した情報を伝達する方案、及びこれをサポートするためのアクセス規則、サービスセッティング、タイマー、及びクライアントとサーバとの間で設定された応答を変更する方法を開示する。
【解決手段】ＰｏＣシステムにおいて、受信側ＰｏＣユーザー端末機とＰｏＣサーバとの間で事前設定セッション及び自動応答モードが設定された場合には、受信側ＰｏＣユーザーがアドホックグループセッション招待者情報の取得を可能にし、選好度に従ってＰｏＣセッションを選択的に確立する方法を開示する。特に、受信側ＳＩＰセッション設定を効率的に活用するために、ユーザープレーンシグナリングを介してグループ通話に参加するものと予想される他のユーザーに関連した情報を伝達する方案、及びこれをサポートするためのアクセス規則、サービスセッティング、タイマー、及びクライアントとサーバとの間で設定された応答を変更する方法を開示する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プッシュツートークオーバーセルラー（Push to Talk Over Cellular：以下、“ＰｏＣ”と称する。）システムにおけるアドホックＰｏＣグループセッションを確立する際に、グループ招待者情報を受信側ＰｏＣクライアントに伝達するための方法及びシステムに関する。
【背景技術】
【０００２】
移動通信技術の画期的な発展及び通信網の拡大に伴って、携帯電話を用いたより拡張された様々なサービス及びアプリケーションが提供されている。また、ユーザーの要求も多様化されており、基本的な通話サービスを越えて、位置サービス、マルチメディアサービス、ＰＴＴ（Push To Talk）サービスなどに拡大されている。特に、ＰＴＴサービスは、従来の無線電信又は基盤無線システム（Trunked Radio System：ＴＲＳ）により提供されたグループ通話及び音声通話だけではなく、インスタントメッセンジャー及び状態表示のような様々な付加機能をサポートする。
【０００３】
現在では、このようなＰＴＴ概念を、移動通信網を用いてサービスするＰｏＣサービスを標準化することが活発に論議されている。従来の移動通信サービスと区別されるＰｏＣサービスの特徴の１つは、ユーザーが、必要に応じて複数のセッション間を移動しながら通話することができることにある。ユーザーが複数のセッションを移動しながら通話可能でなければならないという要求事項は、関連移動通信サービスを定義している団体であるオープンモバイルアライアンス（Open Mobile Alliance：ＯＭＡ）のＰｏＣ規格１．０の要求事項に明示されている。
【０００４】
ＰｏＣ１．０規格に従うと、ＰｏＣセッションは、実時間でＰｏＣセッションに参加したＰｏＣクライアントにだけメディアデータを送信する方式で確立される。このような特性に従うと、バッテリー放電又は不在などによってＰｏＣセッションに参加できないユーザーは、１対１ＰｏＣセッション又はグループＰｏＣセッションで送信される音声のようなメディアストリームを受信することができない。すなわち、ＰｏＣ１．０技術は、従来の通信システムでサポートされたボイスメールボックス機能をサポートしない。
【０００５】
一方、ＰｏＣ１．０規格は、任意のユーザーリストを対象グループとして指定するアドホックグループセッションモードをサポートする。この際、各受信側ＰｏＣクライアントは、アドホックグループセッションに招待されるユーザーに関する情報を受信することができないので、この招待されるユーザーに関する情報を取得する前に、このアドホックグループセッションに参加しなければならないという問題点がある。したがって、受信側ユーザーをセッションに招待する際に、受信側ユーザーがセッションに参加するか否かを決定するために必要とされる上述したようなアドホックグループセッションに招待された全てのユーザーに関する情報を受信側ユーザーに伝達するための方案がＰｏＣ２．０で要求事項として明示されている。
【０００６】
一方、ＰｏＣ１．０規格は、事前設定セッション及び自動応答モードなどをサポートすることにより、セッション確立の手続きを簡素化させる。上述したように、事前設定セッション及び自動応答モードをすべてサポートするＰｏＣクライアント及びＰｏＣサーバがこのアドホックグループセッションに対するセッション招待メッセージを受信した場合には、ＰｏＣクライアント及びＰｏＣサーバは、セッション参加成功メッセージを送信側ＰｏＣネットワークに送信することにより、各対応するユーザーの確認なしに即座に応答する。これは、ＰｏＣサーバがＳＩＰ成功メッセージを応答として直接送信する場合に、ＳＩＰメッセージが受信側ＰｏＣサーバとＰｏＣクライアントとの間のＳＩＰメッセージ交換手続きを簡素化し、したがって、セッション設定時間を短縮させる長所があるためである。しかしながら、従来の技術で提供された事前設定セッション及び自動応答モードは、このアドホックグループセッションの確立の際に、グループ招待者情報を伝達するメッセージを提供することができず、受信側ＰｏＣユーザーが招待者情報の確認を要請することができないという短所があった。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
したがって、本発明は、上述した従来技術の問題点を解決するために提案されたものであり、その目的は、自動応答モード及び受信側ＰｏＣクライアントとの事前設定セッションを確立したＰｏＣサーバがアドホックグループセッションに関する招待者情報を含むセッション招待メッセージを受信した場合には、事前設定セッションを用いてアドホックグループセッションに関する招待者情報を伝達するための方法及びシステムを提供することにある。
【０００８】
本発明の他の目的は、受信側ＰｏＣサーバが対応する招待者情報を送信する際に、受信側ＰｏＣクライアントの応答モードに関係なく、ユーザーがセッションに参加するか否かを識別するための方法及びシステムを提供することにある。
【０００９】
本発明のまた他の目的は、ＰｏＣクライアントがアドホックグループセッションに参加するか又は拒絶する場合に、送信側へのＳＩＰ及び実時間転送プロトコル（ＲＴＰ）メディア送信を効率的に処理するためのシグナリングのための方法及びシステムを提供することにある。
【００１０】
本発明のさらなる目的は、アドホックグループセッションに関する招待者情報を伝達する方法においてＰｏＣクライアント及びＰｏＣサーバのアルゴリズム及び機能を実現するための方法及びシステムを提供することにある。
【課題を解決するための手段】
【００１１】
上記のような目的を達成するために、本発明の実施形態の一態様によれば、受信側プッシュツートーク（ＰＴＴ）オーバーセルラー（ＰｏＣ）クライアントと受信側ＰｏＣサーバとの間で事前設定セッション及び自動応答モードが設定され、ＰｏＣアドホックグループセッションの確立の際に、アドホックグループセッション招待者情報を上記受信側ＰｏＣクライアントに提供し、上記提供された招待者情報に従うセッション設定を行うＰｏＣシステムにおけるＰｏＣアドホックグループセッション情報を処理するシステムであって、上記アドホックグループ招待者情報を含むセッション招待メッセージが送信側ネットワークから受信された場合には、上記招待者情報及び自動応答無視（ＡＡＯ）要請パラメータを含む接続メッセージを生成し、上記生成された接続メッセージを上記受信側ＰｏＣクライアントに伝達した後に、上記ＰｏＣクライアントから受信された応答に従ってＰｏＣセッション手続きを実行する上記ＰｏＣサーバと、上記接続メッセージを受信した場合には、上記接続メッセージに含まれている招待者情報をＰｏＣユーザーに伝達するように、現在設定されている応答モードに関係なく手動応答モードに進入し、上記ＰｏＣユーザーから入力される上記セッション参加の受諾又は拒絶に関する情報を含む応答メッセージを上記ＰｏＣサーバに伝達する上記ＰｏＣクライアントと、を具備することを特徴とする。
【００１２】
本発明の実施形態の他の態様によれば、受信側プッシュツートーク（ＰＴＴ）オーバーセルラー（ＰｏＣ）クライアントと受信側ＰｏＣサーバとの間で事前設定セッション及び自動応答モードが設定されたＰｏＣシステムにおいて、ＰｏＣアドホックグループセッションの確立の際に、アドホックグループセッション招待者情報を上記受信側ＰｏＣクライアントに提供し、上記提供された招待者情報に従うセッション設定を行うＰｏＣアドホックグループセッション情報を処理する方法であって、上記ＰｏＣサーバが上記アドホックグループ招待者情報を含むセッション招待メッセージを送信側ネットワークから受信した場合には、上記招待者情報及び自動応答無視（ＡＡＯ）要請パラメータを含む接続メッセージを生成し、上記生成された接続メッセージを上記受信側ＰｏＣクライアントに伝達するステップと、上記ＰｏＣクライアントが上記接続メッセージを受信した場合には、上記接続メッセージに含まれている招待者情報をＰｏＣユーザーに伝達するように、現在設定されている応答モードに関係なく手動応答モードに進入するステップと、上記ＰｏＣクライアントが上記ＰｏＣユーザーから入力される上記セッション参加の受諾又は拒絶に関する情報を含む応答メッセージを上記ＰｏＣサーバに伝達するステップと、上記ＰｏＣサーバが上記ＰｏＣクライアントから受信された応答に従ってＰｏＣセッション手続きを実行するステップと、を具備することを特徴とする。
【００１３】
本発明の実施形態のさらに他の態様によれば、上記接続メッセージ内のＡＡＯ要請パラメータを選択的に含むことができる。
【００１４】
本発明の実施形態のさらなる他の態様によれば、ＰｏＣ ＵＥがユーザー確認メッセージを送信する時点に従って上記事前設定セッション及び自動応答の際のアドホックＰｏＣグループセッション確立手続きを改善させる手続きを含む。
【００１５】
本発明の実施形態のさらに他の１つの態様によれば、受信側プッシュツートーク（ＰＴＴ）オーバーセルラー（ＰｏＣ）クライアントと受信側ＰｏＣサーバとの間で事前設定セッション及び自動応答モードが設定されたＰｏＣシステムにおいて、ＰｏＣアドホックグループセッションの確立の際に、アドホックグループセッション招待者情報を上記受信側ＰｏＣクライアントに提供し、上記提供された招待者情報に従うセッション設定を行うために、上記ＰｏＣサーバが上記アドホックグループ招待者情報を含むセッション招待メッセージを送信側ネットワークから受信した場合には、受信側ＰｏＣクライアントと受信側ＰｏＣサーバとの間で事前設定されたサービスセッティングに従ってセッション招待メッセージに含まれているアドホックグループ招待者情報を処理する方法を提供する。すなわち、上記アドホックグループ招待者情報処理方法は、上記受信側ＰｏＣクライアントが上記アドホックグループ招待者情報の受信をサポートする事前設定サービスの受信に設定されている場合には、上記招待者情報を含む接続メッセージを生成し、上記受信側ＰｏＣクライアントに伝達するステップと、上記受信側ＰｏＣクライアントが上記接続メッセージを受信した場合には、上記接続メッセージに含まれている招待者情報をＰｏＣユーザーに伝達するステップと、上記受信側ＰｏＣクライアントが上記ＰｏＣユーザーから入力されるセッション参加の受諾又は拒絶に関する情報を含む応答メッセージを上記ＰｏＣサーバに伝達するステップと、上記ＰｏＣサーバが上記受信側ＰｏＣクライアントから受信された応答に従ってＰｏＣセッション手続きを実行するステップと、を具備することを特徴とする。
【００１６】
本発明の実施形態のさらにまた他の態様によれば、受信側ＰｏＣクライアントとＰｏＣサーバとの間で事前設定セッション及び自動応答モードが設定されている場合には、事前設定セッションを用いてアドホックグループセッションに関する招待者情報を伝達する方法を提供する。また、本発明は、上記事前設定セッションを介したユーザープレーンシグナリングを活用し、受信側ＰｏＣユーザーの意思を反映するセッション確立を進行するために、ＰｏＣクライアントが設定した応答モードを管理するアドホックグループセッション確立手続きを提供する。
【発明の効果】
【００１７】
本発明は、事前設定セッション及び自動応答モードを使用するように設定されたＰｏＣ ＵＥとＰｏＣサーバとの間で、事前設定セッションを介して伝達されるＲＴＣＰメッセージを用いてアドホックグループセッションに関する招待者情報を伝達するための方法と、受信側ＰｏＣユーザーの選択に基づいてセッション参加の受諾又は拒絶に対する手続きを実行する方法を提供する。また、本発明によれば、上述したシナリオでアドホックグループのセッション招待者情報又は匿名ユーザーの数を識別することができ、これにより、ＰｏＣユーザーがセッションに参加するか否かを決定することができる。さらに、本発明によれば、ＰｏＣシステムは、応答モードの不一致によるＲＴＰメディアストリームの伝達を管理することができ、同時に、ＰｏＣセッションの迅速な確立を提供することができる。
【図面の簡単な説明】
【００１８】
【図１】従来のＰｏＣサービスシステムの構成を示す図である。
【図２】従来のＰｏＣサーバの機能を示す図である。
【図３】ＰｏＣサーバのＣＦ部及びＰＦ部を含むグループセッションの構成を示す図である。
【図４】本発明の第１の実施形態によるＰｏＣサーバでアドホックグループ招待者情報を送受信する場合におけるＰｏＣユーザーによるセッション確立応答に従って処理される信号のフローを示す図である。
【図５】本発明の第１の実施形態によるＰｏＣサーバでアドホックグループ招待者情報を送受信する場合におけるＰｏＣユーザーによるセッション拒絶応答に従って処理される信号のフローを示す図である。
【図６】本発明の第２の実施形態によるＰｏＣサーバでアドホックグループ招待者情報を送受信する場合におけるＰｏＣユーザーによるセッション拒絶応答に従って処理される改善した信号のフローを示す図である。
【図７】図４に示したＰｏＣサーバとユーザー端末機（ＵＥ）との間で送信されるＲＴＣＰ接続メッセージのフォーマットを示す図である。
【図８】図４に示したＰｏＣサーバとＵＥとの間で送信されるＲＴＣＰ応答（ＡＣＫ）メッセージのフォーマットを示す図である。
【発明を実施するための形態】
【００１９】
以下、本発明の好適な一実施形態を、添付図面を参照しつつ詳細に説明する。下記の説明において、本発明は、プッシュツートーク（Push to Talk：以下、“ＰＴＴ”と称する。）システム、特に、セルラー移動通信網を介してＰＴＴサービスを提供するプッシュツートークオーバーセルラー（PTT Over Cellular：以下、“ＰｏＣ”と称する。）システムに適用される場合を例に挙げて説明する。一般的に、ＰｏＣシステムは、グループ通話に関するセッション参加情報を伝達するために、セッション開始プロトコル（Session Initiation Protocol：以下、“ＳＩＰ”と称する。）及びＳＩＰ拡張プロトコルを使用し、グループ情報を取得するために、拡張可能なマークアップ言語（eXtensible markup language：ＸＭＬ）設定アクセスプロトコル（XML Configuration Access Protocol：以下、“ＸＣＡＰ”と称する。）を使用する。また、ＲＴＰ／ＲＴＣＰプロトコルは、確立されたセッション内で実時間メディア送信及び管理のために使用され、トークバーストコントロールプロトコル（Talk Burst Control Protocol：以下、“ＴＢＣＰ”と称する。）と呼ばれる実時間ＲＴＣＰ基盤専用プロトコルは、ＰＴＴサービスの特徴である発言権管理のために定義され使用される。特に、本発明は、ＰｏＣサーバとユーザー端末機（User Equipment：以下、“ＵＥ”と称する。）との間の事前設定セッションを用いて招待者情報を伝達するために、ＲＴＣＰ ＡＰＰの形態を有するＴＢＣＰメッセージ又は新たに設定されたＭＢＣＰメッセージを使用する。
【００２０】
本発明の下記の実施形態は、上述したプロトコルにより実現されることができ、本発明の基本的な構成は、ＰｏＣ Ｒｅｌ．１システムに基づいており、ＰｏＣ Ｂｏｘ又は拡張された概念のＸＭＬ文書管理（XML Document Management：以下、“ＸＤＭ”と称する。）サーバで記述されることができる。
【００２１】
まず、下記では、本発明が適用される一般的なＰｏＣシステムについて説明する。
【００２２】
図１は、従来のＰｏＣサービスシステム及び関連ネットワークの構成を示す図である。ＰｏＣシステムは、ＰｏＣ ＵＥ１００と、ＸＭＬ文書管理サーバ（XML Document Management Server：ＸＤＭＳ）１３０及び１４０と、ＰｏＣサーバ１５０とを含む。また、ＰｏＣシステムは、アグリゲーションプロキシサーバ１６０をさらに含んでもよい。上述した構成要素は、アクセスネットワーク１１０と、ＳＩＰ／インターネットプロトコル（Internet Protocol：ＩＰ）コアネットワーク１２０又は遠隔ＰｏＣネットワーク１７０とを介して相互に接続される。
【００２３】
ＰｏＣ ＵＥ１００は、ＰｏＣクライアント１０２とＸＤＭクライアント１０４とを含む。
【００２４】
ＰｏＣ ＵＥ１００に含まれているサービス要請者を示すＰｏＣクライアント１０２は、ＰｏＣ ＵＥ１００に滞在し、ＰｏＣサービスをＰｏＣ ＵＥ１００を介してＰｏＣサービス加入者に提供するためのネットワーク接続を遂行する。ＰｏＣサービス加入者は、ＰｏＣクライアントが内蔵されているＰｏＣ ＵＥを介してＰｏＣサービスの提供を受けることができる。下記の説明において、“ＰｏＣクライアント”という用語は、ＰｏＣクライアントが内蔵されているＵＥ及びＰｏＣサービス加入者を総称する。また、ＰｏＣクライアントの参照符号は、特に区別されるべき場合のない限り省略する。
【００２５】
ＰｏＣクライアントは、ＰｏＣサービス加入者（すなわち、ＰｏＣユーザー）がＰｏＣセッションの確立、すでに確立されているセッションの参加、又は確立されているセッションの終了を可能にするために主に使用される。また、ＰｏＣクライアントは、トークバーストを生成し送信する機能、インスタントパーソナルアラート（Instant Personal alert）をサポートする機能、及びＰｏＣサービスへのアクセスを認証する機能を有する。ＰｏＣクライアントは、アクセスネットワーク１１０を介してＳＩＰ／ＩＰマルチメディアをサポートするＳＩＰ／ＩＰコアネットワーク１２０に接続されることもある。
【００２６】
ＰｏＣクライアントは、アクセスネットワーク１１０を介してＳＩＰ／ＩＰマルチメディアサービスをサポートするのに重要な役割を果たすＳＩＰ／ＩＰコアネットワーク１２０に接続される。ＳＩＰ／ＩＰコアネットワーク１２０は、ＰｏＣサーバ１５０とＸＤＭＳ１３０及び１４０とに接続されることにより、ＰｏＣサービスをサポートする。この際、ＰｏＣサーバ１５０は、ＰｏＣセッションの維持及び管理を行うための制御ＰｏＣ機能（Controlling PoC Function）を行うことができ、１対１通話や多者間通話のために確立されるＰｏＣセッションに参加するための参加ＰｏＣ機能（Participating PoC Function）を行うことができる。
【００２７】
一方、ＰｏＣサービスは、コンファレンス通話のようなグループセッションを確立するサービスを伴うことができる。このために、ＯＭＡ標準は、グループリストサービスのためのＸＤＭクライアント１０４とＸＤＭＳ１３０及び１４０とを定義する。図１は、ＰｏＣサービスのために使用されるＰｏＣ ＸＤＭＳ１４０及び他のサービスイネーブラ（service enabler）にも共通に使用されることができる共用ＸＤＭＳ（Shared XDMS）１３０を示す。グループ及びグループメンバーに関する情報は、ＰｏＣクライアントを介してＸＤＭＳ１３０及び１４０に格納されることができる。ＰｏＣクライアント１０２は、ＸＤＭＳ１３０及び１４０から受信された個人又はグループのリストから、自身が呼び出すことができる他のＰｏＣクライアントに関する情報を取得する。一方、ＸＤＭＳ１３０及び１４０に格納されているグループ及びグループメンバー情報の生成、修正、及び管理は、インターネット又はイントラネットのようなＰｏＣサービスプロバイダーが信頼できる通信網を介してなされることもできる。ＸＭＬ文書を管理するためのプロトコル（例えば、グループリストの生成、修正、及び削除）は、本発明とは直接関連しないので、明瞭性のために省略する。
【００２８】
グループサービスのために、ＸＤＭクライアント１０４からグループリストに関連した要請を受信すると、アグリゲーションプロキシサーバ１６０は、適切な規則に従って、上記要請を各ＸＤＭＳ１３０及び１４０にルーティングする。
【００２９】
次いで、ＰｏＣサーバ１５０について説明する。
【００３０】
図２は、従来のＰｏＣサーバの構成を示す図である。ＰｏＣサーバの機能は、ＰｏＣセッションの全般的な維持及び管理を担当する制御ＰｏＣ機能（Controlling PoC Function：以下、“ＣＦ”と称する。）と各ＰｏＣセッションのための維持及び管理を担当する参加ＰｏＣ機能（Participating PoC Function：以下、“ＰＦ”と称する。）とに区分されることができる。下記の＜表１＞及び＜表２＞を参照して、ＰｏＣサーバの各機能に従う特性について説明する。
【００３１】
【表１】
【００３２】
上述した＜表１＞に示すように、ＣＦは、ＰｏＣサーバの機能の中で、ＰｏＣセッションの総体的な管理を意味する。特に、ＣＦは、ＰｏＣクライアントの発言権（floor）要請を受け入れ、その順序を定めて発言権をこのクライアントに付与する。また、ＣＦは、特定のＰｏＣクライアントからのトークバースト（talk burst）をグループＰｏＣ呼出しに参加した他のＰｏＣクライアントに分配し、グループＰｏＣ呼出しに参加したＰｏＣクライアントに関する情報を提供する。
【００３３】
下記の＜表２＞に示すように、ＰＦは、ＰｏＣセッションの間に、ＣＦと各ＰｏＣクライアントとの間に接続されたセッションの管理に関する。特に、ＰＦは、ＣＦでＰｏＣクライアントへの発言権の付与だけではなく、ＰｏＣクライアントの発言権の要請を中継する。また、ＰＦは、ＣＦとＰｏＣクライアントとの間のメディア中継機能、及び両者が異なるコーデック（codecs）を使用する場合にこれらをトランスコーディングする機能を担当する。さらに、他のトークバーストが同時多重セッションで発生している間に、トークバーストが１つのセッションで発生される場合には、ＰＦは、ユーザーの選択に従ってこれらの中の１つをフィルタリングするフィルタリング機能を担当する。
【００３４】
【表２】
【００３５】
図３は、グループセッションでＰｏＣ ＵＥとＰｏＣサーバとの接続を示し、特に、ＰｏＣサーバの機能に従ってＣＦ部とＰＦ部とを区分して説明する。
【００３６】
図３を参照すると、各ＰｏＣクライアント１００-Ａ乃至１００-Ｄは、ＰＦ３１０-Ａ乃至３１０-Ｄを介してＣＦ３００に接続される。この後、ＣＦ３００から発言権を与えられたＰｏＣクライアントの対応するトークバーストに対応するメディアが他のＰｏＣクライアントに送信される。この際、この発言権を有するＰｏＣクライアントは、グループセッションに参加しているＰｏＣクライアントに関する情報を確認するまで、適切なトークバーストをすることができない。
【００３７】
一方、ＰｏＣシステムにおいて、通話接続のための呼処理技術は、送信側及び受信側の要請及び状況に基づいて様々な手続きが可能である。ＯＭＡに基づいて、このような送信側及び受信側の設定に従って必要とされるＰｏＣシステムの特徴は、次の通りである。
【００３８】
第１に、受信側は、ＰｏＣクライアントの要請に応じて、自身の応答モードを設定することができ、自動応答モード及び手動応答モードに分類することができる。自動応答モードにおいては、送信側が受信側で予め定めたＰｏＣクライアントリストに含まれている場合には、受信側の手動応答の代わりに、対応するネットワークから送信側に応答を即座に送る。ＵＥを動作させず、ネットワークにより送られるこのような自動応答は、ＰｏＣサーバが、ＵＥの応答モード設定要請に従って、応答モード及び対応するユーザーリストに関する情報を格納することができるという事実に基づいている。他方、手動応答モードは、送信側が自動応答ユーザーリストに含まれていない場合、送信側が自動応答ユーザーリストに含まれているか否かが不明確な場合、又は受信側が全てのユーザーに手動応答モードを設定する場合に対応する。手動応答モードにおいて、ＰｏＣ通話要請は、受信ネットワークを介してＵＥに送信され、呼は、ＰｏＣクライアントの許可の後に接続される。
【００３９】
第２に、ＰｏＣシステムは、ＰｏＣユーザーのホームネットワーク内のＰｏＣサーバとの接続設定に基づいて、オンデマンド（on-demand）セッションモードと事前設定（pre-established）セッションモードとを有することができる。事前設定セッションモードにおいて、ＰｏＣクライアントが、自身の要請に応じて、ＰｏＣクライアントとユーザーのホームネットワークに属しているＰｏＣサーバとの間で事前にセッションを設定しておく。このような事前設定セッションは、将来使われるＰｏＣサーバとクライアントとの間のメディアパラメータを反復して交渉する必要がなく、迅速なセッション確立を行うことができるように、ＰｏＣクライアントが使用するメディアパラメータをＰｏＣサーバと事前に交渉する必要がある。
【００４０】
事前設定セッションを確立するために、ＰｏＣクライアントは、ＳＩＰ ＩＮＶＩＴＥ方法を使用することにより、セッション記述プロトコル多目的インターネットメール拡張（Session Description Protocol Multipurpose Internet Mail Extension：ＳＤＰ ＭＩＭＥ）のボディーを介してサーバが提供し、ＰｏＣクライアントがサポートしたメディアパラメータ、及びこのサーバが提供したメディアパラメータに対する応答を提供する。このサーバから応答メッセージを受信すると、この応答メッセージは、新たに事前設定されるセッションの識別情報、例えば、コンファレンス識別子（conference URI）とともにＰｏＣクライアントに返信される。
【００４１】
上述した事前設定セッションを使用する場合には、ＩＰアドレス、ポート番号、使用されるコーデック、及びトークバースト制御プロトコルなどの事前交渉が可能である。オンデマンドセッションモードは、任意のＰｏＣクライアントが事前設定セッションを確立しない場合に対応する。したがって、ＰｏＣクライアントは、招待メッセージを他のＰｏＣクライアントから受信した後に、ＰｏＣ呼を接続するための手続きを実行する。
【００４２】
ＰｏＣシステムにおいて、通話要請に関する応答モードの設定は、ネットワーク上のエレメントであるＰｏＣサーバ及びＵＥであるＰｏＣクライアントですべて格納されることができる。
【００４３】
応答モードがＰｏＣクライアントを管理するホームネットワークに設定される場合には、ＰｏＣクライアントが属しているホームネットワーク内でＰＦを有するＰｏＣサーバで実現される。
【００４４】
応答モードがネットワークに設定された場合には、ＰＦは、セッションプログレスメッセージを、通話を要請したネットワークに送信することにより、ＰｏＣ通話のための他のＰｏＣサーバの要請に自動で応答する。したがって、自動応答モードが設定された場合には、セッション設定メッセージがＰｏＣクライアントに伝達された後に応答が送信される場合に比べて、呼要請手続きが簡素化され、これにより、発言権を付与するのに必要とされる初期時間を短縮させる。
【００４５】
しかしながら、ネットワークで自動応答を遂行する場合には、状況に応じて、ユーザーの応答とは異なる結果をもたらすことがあり得る。したがって、ＰｏＣクライアントにも応答モードが設定されることができる。この際、ＰｏＣクライアントの応答モードがネットワーク上に設定された応答モードに優先するという特徴がある。これは、ＰｏＣクライアントが自身の応答モードを変更し、応答モードを更新することをＰｏＣサーバに要請したが、信号遅延又はネットワーク上のエラーにより実時間で応答モードが更新されない際に発生するプライバシー問題を解決するためである。
【００４６】
要約すると、ＰｏＣサービスに対するユーザーの応答モードがＰｏＣサーバ及びＰｏＣクライアントにすべて設定されることができるが、応答モードは、ユーザーの最も最近の意思を反映したＰｏＣクライアントにより決定され、このような決定に基づいて、実際のユーザーの音声又は映像などのようなメディアのストリームが伝達される。
【００４７】
上述したような特徴を有するＰｏＣシステムでのＰｏＣマルチメディアセッションを確立する手続きについて説明する。
【００４８】
送信側ＰｏＣクライアントは、ＳＩＰプロトコルを使用してマルチメディア招待メッセージを送信することにより、呼処理を要請する。この際、このマルチメディアは、メディアタイプの指定に従って、様々なフォーマットを有するオーディオ、ビデオ、及びテキストなどを含んでもよい。このような呼処理要請に応じて、受信側クライアントは、対応するＰｏＣサーバでの応答モードの設定及び事前設定セッションが確立されたか否かに基づいて、様々な応答手続きを実行する。ＰｏＣ通話のための呼処理手続きについては、送信側及び受信側の１つのネットワークを用いて説明する。
【００４９】
送信側ＰｏＣクライアントは、自身が通信を希望する受信側ＰｏＣクライアントのＳＩＰアドレス情報を含むＳＩＰ ＩＮＶＩＴＥ要請を対応するＳＩＰ／ＩＰコアネットワークに送信する。この際、ＳＩＰ ＩＮＶＩＴＥメッセージは、送信側ＰｏＣクライアントのＰｏＣアドレス情報、要求されるメディアパラメータ、及びＰｏＣサービスを識別する特性値情報などのようなエレメントをさらに含むことができる。ここで、“要求されるメディアパラメータ”は、要求されるセッションがマルチメディアセッションに関連する場合には、オーディオ及びビデオに関するエンコーディング方法、レート、及びペイロードタイプなどを示す複数の特性値を含むことができる。
【００５０】
ＳＩＰ ＩＮＶＩＴＥメッセージは、ダイナミックホストコンフィギュレーションプロトコル（Dynamic Host Configuration Protocol：ＤＨＣＰ）サーバ又はドメインネームサーバ（Domain Name Server：ＤＮＳ）における経路クエリー（query）に基づいて、インターネットプロトコルマルチメディアサブシステム（IP Multimedia Subsystem：ＩＭＳ）ネットワーク内の対応するＩＭＳサーバ、すなわち、プロキシ呼セッション制御機能（Proxy Call Session Control Function：Ｐ-ＣＳＣＦ）及びサービング呼サーバ制御機能（Serving-Call Server Control Function：Ｓ-ＣＳＣＦ）を介して参加ＰｏＣサーバに伝達される。一般的な通話が要請される際には、ＰｏＣクライアントが接続された参加ＰｏＣサーバは、確立されたセッションのトークバーストを管理する制御ＰｏＣサーバと個別に実現されることができ、これにより、ＰＦサーバに送信されたＳＩＰ ＩＮＶＩＴＥ要請は、対応するネットワークのＳＩＰ／ＩＰコアネットワークを介してＣＦサーバに伝達される。
【００５１】
一方、ＣＦを含むＰｏＣセッション制御ネットワークは、ＳＩＰ ＩＮＶＩＴＥ要請メッセージを受信側ネットワークに伝達した後に、受信側ネットワークから応答メッセージを受信する。受信側ネットワークから応答するＳＩＰメッセージは、受信側ＰｏＣクライアント及びＰＦの設定に基づいて、１ｘｘの臨時応答メッセージ、２ｘｘの成功応答メッセージ、又は４ＸＸ〜６ＸＸのエラー応答メッセージの中の１つであり得る。自動応答モードの場合には、ＳＩＰ １８３“セッションプログレス”信号が応答メッセージとして受信されることができ、このメッセージを介して通話要請者のＩＭＳネットワークでＰｏＣサーバとクライアントとの間の接続を行うことができる。受信側ＰｏＣクライアントの通話許可信号として、ＳＩＰ １８３セッションプログレス又はＳＩＰ ２００ ＯＫ応答は、ＣＦ及びＰＦのＰｏＣサーバを介してＰｏＣクライアントに送信される。受信側ＰｏＣサーバから１８３セッションプログレス信号又は２００ ＯＫ応答を受信すると、ＣＦは、ＰｏＣ呼が接続されたことを確認し、発言権許可信号（floor granted signal）を送信側ＰｏＣクライアントに送信することにより、トークバーストの発言権を付与する。上記応答、すなわち、ＳＩＰ ２００ ＯＫ又は１８３セッションプログレス信号に従ってトークバーストの発言権を付与することは、“ｃｏｎｆｉｒｍｅｄ”又は“ｕｎｃｏｎｆｉｒｍｅｄ”を使用して識別されることができる。ＣＦが“ｕｎｃｏｎｆｉｒｍｅｄ”応答を受信する場合には、バッファリング機能を必要とする。
【００５２】
一方、ＳＩＰ ＩＮＶＩＴＥ要請信号に対する応答信号を受信した後に、送信側ＰｏＣクライアントは、トークバースト送信許可信号、例えば、リングバックトーンを伝達するための発言権許可信号を、ＲＴＣＰを介して受信する。発言権許可信号は、トークバースト仲裁権限を有するＣＦにより生成され、対応するＰｏＣクライアントを管理するＰＦを介してＰｏＣクライアントに送信される。この際、発言権許可信号は、ＳＩＰプロトコルを使用せず、ベアラー経路を使用するため、ＩＭＳのようなＳＩＰ／ＩＰコアネットワークを迂回して送信されることができる。リングバックトーンを確認したＰｏＣクライアントは、メディア、例えば音声のストリームを、ＲＴＰを用いて伝達する。
【００５３】
本発明の実施形態は、上述したＰｏＣシステムの構成を参照して説明する。ＰｏＣクライアントＡは、クライアントＢ、Ｃ、及びＤを含むアドホックグループセッションの確立を希望する。一方、ＰｏＣクライアントＢがＰｏＣサーバＢと事前設定セッションを確立しており、ＰｏＣサーバＢ（すなわち、ＰＦ Ｂ）において、上述した自動応答モードを応答モードとして確立していると仮定する。このような仮定の下で、本発明は、ＰｏＣクライアントＢとＰｏＣサーバＢとの間で確立された応答モード及び事前設定セッションを使用し、ＰｏＣサーバがアドホックグループ内の招待されたクライアントであるＰｏＣクライアントＣ及びＤのＰｏＣ識別子情報をＰｏＣクライアントＢに提供することを可能にする。また、本発明は、ＰｏＣクライアントＢのユーザーが対応するアドホックグループセッション内の招待者情報を識別した後に、次のセッション確立手続きを進行するようにする方法を提供する。
【００５４】
ＰｏＣサーバがアドホックグループ招待者情報を対応するＰｏＣクライアントに提供し、このアドホックグループ招待者情報を受信したＰｏＣクライアントがセッションの確立を受諾するか又は拒絶する応答に従って、ＰｏＣサーバとＰｏＣクライアントとの間で送受信される信号のフローについては、図４及び図５を参照して具体的に説明する。
【００５５】
また、本発明は、従来の事前設定セッション及び自動応答モードで発生し得るＰｏＣサーバとＵＥとの間での応答モード不一致環境でメディアの無条件的な送信を防止するための技術であるレースコンディション（race condition）を招待者情報確認メッセージとして使用する手続きを提供する。図４は、本発明の実施形態に従って、送信側ＰｏＣネットワークでアドホックグループ招待者情報を含んでセッションを要請し、受信側ＰｏＣサーバ及びＰｏＣクライアントの機能及び信号のフローを示す。ここで、ＰｏＣクライアントＡがＰｏＣユーザーＡ、Ｂ、Ｃ、及びＤを含むアドホックグループセッションの確立を希望し、ＰｏＣサーバＢとＰｏＣクライアントＢとの間で事前設定セッションが確立されており、ＰｏＣサーバＢの応答モードが自動応答モードに確立されていると仮定する。
【００５６】
ＰｏＣクライアントＡは、ステップ４００で、このアドホックグループセッションに招待されるＰｏＣユーザーＡ、Ｂ、Ｃ、及びＤに関する情報を含むＳＩＰ ＩＮＶＩＴＥメッセージをＰｏＣクライアントＡのホームネットワークでのＰｏＣサーバＡに送信する。この際に、ＰｏＣサーバＡは、アドホックグループの特性に従って、制御ＰｏＣサーバＸとしても機能するので、物理的な構成の観点で１つのサーバとして実現されることができる。本発明は、個別の制御ＰｏＣサーバＸを含む場合について説明する。下記では、ステップ４０２で、ＰｏＣサーバＡからＩＮＶＩＴＥメッセージを受信した制御ＰｏＣサーバＸがＩＮＶＩＴＥメッセージをこのアドホックグループセッションの招待者の中でＰｏＣクライアントＢに送信する場合について説明する。
【００５７】
ステップ４０４で、受信側ＰｏＣサーバＢが対応するグループの招待者情報を含むＩＮＶＩＴＥメッセージを受信する場合には、受信側ＰｏＣサーバＢは、受信側ＰｏＣクライアントＢと確立された応答モード及び事前設定セッション、そして、招待されたＰｏＣユーザーの識別子情報を確認する。
【００５８】
事前設定セッションが提案されたメディアパラメータを用いて活用されることができ、応答モードが自動応答モードに設定された場合には、ＰｏＣサーバＢは、ステップ４０６乃至ステップ４１０を介して２００ ＯＫメッセージをＰｏＣクライアントＡに送信する。次いで、受信側ＰｏＣサーバＢは、ステップ４１２で、対応する招待者に関する情報を含むＲＴＣＰ接続メッセージを生成した後に、ステップ４１６で、この事前設定セッションのダイアローグ内に送信する。この際、ステップ４１２で、受信側ＰｏＣサーバＢは、受信側ユーザーの確認をＲＴＣＰ接続メッセージに要請するように、ＰｏＣクライアントＢの設定された応答モードを無視し、強制的に受動応答を指示する自動応答無視（Auto-Answer Override：以下、“ＡＡＯ”と称する。）要請パラメータを挿入してもよい。
【００５９】
また、ＰｏＣサーバＢは、ＲＴＣＰ接続メッセージを送信した後に、ステップ４１４で、ＲＴＣＰ接続メッセージの満了のためのタイマーＡを動作させ、成功的な応答メッセージがＰｏＣクライアントＢから受信されるまで発言権許可（floor grant）及び／またはメディアストリーム送信を保留してもよい。ＲＴＣＰ応答メッセージが受信されない場合には、ＰｏＣサーバＢは、タイマーＡが満了しない範囲内で接続メッセージを再要請するためのタイマーであるタイマーＢを動作させることにより、ＲＴＣＰ接続メッセージを再送信することができる。この際、ＰｏＣサーバＢがタイマーＡ及びタイマーＢが駆動されている間にＲＴＣＰ応答メッセージを受信するか、又は事前設定セッションが解除される場合には、ＰｏＣサーバＢは、タイマーの駆動を終了させる。また、ＰｏＣサーバＢは、タイマーＢが満了するまでセッション内のメディア送信を保留する。
【００６０】
一方、ステップ４１６で、ＰｏＣサーバＢから送信されたＲＴＣＰ接続メッセージを受信しているＰｏＣクライアントＢは、ステップ４１８で、ＰｏＣユーザーがＲＴＣＰ接続メッセージに含まれているアドホックグループ招待者情報を確認することができるようにした後に、ステップ４１８で、ユーザーが入力した応答の受諾又は拒絶を確認し、ユーザーの応答に従うＲＴＣＰ接続メッセージに応じるＲＴＣＰ応答メッセージを返信する。
【００６１】
一方、図４の手続きは、ステップ４１８で、ＰｏＣユーザーがセッション確立の受諾を選択する場合を示す。したがって、ＰｏＣクライアントＢは、ステップ４２０で、セッション成功メッセージをＰｏＣサーバＢに送信し、これにより、ピアツーピア（peer-to-peer）ＰｏＣセッションが確立される。ステップ４２２で、発言権を与えられたＰｏＣクライアントＡは、ステップ４２５及びステップ４２６で、実際のＲＴＰメディアをＰｏＣクライアントＢに送信する。受信側ＰｏＣクライアントＢは、ＰｏＣクライアントＡから送信されたメディアストリームを受信し、受信されたメディアストリームを実時間で自動再生するか、又はディスプレーする。
【００６２】
図５は、図４のステップ４１６で受信されたＲＴＣＰ接続メッセージを通じてアドホックグループ招待者情報を確認したＰｏＣユーザーが対応するセッションへの参加を拒絶する場合のセッション進行手続きを示す。この際、図５のステップ５００、ステップ５０２、ステップ５０４、ステップ５０６、ステップ５０８、ステップ５１０、ステップ５１２、ステップ５１４、ステップ５１６、及びステップ５１８は、図４のステップ４００、ステップ４０２、ステップ４０４、ステップ４０６、ステップ４０８、ステップ４１０、ステップ４１２、ステップ４１４、ステップ４１６、及びステップ４１８とそれぞれ同一の手続きを有する。一方、ステップ５１６の後に、ＰｏＣユーザーがアドホックグループ招待者情報を確認した後に、セッション接続を拒絶する場合には、ＰｏＣクライアントＢは、セッション拒絶パラメータを含むＲＴＣＰ応答メッセージをＰｏＣサーバＢに送信する。この招待者情報を確認した後に、ＰｏＣユーザーは、セッション参加を拒絶したことを通知することができる。このように、セッション参加を拒絶したことを通知するための参加拒絶理由コードを挿入する具体的な方法については、図８を参照して説明する。
【００６３】
一方、ステップ５２０で、ＰｏＣクライアントＢから送信されたメッセージに含まれているセッション拒絶応答に従って、ＰｏＣサーバＢは、ステップ５２６、ステップ５３０、及びステップ５３１を介してＳＩＰ ＢＹＥメッセージをＰｏＣクライアントＡに送信することにより、セッション接続が拒絶されたことをＰｏＣクライアントＡに通知する。すなわち、ステップ５０６乃至ステップ５１０を介して確立されたＳＩＰセッションは、ステップ５２６乃至ステップ５３２を介して対応するアドホックグループから解除される。また、この際に送信されたＲＴＰメディアストリームは、セッション解除によりＰｏＣクライアントＢに送信されない。この際に、サーバ側タイマーＡ及びタイマーＢは、図４のタイマーＡ及びタイマーＢと同一の機能を実行するように動作する。
【００６４】
一方、図４及び図５を参照して説明したＲＴＣＰ接続メッセージに含まれている招待者情報を表現するための具体的なフォーマット及びＡＡＯパラメータについては、図７及び図８を参照して説明する。この際、ＡＡＯパラメータは、受信側ＰｏＣクライアントの応答手続きを改善させるためにＲＴＣＰ接続メッセージに選択的に含まれている。
【００６５】
本発明は、ＲＴＣＰ接続メッセージを使用するアドホックグループ招待者情報を伝達し、ＡＡＯ機能を用いてレースコンディション（すなわち、ＵＥとサーバとの間の応答モードの不一致）を考慮してセッション確立手続きを改善するための方法を提供し、これを図６に示す。
【００６６】
ＰｏＣクライアントＡは、ステップ６００乃至ステップ６０４を介して招待者情報を含むＩＮＶＩＴＥメッセージをＰｏＣサーバＢに伝達する。その後、招待者情報を含むＩＮＶＩＴＥメッセージを受信したＰｏＣサーバＢは、ステップ６０６で、事前設定セッション及び応答モードが確立されたか否かを確認し、ＲＴＣＰ接続メッセージに含まれる招待者情報及びＡＡＯパラメータを生成する。また、ＰｏＣサーバＢは、ステップ６０８で、ＲＴＣＰ接続及び応答メッセージを処理するために、図４及び図５を参照して説明したタイマーＡ及びタイマーＢと同一の機能を実行するサーバ側タイマーＡ及びタイマーＢを駆動させる。タイマーＡは、ＲＴＣＰ応答メッセージがセッション進行手続きで受信されなかった場合には、上述したメディアストリームを遮断する機能に加えて、４ＸＸエラー応答を発生するように設計されている。また、タイマーＢは、図４と同様に、ＲＴＣＰ応答が受信されなかった場合には、ＲＴＣＰ接続メッセージを再送信するために動作する。
【００６７】
その後、ＰｏＣサーバＢは、ステップ６０６で生成された招待者情報及びＡＡＯパラメータを含むＲＴＣＰ接続メッセージをステップ６１０でＰｏＣクライアントに送信する。ＲＴＣＰ接続メッセージを受信したＰｏＣクライアントＢは、ＰｏＣユーザーがＡＡＯパラメータに基づいて招待者情報を確認することができるようにした後に、ステップ６１２で、ＰｏＣユーザーが入力したセッション確立に対する応答を確認する。
【００６８】
ステップ６１２で、ＰｏＣユーザーがこのアドホックグループセッションの確立を拒絶することを決定する場合には、ステップ６１４で、ＰｏＣクライアントＢは、拒絶理由を含むＲＴＣＰ応答メッセージをＰｏＣサーバＢに送信する。一方、タイマーＡが満了する前にＰｏＣサーバＢがステップ６１４で送信されたメッセージを受信するか、又はＰｏＣサーバＢがステップ６１４で送信されたメッセージを受信する前にタイマーＡが満了する場合には、ＰｏＣサーバＢは、ステップ６１６を介してセッションエラー応答を送信側ネットワークに送信する。この後に、ＰｏＣクライアントＡは、ステップ６１８におけるように、招待者情報を含む他のセッション確立動作を独立して遂行してもよい。
【００６９】
図６は、ＰｏＣユーザーが招待者情報を確認した後に、ＰｏＣユーザーの決定に従って事前設定セッション及び自動応答モードでのセッションを確立する手続きを示す図である。
【００７０】
一方、図４乃至図６において、セッションＩＮＶＩＴＥメッセージを受信したＰｏＣサーバＢは、アドホックグループ招待者情報を含む上述したメッセージの応答モードを決定する個別のアクセス規則又はサービスセッティングに従って自動応答手続き又は受動応答手続きを実行してもよい。ＸＤＭサーバに格納されているアクセス規則は、この招待者情報を含むセッションＩＮＶＩＴＥメッセージが受信される際に、自動応答モードが許可されるか否かに関する規則文書を含むことがある。この際、この招待者情報アクセス規則がこの自動応答モードを許可しない場合には、ＰｏＣサーバは、対応するクライアントに対して格納されている応答モードを無視し、受動応答モードを採用する。具体的に、この招待者情報アクセス規則は、“ＰｏＣユーザーアクセスポリシー”で＜ａｃｔｉｏｎ＞エレメントとして含まれる。＜ａｃｔｉｏｎ＞エレメントがアドホックグループ招待者情報を含むセッションＩＮＶＩＴＥメッセージに対して自動応答モードを許可しない場合には、ＰｏＣサーバは、内部に格納されている自動応答モードサービスセッティングを無視し、受動応答手続きを取り、ＳＩＰメッセージを用いて受信された招待者情報を伝達する。
【００７１】
図７は、本発明の実施形態による図４乃至図６を参照して説明したＲＴＣＰ接続メッセージのフォーマットを示す図である。一般的なＲＴＣＰ ＡＰＰメッセージのフォーマットに基づくＲＴＣＰ接続メッセージは、この招待者情報の伝達を識別するために、ソースディスクリプション（ＳＤＥＳ）アイテムコンテンツフィールド内の“ＳＤＥＳアイテムコンテンツ＝‘ＸＸＸＸＦＹＹＹＹＹＹＹＹＹＹ’”のような２進データを含む。“ＸＸＸＸ”フィールドは、従来技術に含まれているセッション開始者の識別子（ＩＤ）情報、セッション、又はＰｏＣグループなどが存在することを示すのに使用されてもよい。“Ｆ”フィールドは、“Ｆ”フィールドが“１”の値を有する場合には、グループセッション又はアドホックグループセッションの招待者情報がＲＴＣＰ接続メッセージのＳＤＥＳアイテムフィールドに含まれていることを示す。また、上述したように、“Ｆ”フィールドが“１”の値を有するように設定される場合には、対応する招待者のユニフォームリソース識別子（ＵＲＩ）アドレス情報がＳＤＥＳアイテムフィールドに含まれる。
【００７２】
対応する招待者情報がＳＤＥＳアイテムフィールドに含まれている際に、ＵＲＩアドレス情報が特定のＰｏＣユーザー又はＰｏＣサービスオペレータの要請により匿名で表記されるように設定される場合には、ＵＲＩアドレス情報は、受信側ＰｏＣクライアントに伝達されない。匿名に要請された招待者のＵＲＩアドレス情報の代わりに、匿名アイデンティティに関する情報及び匿名要請者の数は、受信側ＰｏＣユーザーに提供されてもよい。
【００７３】
次いで、ＡＡＯ要請パラメータは、追加指示子フィールドに含まれてもよい。すなわち、図７において、“Ａｄｄ．Ｉｎｄｉｃ．＝‘ｘａｙｙｙｙｙｙ’が追加される場合には、“１”の値を有する“ａ”フィールドは、ＲＴＣＰ接続メッセージが“自動応答無視（ＡＡＯ）”動作を示すメッセージとして動作するようにする。ＰｏＣクライアントがこのようなパラメータを含むＲＴＣＰ接続メッセージを受信する場合には、ＰｏＣクライアントは、ＰｏＣユーザーが所定の応答モードに関係なく受動応答をするようにする。
【００７４】
一方、本発明の範囲がメッセージ名に限定されず、ＲＴＣＰ接続メッセージは、ＲＴＣＰ ＡＰＰのフォーマットに基づくように定義された任意のユーザープレーンメッセージに修正されるか又は変更されてもよい。例えば、ＲＴＣＰ接続メッセージは、ＰｏＣ２．０で定義されたようなトークバースト（ＴＢ）接続メッセージに追加のフィールドとして挿入されてもよく、又はあらかじめＴＢ接続又はＭＢ接続メッセージで示されてもよく、“ＭＢＣＰ Ｉｎｆｏｒｍ”メッセージのような新たなメッセージ形態で伝達されてもよい。アドホックグループセッションの招待者情報が含まれていることを知らせるための“Ｆ”フィールド及び／又はユーザーが受動で応答することを要請するための“ａ”フィールドは、ユーザープレーンメッセージ内の他のタイプのオプションフィールドとして表現されてもよいのは、自明な事実である。
【００７５】
図８は、本発明の実施形態による図４乃至６を参照して説明したＲＴＣＰ応答（ＡＣＫ）メッセージのフォーマットを示す図である。招待者情報及び受動応答要請メッセージがＰｏＣサーバＢからＰｏＣクライアントＢに伝達された後に、ＰｏＣユーザーがセッション招待を拒絶する場合には、ＰｏＣクライアントは、このような拒絶理由を含むＲＴＣＰ応答メッセージを送信することにより、セッション招待に応じる“リンギング（ringing）”応答を送信側ネットワークに返信してもよく、又は拒絶理由を含むＳＩＰエラー応答を返信してもよい。このために、招待者識別の不可能を示すフィールド値は、図８に示すようなＲＴＣＰ ＡＣＫ応答メッセージ内の理由コードで定義される。
【００７６】
また、本発明は、図４の基本手続きにおいて、ＰｏＣサーバとＰｏＣクライアントとの間のアドホックグループ招待者情報に関するサービスセッティングに基づいて、ＰｏＣサーバとＰｏＣクライアントとの間の接続メッセージを処理する手続きを提供する。まず、ＰｏＣクライアントＢは、アドホックグループ招待者情報の受信が可能であるか、又は、招待者情報の使用を希望するサービスセッティング（例えば、Invitee Parties Identity Information Mode active）をＰｏＣサーバＢに設定する。この際、招待者情報サービスセッティングは、ＳＩＰ ＰＵＢＬＩＳＨ方式を使用して実現されてもよく、サービスセッティングに対する既存のＸＭＬスキーマを拡張することにより実現されてもよい。一方、格納されているサービスセッティング値の中で招待者情報受信モードの値が“真（true）”である場合には、この招待者情報を含むアドホックグループセッション招待メッセージを受信したＰｏＣサーバＢは、ＲＴＣＰ接続メッセージのフォーマットに従ってこの招待者情報の修正及び変更を行い、このアドホックグループセッション招待メッセージを受信側ＰｏＣクライアントに送信する。他方、サービスセッティング値の中で、招待者情報受信モードの値が“偽（false）”である場合には、ＰｏＣサーバＢは、関連する招待者情報を含まないＲＴＣＰ接続メッセージを受信側ＰｏＣクライアントに送信する。
【００７７】
以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び精神を逸脱することなく様々な変形が可能であるということは、当該技術分野における通常の知識を持つ者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。
【符号の説明】
【００７８】
１００ ＰｏＣ ＵＥ
１０２ ＰｏＣクライアント
１０４ ＸＤＭクライアント
１１０ アクセスネットワーク
１２０ コアネットワーク
１３０ ＸＭＬ文書管理サーバ
１４０ ＸＭＬ文書管理サーバ
１５０ ＰｏＣサーバ
１６０ アグリゲーションプロキシサーバ
１７０ 遠隔ＰｏＣネットワーク
３００ ＣＦ
３１０ ＰＦ
【技術分野】
【０００１】
本発明は、プッシュツートークオーバーセルラー（Push to Talk Over Cellular：以下、“ＰｏＣ”と称する。）システムにおけるアドホックＰｏＣグループセッションを確立する際に、グループ招待者情報を受信側ＰｏＣクライアントに伝達するための方法及びシステムに関する。
【背景技術】
【０００２】
移動通信技術の画期的な発展及び通信網の拡大に伴って、携帯電話を用いたより拡張された様々なサービス及びアプリケーションが提供されている。また、ユーザーの要求も多様化されており、基本的な通話サービスを越えて、位置サービス、マルチメディアサービス、ＰＴＴ（Push To Talk）サービスなどに拡大されている。特に、ＰＴＴサービスは、従来の無線電信又は基盤無線システム（Trunked Radio System：ＴＲＳ）により提供されたグループ通話及び音声通話だけではなく、インスタントメッセンジャー及び状態表示のような様々な付加機能をサポートする。
【０００３】
現在では、このようなＰＴＴ概念を、移動通信網を用いてサービスするＰｏＣサービスを標準化することが活発に論議されている。従来の移動通信サービスと区別されるＰｏＣサービスの特徴の１つは、ユーザーが、必要に応じて複数のセッション間を移動しながら通話することができることにある。ユーザーが複数のセッションを移動しながら通話可能でなければならないという要求事項は、関連移動通信サービスを定義している団体であるオープンモバイルアライアンス（Open Mobile Alliance：ＯＭＡ）のＰｏＣ規格１．０の要求事項に明示されている。
【０００４】
ＰｏＣ１．０規格に従うと、ＰｏＣセッションは、実時間でＰｏＣセッションに参加したＰｏＣクライアントにだけメディアデータを送信する方式で確立される。このような特性に従うと、バッテリー放電又は不在などによってＰｏＣセッションに参加できないユーザーは、１対１ＰｏＣセッション又はグループＰｏＣセッションで送信される音声のようなメディアストリームを受信することができない。すなわち、ＰｏＣ１．０技術は、従来の通信システムでサポートされたボイスメールボックス機能をサポートしない。
【０００５】
一方、ＰｏＣ１．０規格は、任意のユーザーリストを対象グループとして指定するアドホックグループセッションモードをサポートする。この際、各受信側ＰｏＣクライアントは、アドホックグループセッションに招待されるユーザーに関する情報を受信することができないので、この招待されるユーザーに関する情報を取得する前に、このアドホックグループセッションに参加しなければならないという問題点がある。したがって、受信側ユーザーをセッションに招待する際に、受信側ユーザーがセッションに参加するか否かを決定するために必要とされる上述したようなアドホックグループセッションに招待された全てのユーザーに関する情報を受信側ユーザーに伝達するための方案がＰｏＣ２．０で要求事項として明示されている。
【０００６】
一方、ＰｏＣ１．０規格は、事前設定セッション及び自動応答モードなどをサポートすることにより、セッション確立の手続きを簡素化させる。上述したように、事前設定セッション及び自動応答モードをすべてサポートするＰｏＣクライアント及びＰｏＣサーバがこのアドホックグループセッションに対するセッション招待メッセージを受信した場合には、ＰｏＣクライアント及びＰｏＣサーバは、セッション参加成功メッセージを送信側ＰｏＣネットワークに送信することにより、各対応するユーザーの確認なしに即座に応答する。これは、ＰｏＣサーバがＳＩＰ成功メッセージを応答として直接送信する場合に、ＳＩＰメッセージが受信側ＰｏＣサーバとＰｏＣクライアントとの間のＳＩＰメッセージ交換手続きを簡素化し、したがって、セッション設定時間を短縮させる長所があるためである。しかしながら、従来の技術で提供された事前設定セッション及び自動応答モードは、このアドホックグループセッションの確立の際に、グループ招待者情報を伝達するメッセージを提供することができず、受信側ＰｏＣユーザーが招待者情報の確認を要請することができないという短所があった。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
したがって、本発明は、上述した従来技術の問題点を解決するために提案されたものであり、その目的は、自動応答モード及び受信側ＰｏＣクライアントとの事前設定セッションを確立したＰｏＣサーバがアドホックグループセッションに関する招待者情報を含むセッション招待メッセージを受信した場合には、事前設定セッションを用いてアドホックグループセッションに関する招待者情報を伝達するための方法及びシステムを提供することにある。
【０００８】
本発明の他の目的は、受信側ＰｏＣサーバが対応する招待者情報を送信する際に、受信側ＰｏＣクライアントの応答モードに関係なく、ユーザーがセッションに参加するか否かを識別するための方法及びシステムを提供することにある。
【０００９】
本発明のまた他の目的は、ＰｏＣクライアントがアドホックグループセッションに参加するか又は拒絶する場合に、送信側へのＳＩＰ及び実時間転送プロトコル（ＲＴＰ）メディア送信を効率的に処理するためのシグナリングのための方法及びシステムを提供することにある。
【００１０】
本発明のさらなる目的は、アドホックグループセッションに関する招待者情報を伝達する方法においてＰｏＣクライアント及びＰｏＣサーバのアルゴリズム及び機能を実現するための方法及びシステムを提供することにある。
【課題を解決するための手段】
【００１１】
上記のような目的を達成するために、本発明の実施形態の一態様によれば、受信側プッシュツートーク（ＰＴＴ）オーバーセルラー（ＰｏＣ）クライアントと受信側ＰｏＣサーバとの間で事前設定セッション及び自動応答モードが設定され、ＰｏＣアドホックグループセッションの確立の際に、アドホックグループセッション招待者情報を上記受信側ＰｏＣクライアントに提供し、上記提供された招待者情報に従うセッション設定を行うＰｏＣシステムにおけるＰｏＣアドホックグループセッション情報を処理するシステムであって、上記アドホックグループ招待者情報を含むセッション招待メッセージが送信側ネットワークから受信された場合には、上記招待者情報及び自動応答無視（ＡＡＯ）要請パラメータを含む接続メッセージを生成し、上記生成された接続メッセージを上記受信側ＰｏＣクライアントに伝達した後に、上記ＰｏＣクライアントから受信された応答に従ってＰｏＣセッション手続きを実行する上記ＰｏＣサーバと、上記接続メッセージを受信した場合には、上記接続メッセージに含まれている招待者情報をＰｏＣユーザーに伝達するように、現在設定されている応答モードに関係なく手動応答モードに進入し、上記ＰｏＣユーザーから入力される上記セッション参加の受諾又は拒絶に関する情報を含む応答メッセージを上記ＰｏＣサーバに伝達する上記ＰｏＣクライアントと、を具備することを特徴とする。
【００１２】
本発明の実施形態の他の態様によれば、受信側プッシュツートーク（ＰＴＴ）オーバーセルラー（ＰｏＣ）クライアントと受信側ＰｏＣサーバとの間で事前設定セッション及び自動応答モードが設定されたＰｏＣシステムにおいて、ＰｏＣアドホックグループセッションの確立の際に、アドホックグループセッション招待者情報を上記受信側ＰｏＣクライアントに提供し、上記提供された招待者情報に従うセッション設定を行うＰｏＣアドホックグループセッション情報を処理する方法であって、上記ＰｏＣサーバが上記アドホックグループ招待者情報を含むセッション招待メッセージを送信側ネットワークから受信した場合には、上記招待者情報及び自動応答無視（ＡＡＯ）要請パラメータを含む接続メッセージを生成し、上記生成された接続メッセージを上記受信側ＰｏＣクライアントに伝達するステップと、上記ＰｏＣクライアントが上記接続メッセージを受信した場合には、上記接続メッセージに含まれている招待者情報をＰｏＣユーザーに伝達するように、現在設定されている応答モードに関係なく手動応答モードに進入するステップと、上記ＰｏＣクライアントが上記ＰｏＣユーザーから入力される上記セッション参加の受諾又は拒絶に関する情報を含む応答メッセージを上記ＰｏＣサーバに伝達するステップと、上記ＰｏＣサーバが上記ＰｏＣクライアントから受信された応答に従ってＰｏＣセッション手続きを実行するステップと、を具備することを特徴とする。
【００１３】
本発明の実施形態のさらに他の態様によれば、上記接続メッセージ内のＡＡＯ要請パラメータを選択的に含むことができる。
【００１４】
本発明の実施形態のさらなる他の態様によれば、ＰｏＣ ＵＥがユーザー確認メッセージを送信する時点に従って上記事前設定セッション及び自動応答の際のアドホックＰｏＣグループセッション確立手続きを改善させる手続きを含む。
【００１５】
本発明の実施形態のさらに他の１つの態様によれば、受信側プッシュツートーク（ＰＴＴ）オーバーセルラー（ＰｏＣ）クライアントと受信側ＰｏＣサーバとの間で事前設定セッション及び自動応答モードが設定されたＰｏＣシステムにおいて、ＰｏＣアドホックグループセッションの確立の際に、アドホックグループセッション招待者情報を上記受信側ＰｏＣクライアントに提供し、上記提供された招待者情報に従うセッション設定を行うために、上記ＰｏＣサーバが上記アドホックグループ招待者情報を含むセッション招待メッセージを送信側ネットワークから受信した場合には、受信側ＰｏＣクライアントと受信側ＰｏＣサーバとの間で事前設定されたサービスセッティングに従ってセッション招待メッセージに含まれているアドホックグループ招待者情報を処理する方法を提供する。すなわち、上記アドホックグループ招待者情報処理方法は、上記受信側ＰｏＣクライアントが上記アドホックグループ招待者情報の受信をサポートする事前設定サービスの受信に設定されている場合には、上記招待者情報を含む接続メッセージを生成し、上記受信側ＰｏＣクライアントに伝達するステップと、上記受信側ＰｏＣクライアントが上記接続メッセージを受信した場合には、上記接続メッセージに含まれている招待者情報をＰｏＣユーザーに伝達するステップと、上記受信側ＰｏＣクライアントが上記ＰｏＣユーザーから入力されるセッション参加の受諾又は拒絶に関する情報を含む応答メッセージを上記ＰｏＣサーバに伝達するステップと、上記ＰｏＣサーバが上記受信側ＰｏＣクライアントから受信された応答に従ってＰｏＣセッション手続きを実行するステップと、を具備することを特徴とする。
【００１６】
本発明の実施形態のさらにまた他の態様によれば、受信側ＰｏＣクライアントとＰｏＣサーバとの間で事前設定セッション及び自動応答モードが設定されている場合には、事前設定セッションを用いてアドホックグループセッションに関する招待者情報を伝達する方法を提供する。また、本発明は、上記事前設定セッションを介したユーザープレーンシグナリングを活用し、受信側ＰｏＣユーザーの意思を反映するセッション確立を進行するために、ＰｏＣクライアントが設定した応答モードを管理するアドホックグループセッション確立手続きを提供する。
【発明の効果】
【００１７】
本発明は、事前設定セッション及び自動応答モードを使用するように設定されたＰｏＣ ＵＥとＰｏＣサーバとの間で、事前設定セッションを介して伝達されるＲＴＣＰメッセージを用いてアドホックグループセッションに関する招待者情報を伝達するための方法と、受信側ＰｏＣユーザーの選択に基づいてセッション参加の受諾又は拒絶に対する手続きを実行する方法を提供する。また、本発明によれば、上述したシナリオでアドホックグループのセッション招待者情報又は匿名ユーザーの数を識別することができ、これにより、ＰｏＣユーザーがセッションに参加するか否かを決定することができる。さらに、本発明によれば、ＰｏＣシステムは、応答モードの不一致によるＲＴＰメディアストリームの伝達を管理することができ、同時に、ＰｏＣセッションの迅速な確立を提供することができる。
【図面の簡単な説明】
【００１８】
【図１】従来のＰｏＣサービスシステムの構成を示す図である。
【図２】従来のＰｏＣサーバの機能を示す図である。
【図３】ＰｏＣサーバのＣＦ部及びＰＦ部を含むグループセッションの構成を示す図である。
【図４】本発明の第１の実施形態によるＰｏＣサーバでアドホックグループ招待者情報を送受信する場合におけるＰｏＣユーザーによるセッション確立応答に従って処理される信号のフローを示す図である。
【図５】本発明の第１の実施形態によるＰｏＣサーバでアドホックグループ招待者情報を送受信する場合におけるＰｏＣユーザーによるセッション拒絶応答に従って処理される信号のフローを示す図である。
【図６】本発明の第２の実施形態によるＰｏＣサーバでアドホックグループ招待者情報を送受信する場合におけるＰｏＣユーザーによるセッション拒絶応答に従って処理される改善した信号のフローを示す図である。
【図７】図４に示したＰｏＣサーバとユーザー端末機（ＵＥ）との間で送信されるＲＴＣＰ接続メッセージのフォーマットを示す図である。
【図８】図４に示したＰｏＣサーバとＵＥとの間で送信されるＲＴＣＰ応答（ＡＣＫ）メッセージのフォーマットを示す図である。
【発明を実施するための形態】
【００１９】
以下、本発明の好適な一実施形態を、添付図面を参照しつつ詳細に説明する。下記の説明において、本発明は、プッシュツートーク（Push to Talk：以下、“ＰＴＴ”と称する。）システム、特に、セルラー移動通信網を介してＰＴＴサービスを提供するプッシュツートークオーバーセルラー（PTT Over Cellular：以下、“ＰｏＣ”と称する。）システムに適用される場合を例に挙げて説明する。一般的に、ＰｏＣシステムは、グループ通話に関するセッション参加情報を伝達するために、セッション開始プロトコル（Session Initiation Protocol：以下、“ＳＩＰ”と称する。）及びＳＩＰ拡張プロトコルを使用し、グループ情報を取得するために、拡張可能なマークアップ言語（eXtensible markup language：ＸＭＬ）設定アクセスプロトコル（XML Configuration Access Protocol：以下、“ＸＣＡＰ”と称する。）を使用する。また、ＲＴＰ／ＲＴＣＰプロトコルは、確立されたセッション内で実時間メディア送信及び管理のために使用され、トークバーストコントロールプロトコル（Talk Burst Control Protocol：以下、“ＴＢＣＰ”と称する。）と呼ばれる実時間ＲＴＣＰ基盤専用プロトコルは、ＰＴＴサービスの特徴である発言権管理のために定義され使用される。特に、本発明は、ＰｏＣサーバとユーザー端末機（User Equipment：以下、“ＵＥ”と称する。）との間の事前設定セッションを用いて招待者情報を伝達するために、ＲＴＣＰ ＡＰＰの形態を有するＴＢＣＰメッセージ又は新たに設定されたＭＢＣＰメッセージを使用する。
【００２０】
本発明の下記の実施形態は、上述したプロトコルにより実現されることができ、本発明の基本的な構成は、ＰｏＣ Ｒｅｌ．１システムに基づいており、ＰｏＣ Ｂｏｘ又は拡張された概念のＸＭＬ文書管理（XML Document Management：以下、“ＸＤＭ”と称する。）サーバで記述されることができる。
【００２１】
まず、下記では、本発明が適用される一般的なＰｏＣシステムについて説明する。
【００２２】
図１は、従来のＰｏＣサービスシステム及び関連ネットワークの構成を示す図である。ＰｏＣシステムは、ＰｏＣ ＵＥ１００と、ＸＭＬ文書管理サーバ（XML Document Management Server：ＸＤＭＳ）１３０及び１４０と、ＰｏＣサーバ１５０とを含む。また、ＰｏＣシステムは、アグリゲーションプロキシサーバ１６０をさらに含んでもよい。上述した構成要素は、アクセスネットワーク１１０と、ＳＩＰ／インターネットプロトコル（Internet Protocol：ＩＰ）コアネットワーク１２０又は遠隔ＰｏＣネットワーク１７０とを介して相互に接続される。
【００２３】
ＰｏＣ ＵＥ１００は、ＰｏＣクライアント１０２とＸＤＭクライアント１０４とを含む。
【００２４】
ＰｏＣ ＵＥ１００に含まれているサービス要請者を示すＰｏＣクライアント１０２は、ＰｏＣ ＵＥ１００に滞在し、ＰｏＣサービスをＰｏＣ ＵＥ１００を介してＰｏＣサービス加入者に提供するためのネットワーク接続を遂行する。ＰｏＣサービス加入者は、ＰｏＣクライアントが内蔵されているＰｏＣ ＵＥを介してＰｏＣサービスの提供を受けることができる。下記の説明において、“ＰｏＣクライアント”という用語は、ＰｏＣクライアントが内蔵されているＵＥ及びＰｏＣサービス加入者を総称する。また、ＰｏＣクライアントの参照符号は、特に区別されるべき場合のない限り省略する。
【００２５】
ＰｏＣクライアントは、ＰｏＣサービス加入者（すなわち、ＰｏＣユーザー）がＰｏＣセッションの確立、すでに確立されているセッションの参加、又は確立されているセッションの終了を可能にするために主に使用される。また、ＰｏＣクライアントは、トークバーストを生成し送信する機能、インスタントパーソナルアラート（Instant Personal alert）をサポートする機能、及びＰｏＣサービスへのアクセスを認証する機能を有する。ＰｏＣクライアントは、アクセスネットワーク１１０を介してＳＩＰ／ＩＰマルチメディアをサポートするＳＩＰ／ＩＰコアネットワーク１２０に接続されることもある。
【００２６】
ＰｏＣクライアントは、アクセスネットワーク１１０を介してＳＩＰ／ＩＰマルチメディアサービスをサポートするのに重要な役割を果たすＳＩＰ／ＩＰコアネットワーク１２０に接続される。ＳＩＰ／ＩＰコアネットワーク１２０は、ＰｏＣサーバ１５０とＸＤＭＳ１３０及び１４０とに接続されることにより、ＰｏＣサービスをサポートする。この際、ＰｏＣサーバ１５０は、ＰｏＣセッションの維持及び管理を行うための制御ＰｏＣ機能（Controlling PoC Function）を行うことができ、１対１通話や多者間通話のために確立されるＰｏＣセッションに参加するための参加ＰｏＣ機能（Participating PoC Function）を行うことができる。
【００２７】
一方、ＰｏＣサービスは、コンファレンス通話のようなグループセッションを確立するサービスを伴うことができる。このために、ＯＭＡ標準は、グループリストサービスのためのＸＤＭクライアント１０４とＸＤＭＳ１３０及び１４０とを定義する。図１は、ＰｏＣサービスのために使用されるＰｏＣ ＸＤＭＳ１４０及び他のサービスイネーブラ（service enabler）にも共通に使用されることができる共用ＸＤＭＳ（Shared XDMS）１３０を示す。グループ及びグループメンバーに関する情報は、ＰｏＣクライアントを介してＸＤＭＳ１３０及び１４０に格納されることができる。ＰｏＣクライアント１０２は、ＸＤＭＳ１３０及び１４０から受信された個人又はグループのリストから、自身が呼び出すことができる他のＰｏＣクライアントに関する情報を取得する。一方、ＸＤＭＳ１３０及び１４０に格納されているグループ及びグループメンバー情報の生成、修正、及び管理は、インターネット又はイントラネットのようなＰｏＣサービスプロバイダーが信頼できる通信網を介してなされることもできる。ＸＭＬ文書を管理するためのプロトコル（例えば、グループリストの生成、修正、及び削除）は、本発明とは直接関連しないので、明瞭性のために省略する。
【００２８】
グループサービスのために、ＸＤＭクライアント１０４からグループリストに関連した要請を受信すると、アグリゲーションプロキシサーバ１６０は、適切な規則に従って、上記要請を各ＸＤＭＳ１３０及び１４０にルーティングする。
【００２９】
次いで、ＰｏＣサーバ１５０について説明する。
【００３０】
図２は、従来のＰｏＣサーバの構成を示す図である。ＰｏＣサーバの機能は、ＰｏＣセッションの全般的な維持及び管理を担当する制御ＰｏＣ機能（Controlling PoC Function：以下、“ＣＦ”と称する。）と各ＰｏＣセッションのための維持及び管理を担当する参加ＰｏＣ機能（Participating PoC Function：以下、“ＰＦ”と称する。）とに区分されることができる。下記の＜表１＞及び＜表２＞を参照して、ＰｏＣサーバの各機能に従う特性について説明する。
【００３１】
【表１】
【００３２】
上述した＜表１＞に示すように、ＣＦは、ＰｏＣサーバの機能の中で、ＰｏＣセッションの総体的な管理を意味する。特に、ＣＦは、ＰｏＣクライアントの発言権（floor）要請を受け入れ、その順序を定めて発言権をこのクライアントに付与する。また、ＣＦは、特定のＰｏＣクライアントからのトークバースト（talk burst）をグループＰｏＣ呼出しに参加した他のＰｏＣクライアントに分配し、グループＰｏＣ呼出しに参加したＰｏＣクライアントに関する情報を提供する。
【００３３】
下記の＜表２＞に示すように、ＰＦは、ＰｏＣセッションの間に、ＣＦと各ＰｏＣクライアントとの間に接続されたセッションの管理に関する。特に、ＰＦは、ＣＦでＰｏＣクライアントへの発言権の付与だけではなく、ＰｏＣクライアントの発言権の要請を中継する。また、ＰＦは、ＣＦとＰｏＣクライアントとの間のメディア中継機能、及び両者が異なるコーデック（codecs）を使用する場合にこれらをトランスコーディングする機能を担当する。さらに、他のトークバーストが同時多重セッションで発生している間に、トークバーストが１つのセッションで発生される場合には、ＰＦは、ユーザーの選択に従ってこれらの中の１つをフィルタリングするフィルタリング機能を担当する。
【００３４】
【表２】
【００３５】
図３は、グループセッションでＰｏＣ ＵＥとＰｏＣサーバとの接続を示し、特に、ＰｏＣサーバの機能に従ってＣＦ部とＰＦ部とを区分して説明する。
【００３６】
図３を参照すると、各ＰｏＣクライアント１００-Ａ乃至１００-Ｄは、ＰＦ３１０-Ａ乃至３１０-Ｄを介してＣＦ３００に接続される。この後、ＣＦ３００から発言権を与えられたＰｏＣクライアントの対応するトークバーストに対応するメディアが他のＰｏＣクライアントに送信される。この際、この発言権を有するＰｏＣクライアントは、グループセッションに参加しているＰｏＣクライアントに関する情報を確認するまで、適切なトークバーストをすることができない。
【００３７】
一方、ＰｏＣシステムにおいて、通話接続のための呼処理技術は、送信側及び受信側の要請及び状況に基づいて様々な手続きが可能である。ＯＭＡに基づいて、このような送信側及び受信側の設定に従って必要とされるＰｏＣシステムの特徴は、次の通りである。
【００３８】
第１に、受信側は、ＰｏＣクライアントの要請に応じて、自身の応答モードを設定することができ、自動応答モード及び手動応答モードに分類することができる。自動応答モードにおいては、送信側が受信側で予め定めたＰｏＣクライアントリストに含まれている場合には、受信側の手動応答の代わりに、対応するネットワークから送信側に応答を即座に送る。ＵＥを動作させず、ネットワークにより送られるこのような自動応答は、ＰｏＣサーバが、ＵＥの応答モード設定要請に従って、応答モード及び対応するユーザーリストに関する情報を格納することができるという事実に基づいている。他方、手動応答モードは、送信側が自動応答ユーザーリストに含まれていない場合、送信側が自動応答ユーザーリストに含まれているか否かが不明確な場合、又は受信側が全てのユーザーに手動応答モードを設定する場合に対応する。手動応答モードにおいて、ＰｏＣ通話要請は、受信ネットワークを介してＵＥに送信され、呼は、ＰｏＣクライアントの許可の後に接続される。
【００３９】
第２に、ＰｏＣシステムは、ＰｏＣユーザーのホームネットワーク内のＰｏＣサーバとの接続設定に基づいて、オンデマンド（on-demand）セッションモードと事前設定（pre-established）セッションモードとを有することができる。事前設定セッションモードにおいて、ＰｏＣクライアントが、自身の要請に応じて、ＰｏＣクライアントとユーザーのホームネットワークに属しているＰｏＣサーバとの間で事前にセッションを設定しておく。このような事前設定セッションは、将来使われるＰｏＣサーバとクライアントとの間のメディアパラメータを反復して交渉する必要がなく、迅速なセッション確立を行うことができるように、ＰｏＣクライアントが使用するメディアパラメータをＰｏＣサーバと事前に交渉する必要がある。
【００４０】
事前設定セッションを確立するために、ＰｏＣクライアントは、ＳＩＰ ＩＮＶＩＴＥ方法を使用することにより、セッション記述プロトコル多目的インターネットメール拡張（Session Description Protocol Multipurpose Internet Mail Extension：ＳＤＰ ＭＩＭＥ）のボディーを介してサーバが提供し、ＰｏＣクライアントがサポートしたメディアパラメータ、及びこのサーバが提供したメディアパラメータに対する応答を提供する。このサーバから応答メッセージを受信すると、この応答メッセージは、新たに事前設定されるセッションの識別情報、例えば、コンファレンス識別子（conference URI）とともにＰｏＣクライアントに返信される。
【００４１】
上述した事前設定セッションを使用する場合には、ＩＰアドレス、ポート番号、使用されるコーデック、及びトークバースト制御プロトコルなどの事前交渉が可能である。オンデマンドセッションモードは、任意のＰｏＣクライアントが事前設定セッションを確立しない場合に対応する。したがって、ＰｏＣクライアントは、招待メッセージを他のＰｏＣクライアントから受信した後に、ＰｏＣ呼を接続するための手続きを実行する。
【００４２】
ＰｏＣシステムにおいて、通話要請に関する応答モードの設定は、ネットワーク上のエレメントであるＰｏＣサーバ及びＵＥであるＰｏＣクライアントですべて格納されることができる。
【００４３】
応答モードがＰｏＣクライアントを管理するホームネットワークに設定される場合には、ＰｏＣクライアントが属しているホームネットワーク内でＰＦを有するＰｏＣサーバで実現される。
【００４４】
応答モードがネットワークに設定された場合には、ＰＦは、セッションプログレスメッセージを、通話を要請したネットワークに送信することにより、ＰｏＣ通話のための他のＰｏＣサーバの要請に自動で応答する。したがって、自動応答モードが設定された場合には、セッション設定メッセージがＰｏＣクライアントに伝達された後に応答が送信される場合に比べて、呼要請手続きが簡素化され、これにより、発言権を付与するのに必要とされる初期時間を短縮させる。
【００４５】
しかしながら、ネットワークで自動応答を遂行する場合には、状況に応じて、ユーザーの応答とは異なる結果をもたらすことがあり得る。したがって、ＰｏＣクライアントにも応答モードが設定されることができる。この際、ＰｏＣクライアントの応答モードがネットワーク上に設定された応答モードに優先するという特徴がある。これは、ＰｏＣクライアントが自身の応答モードを変更し、応答モードを更新することをＰｏＣサーバに要請したが、信号遅延又はネットワーク上のエラーにより実時間で応答モードが更新されない際に発生するプライバシー問題を解決するためである。
【００４６】
要約すると、ＰｏＣサービスに対するユーザーの応答モードがＰｏＣサーバ及びＰｏＣクライアントにすべて設定されることができるが、応答モードは、ユーザーの最も最近の意思を反映したＰｏＣクライアントにより決定され、このような決定に基づいて、実際のユーザーの音声又は映像などのようなメディアのストリームが伝達される。
【００４７】
上述したような特徴を有するＰｏＣシステムでのＰｏＣマルチメディアセッションを確立する手続きについて説明する。
【００４８】
送信側ＰｏＣクライアントは、ＳＩＰプロトコルを使用してマルチメディア招待メッセージを送信することにより、呼処理を要請する。この際、このマルチメディアは、メディアタイプの指定に従って、様々なフォーマットを有するオーディオ、ビデオ、及びテキストなどを含んでもよい。このような呼処理要請に応じて、受信側クライアントは、対応するＰｏＣサーバでの応答モードの設定及び事前設定セッションが確立されたか否かに基づいて、様々な応答手続きを実行する。ＰｏＣ通話のための呼処理手続きについては、送信側及び受信側の１つのネットワークを用いて説明する。
【００４９】
送信側ＰｏＣクライアントは、自身が通信を希望する受信側ＰｏＣクライアントのＳＩＰアドレス情報を含むＳＩＰ ＩＮＶＩＴＥ要請を対応するＳＩＰ／ＩＰコアネットワークに送信する。この際、ＳＩＰ ＩＮＶＩＴＥメッセージは、送信側ＰｏＣクライアントのＰｏＣアドレス情報、要求されるメディアパラメータ、及びＰｏＣサービスを識別する特性値情報などのようなエレメントをさらに含むことができる。ここで、“要求されるメディアパラメータ”は、要求されるセッションがマルチメディアセッションに関連する場合には、オーディオ及びビデオに関するエンコーディング方法、レート、及びペイロードタイプなどを示す複数の特性値を含むことができる。
【００５０】
ＳＩＰ ＩＮＶＩＴＥメッセージは、ダイナミックホストコンフィギュレーションプロトコル（Dynamic Host Configuration Protocol：ＤＨＣＰ）サーバ又はドメインネームサーバ（Domain Name Server：ＤＮＳ）における経路クエリー（query）に基づいて、インターネットプロトコルマルチメディアサブシステム（IP Multimedia Subsystem：ＩＭＳ）ネットワーク内の対応するＩＭＳサーバ、すなわち、プロキシ呼セッション制御機能（Proxy Call Session Control Function：Ｐ-ＣＳＣＦ）及びサービング呼サーバ制御機能（Serving-Call Server Control Function：Ｓ-ＣＳＣＦ）を介して参加ＰｏＣサーバに伝達される。一般的な通話が要請される際には、ＰｏＣクライアントが接続された参加ＰｏＣサーバは、確立されたセッションのトークバーストを管理する制御ＰｏＣサーバと個別に実現されることができ、これにより、ＰＦサーバに送信されたＳＩＰ ＩＮＶＩＴＥ要請は、対応するネットワークのＳＩＰ／ＩＰコアネットワークを介してＣＦサーバに伝達される。
【００５１】
一方、ＣＦを含むＰｏＣセッション制御ネットワークは、ＳＩＰ ＩＮＶＩＴＥ要請メッセージを受信側ネットワークに伝達した後に、受信側ネットワークから応答メッセージを受信する。受信側ネットワークから応答するＳＩＰメッセージは、受信側ＰｏＣクライアント及びＰＦの設定に基づいて、１ｘｘの臨時応答メッセージ、２ｘｘの成功応答メッセージ、又は４ＸＸ〜６ＸＸのエラー応答メッセージの中の１つであり得る。自動応答モードの場合には、ＳＩＰ １８３“セッションプログレス”信号が応答メッセージとして受信されることができ、このメッセージを介して通話要請者のＩＭＳネットワークでＰｏＣサーバとクライアントとの間の接続を行うことができる。受信側ＰｏＣクライアントの通話許可信号として、ＳＩＰ １８３セッションプログレス又はＳＩＰ ２００ ＯＫ応答は、ＣＦ及びＰＦのＰｏＣサーバを介してＰｏＣクライアントに送信される。受信側ＰｏＣサーバから１８３セッションプログレス信号又は２００ ＯＫ応答を受信すると、ＣＦは、ＰｏＣ呼が接続されたことを確認し、発言権許可信号（floor granted signal）を送信側ＰｏＣクライアントに送信することにより、トークバーストの発言権を付与する。上記応答、すなわち、ＳＩＰ ２００ ＯＫ又は１８３セッションプログレス信号に従ってトークバーストの発言権を付与することは、“ｃｏｎｆｉｒｍｅｄ”又は“ｕｎｃｏｎｆｉｒｍｅｄ”を使用して識別されることができる。ＣＦが“ｕｎｃｏｎｆｉｒｍｅｄ”応答を受信する場合には、バッファリング機能を必要とする。
【００５２】
一方、ＳＩＰ ＩＮＶＩＴＥ要請信号に対する応答信号を受信した後に、送信側ＰｏＣクライアントは、トークバースト送信許可信号、例えば、リングバックトーンを伝達するための発言権許可信号を、ＲＴＣＰを介して受信する。発言権許可信号は、トークバースト仲裁権限を有するＣＦにより生成され、対応するＰｏＣクライアントを管理するＰＦを介してＰｏＣクライアントに送信される。この際、発言権許可信号は、ＳＩＰプロトコルを使用せず、ベアラー経路を使用するため、ＩＭＳのようなＳＩＰ／ＩＰコアネットワークを迂回して送信されることができる。リングバックトーンを確認したＰｏＣクライアントは、メディア、例えば音声のストリームを、ＲＴＰを用いて伝達する。
【００５３】
本発明の実施形態は、上述したＰｏＣシステムの構成を参照して説明する。ＰｏＣクライアントＡは、クライアントＢ、Ｃ、及びＤを含むアドホックグループセッションの確立を希望する。一方、ＰｏＣクライアントＢがＰｏＣサーバＢと事前設定セッションを確立しており、ＰｏＣサーバＢ（すなわち、ＰＦ Ｂ）において、上述した自動応答モードを応答モードとして確立していると仮定する。このような仮定の下で、本発明は、ＰｏＣクライアントＢとＰｏＣサーバＢとの間で確立された応答モード及び事前設定セッションを使用し、ＰｏＣサーバがアドホックグループ内の招待されたクライアントであるＰｏＣクライアントＣ及びＤのＰｏＣ識別子情報をＰｏＣクライアントＢに提供することを可能にする。また、本発明は、ＰｏＣクライアントＢのユーザーが対応するアドホックグループセッション内の招待者情報を識別した後に、次のセッション確立手続きを進行するようにする方法を提供する。
【００５４】
ＰｏＣサーバがアドホックグループ招待者情報を対応するＰｏＣクライアントに提供し、このアドホックグループ招待者情報を受信したＰｏＣクライアントがセッションの確立を受諾するか又は拒絶する応答に従って、ＰｏＣサーバとＰｏＣクライアントとの間で送受信される信号のフローについては、図４及び図５を参照して具体的に説明する。
【００５５】
また、本発明は、従来の事前設定セッション及び自動応答モードで発生し得るＰｏＣサーバとＵＥとの間での応答モード不一致環境でメディアの無条件的な送信を防止するための技術であるレースコンディション（race condition）を招待者情報確認メッセージとして使用する手続きを提供する。図４は、本発明の実施形態に従って、送信側ＰｏＣネットワークでアドホックグループ招待者情報を含んでセッションを要請し、受信側ＰｏＣサーバ及びＰｏＣクライアントの機能及び信号のフローを示す。ここで、ＰｏＣクライアントＡがＰｏＣユーザーＡ、Ｂ、Ｃ、及びＤを含むアドホックグループセッションの確立を希望し、ＰｏＣサーバＢとＰｏＣクライアントＢとの間で事前設定セッションが確立されており、ＰｏＣサーバＢの応答モードが自動応答モードに確立されていると仮定する。
【００５６】
ＰｏＣクライアントＡは、ステップ４００で、このアドホックグループセッションに招待されるＰｏＣユーザーＡ、Ｂ、Ｃ、及びＤに関する情報を含むＳＩＰ ＩＮＶＩＴＥメッセージをＰｏＣクライアントＡのホームネットワークでのＰｏＣサーバＡに送信する。この際に、ＰｏＣサーバＡは、アドホックグループの特性に従って、制御ＰｏＣサーバＸとしても機能するので、物理的な構成の観点で１つのサーバとして実現されることができる。本発明は、個別の制御ＰｏＣサーバＸを含む場合について説明する。下記では、ステップ４０２で、ＰｏＣサーバＡからＩＮＶＩＴＥメッセージを受信した制御ＰｏＣサーバＸがＩＮＶＩＴＥメッセージをこのアドホックグループセッションの招待者の中でＰｏＣクライアントＢに送信する場合について説明する。
【００５７】
ステップ４０４で、受信側ＰｏＣサーバＢが対応するグループの招待者情報を含むＩＮＶＩＴＥメッセージを受信する場合には、受信側ＰｏＣサーバＢは、受信側ＰｏＣクライアントＢと確立された応答モード及び事前設定セッション、そして、招待されたＰｏＣユーザーの識別子情報を確認する。
【００５８】
事前設定セッションが提案されたメディアパラメータを用いて活用されることができ、応答モードが自動応答モードに設定された場合には、ＰｏＣサーバＢは、ステップ４０６乃至ステップ４１０を介して２００ ＯＫメッセージをＰｏＣクライアントＡに送信する。次いで、受信側ＰｏＣサーバＢは、ステップ４１２で、対応する招待者に関する情報を含むＲＴＣＰ接続メッセージを生成した後に、ステップ４１６で、この事前設定セッションのダイアローグ内に送信する。この際、ステップ４１２で、受信側ＰｏＣサーバＢは、受信側ユーザーの確認をＲＴＣＰ接続メッセージに要請するように、ＰｏＣクライアントＢの設定された応答モードを無視し、強制的に受動応答を指示する自動応答無視（Auto-Answer Override：以下、“ＡＡＯ”と称する。）要請パラメータを挿入してもよい。
【００５９】
また、ＰｏＣサーバＢは、ＲＴＣＰ接続メッセージを送信した後に、ステップ４１４で、ＲＴＣＰ接続メッセージの満了のためのタイマーＡを動作させ、成功的な応答メッセージがＰｏＣクライアントＢから受信されるまで発言権許可（floor grant）及び／またはメディアストリーム送信を保留してもよい。ＲＴＣＰ応答メッセージが受信されない場合には、ＰｏＣサーバＢは、タイマーＡが満了しない範囲内で接続メッセージを再要請するためのタイマーであるタイマーＢを動作させることにより、ＲＴＣＰ接続メッセージを再送信することができる。この際、ＰｏＣサーバＢがタイマーＡ及びタイマーＢが駆動されている間にＲＴＣＰ応答メッセージを受信するか、又は事前設定セッションが解除される場合には、ＰｏＣサーバＢは、タイマーの駆動を終了させる。また、ＰｏＣサーバＢは、タイマーＢが満了するまでセッション内のメディア送信を保留する。
【００６０】
一方、ステップ４１６で、ＰｏＣサーバＢから送信されたＲＴＣＰ接続メッセージを受信しているＰｏＣクライアントＢは、ステップ４１８で、ＰｏＣユーザーがＲＴＣＰ接続メッセージに含まれているアドホックグループ招待者情報を確認することができるようにした後に、ステップ４１８で、ユーザーが入力した応答の受諾又は拒絶を確認し、ユーザーの応答に従うＲＴＣＰ接続メッセージに応じるＲＴＣＰ応答メッセージを返信する。
【００６１】
一方、図４の手続きは、ステップ４１８で、ＰｏＣユーザーがセッション確立の受諾を選択する場合を示す。したがって、ＰｏＣクライアントＢは、ステップ４２０で、セッション成功メッセージをＰｏＣサーバＢに送信し、これにより、ピアツーピア（peer-to-peer）ＰｏＣセッションが確立される。ステップ４２２で、発言権を与えられたＰｏＣクライアントＡは、ステップ４２５及びステップ４２６で、実際のＲＴＰメディアをＰｏＣクライアントＢに送信する。受信側ＰｏＣクライアントＢは、ＰｏＣクライアントＡから送信されたメディアストリームを受信し、受信されたメディアストリームを実時間で自動再生するか、又はディスプレーする。
【００６２】
図５は、図４のステップ４１６で受信されたＲＴＣＰ接続メッセージを通じてアドホックグループ招待者情報を確認したＰｏＣユーザーが対応するセッションへの参加を拒絶する場合のセッション進行手続きを示す。この際、図５のステップ５００、ステップ５０２、ステップ５０４、ステップ５０６、ステップ５０８、ステップ５１０、ステップ５１２、ステップ５１４、ステップ５１６、及びステップ５１８は、図４のステップ４００、ステップ４０２、ステップ４０４、ステップ４０６、ステップ４０８、ステップ４１０、ステップ４１２、ステップ４１４、ステップ４１６、及びステップ４１８とそれぞれ同一の手続きを有する。一方、ステップ５１６の後に、ＰｏＣユーザーがアドホックグループ招待者情報を確認した後に、セッション接続を拒絶する場合には、ＰｏＣクライアントＢは、セッション拒絶パラメータを含むＲＴＣＰ応答メッセージをＰｏＣサーバＢに送信する。この招待者情報を確認した後に、ＰｏＣユーザーは、セッション参加を拒絶したことを通知することができる。このように、セッション参加を拒絶したことを通知するための参加拒絶理由コードを挿入する具体的な方法については、図８を参照して説明する。
【００６３】
一方、ステップ５２０で、ＰｏＣクライアントＢから送信されたメッセージに含まれているセッション拒絶応答に従って、ＰｏＣサーバＢは、ステップ５２６、ステップ５３０、及びステップ５３１を介してＳＩＰ ＢＹＥメッセージをＰｏＣクライアントＡに送信することにより、セッション接続が拒絶されたことをＰｏＣクライアントＡに通知する。すなわち、ステップ５０６乃至ステップ５１０を介して確立されたＳＩＰセッションは、ステップ５２６乃至ステップ５３２を介して対応するアドホックグループから解除される。また、この際に送信されたＲＴＰメディアストリームは、セッション解除によりＰｏＣクライアントＢに送信されない。この際に、サーバ側タイマーＡ及びタイマーＢは、図４のタイマーＡ及びタイマーＢと同一の機能を実行するように動作する。
【００６４】
一方、図４及び図５を参照して説明したＲＴＣＰ接続メッセージに含まれている招待者情報を表現するための具体的なフォーマット及びＡＡＯパラメータについては、図７及び図８を参照して説明する。この際、ＡＡＯパラメータは、受信側ＰｏＣクライアントの応答手続きを改善させるためにＲＴＣＰ接続メッセージに選択的に含まれている。
【００６５】
本発明は、ＲＴＣＰ接続メッセージを使用するアドホックグループ招待者情報を伝達し、ＡＡＯ機能を用いてレースコンディション（すなわち、ＵＥとサーバとの間の応答モードの不一致）を考慮してセッション確立手続きを改善するための方法を提供し、これを図６に示す。
【００６６】
ＰｏＣクライアントＡは、ステップ６００乃至ステップ６０４を介して招待者情報を含むＩＮＶＩＴＥメッセージをＰｏＣサーバＢに伝達する。その後、招待者情報を含むＩＮＶＩＴＥメッセージを受信したＰｏＣサーバＢは、ステップ６０６で、事前設定セッション及び応答モードが確立されたか否かを確認し、ＲＴＣＰ接続メッセージに含まれる招待者情報及びＡＡＯパラメータを生成する。また、ＰｏＣサーバＢは、ステップ６０８で、ＲＴＣＰ接続及び応答メッセージを処理するために、図４及び図５を参照して説明したタイマーＡ及びタイマーＢと同一の機能を実行するサーバ側タイマーＡ及びタイマーＢを駆動させる。タイマーＡは、ＲＴＣＰ応答メッセージがセッション進行手続きで受信されなかった場合には、上述したメディアストリームを遮断する機能に加えて、４ＸＸエラー応答を発生するように設計されている。また、タイマーＢは、図４と同様に、ＲＴＣＰ応答が受信されなかった場合には、ＲＴＣＰ接続メッセージを再送信するために動作する。
【００６７】
その後、ＰｏＣサーバＢは、ステップ６０６で生成された招待者情報及びＡＡＯパラメータを含むＲＴＣＰ接続メッセージをステップ６１０でＰｏＣクライアントに送信する。ＲＴＣＰ接続メッセージを受信したＰｏＣクライアントＢは、ＰｏＣユーザーがＡＡＯパラメータに基づいて招待者情報を確認することができるようにした後に、ステップ６１２で、ＰｏＣユーザーが入力したセッション確立に対する応答を確認する。
【００６８】
ステップ６１２で、ＰｏＣユーザーがこのアドホックグループセッションの確立を拒絶することを決定する場合には、ステップ６１４で、ＰｏＣクライアントＢは、拒絶理由を含むＲＴＣＰ応答メッセージをＰｏＣサーバＢに送信する。一方、タイマーＡが満了する前にＰｏＣサーバＢがステップ６１４で送信されたメッセージを受信するか、又はＰｏＣサーバＢがステップ６１４で送信されたメッセージを受信する前にタイマーＡが満了する場合には、ＰｏＣサーバＢは、ステップ６１６を介してセッションエラー応答を送信側ネットワークに送信する。この後に、ＰｏＣクライアントＡは、ステップ６１８におけるように、招待者情報を含む他のセッション確立動作を独立して遂行してもよい。
【００６９】
図６は、ＰｏＣユーザーが招待者情報を確認した後に、ＰｏＣユーザーの決定に従って事前設定セッション及び自動応答モードでのセッションを確立する手続きを示す図である。
【００７０】
一方、図４乃至図６において、セッションＩＮＶＩＴＥメッセージを受信したＰｏＣサーバＢは、アドホックグループ招待者情報を含む上述したメッセージの応答モードを決定する個別のアクセス規則又はサービスセッティングに従って自動応答手続き又は受動応答手続きを実行してもよい。ＸＤＭサーバに格納されているアクセス規則は、この招待者情報を含むセッションＩＮＶＩＴＥメッセージが受信される際に、自動応答モードが許可されるか否かに関する規則文書を含むことがある。この際、この招待者情報アクセス規則がこの自動応答モードを許可しない場合には、ＰｏＣサーバは、対応するクライアントに対して格納されている応答モードを無視し、受動応答モードを採用する。具体的に、この招待者情報アクセス規則は、“ＰｏＣユーザーアクセスポリシー”で＜ａｃｔｉｏｎ＞エレメントとして含まれる。＜ａｃｔｉｏｎ＞エレメントがアドホックグループ招待者情報を含むセッションＩＮＶＩＴＥメッセージに対して自動応答モードを許可しない場合には、ＰｏＣサーバは、内部に格納されている自動応答モードサービスセッティングを無視し、受動応答手続きを取り、ＳＩＰメッセージを用いて受信された招待者情報を伝達する。
【００７１】
図７は、本発明の実施形態による図４乃至図６を参照して説明したＲＴＣＰ接続メッセージのフォーマットを示す図である。一般的なＲＴＣＰ ＡＰＰメッセージのフォーマットに基づくＲＴＣＰ接続メッセージは、この招待者情報の伝達を識別するために、ソースディスクリプション（ＳＤＥＳ）アイテムコンテンツフィールド内の“ＳＤＥＳアイテムコンテンツ＝‘ＸＸＸＸＦＹＹＹＹＹＹＹＹＹＹ’”のような２進データを含む。“ＸＸＸＸ”フィールドは、従来技術に含まれているセッション開始者の識別子（ＩＤ）情報、セッション、又はＰｏＣグループなどが存在することを示すのに使用されてもよい。“Ｆ”フィールドは、“Ｆ”フィールドが“１”の値を有する場合には、グループセッション又はアドホックグループセッションの招待者情報がＲＴＣＰ接続メッセージのＳＤＥＳアイテムフィールドに含まれていることを示す。また、上述したように、“Ｆ”フィールドが“１”の値を有するように設定される場合には、対応する招待者のユニフォームリソース識別子（ＵＲＩ）アドレス情報がＳＤＥＳアイテムフィールドに含まれる。
【００７２】
対応する招待者情報がＳＤＥＳアイテムフィールドに含まれている際に、ＵＲＩアドレス情報が特定のＰｏＣユーザー又はＰｏＣサービスオペレータの要請により匿名で表記されるように設定される場合には、ＵＲＩアドレス情報は、受信側ＰｏＣクライアントに伝達されない。匿名に要請された招待者のＵＲＩアドレス情報の代わりに、匿名アイデンティティに関する情報及び匿名要請者の数は、受信側ＰｏＣユーザーに提供されてもよい。
【００７３】
次いで、ＡＡＯ要請パラメータは、追加指示子フィールドに含まれてもよい。すなわち、図７において、“Ａｄｄ．Ｉｎｄｉｃ．＝‘ｘａｙｙｙｙｙｙ’が追加される場合には、“１”の値を有する“ａ”フィールドは、ＲＴＣＰ接続メッセージが“自動応答無視（ＡＡＯ）”動作を示すメッセージとして動作するようにする。ＰｏＣクライアントがこのようなパラメータを含むＲＴＣＰ接続メッセージを受信する場合には、ＰｏＣクライアントは、ＰｏＣユーザーが所定の応答モードに関係なく受動応答をするようにする。
【００７４】
一方、本発明の範囲がメッセージ名に限定されず、ＲＴＣＰ接続メッセージは、ＲＴＣＰ ＡＰＰのフォーマットに基づくように定義された任意のユーザープレーンメッセージに修正されるか又は変更されてもよい。例えば、ＲＴＣＰ接続メッセージは、ＰｏＣ２．０で定義されたようなトークバースト（ＴＢ）接続メッセージに追加のフィールドとして挿入されてもよく、又はあらかじめＴＢ接続又はＭＢ接続メッセージで示されてもよく、“ＭＢＣＰ Ｉｎｆｏｒｍ”メッセージのような新たなメッセージ形態で伝達されてもよい。アドホックグループセッションの招待者情報が含まれていることを知らせるための“Ｆ”フィールド及び／又はユーザーが受動で応答することを要請するための“ａ”フィールドは、ユーザープレーンメッセージ内の他のタイプのオプションフィールドとして表現されてもよいのは、自明な事実である。
【００７５】
図８は、本発明の実施形態による図４乃至６を参照して説明したＲＴＣＰ応答（ＡＣＫ）メッセージのフォーマットを示す図である。招待者情報及び受動応答要請メッセージがＰｏＣサーバＢからＰｏＣクライアントＢに伝達された後に、ＰｏＣユーザーがセッション招待を拒絶する場合には、ＰｏＣクライアントは、このような拒絶理由を含むＲＴＣＰ応答メッセージを送信することにより、セッション招待に応じる“リンギング（ringing）”応答を送信側ネットワークに返信してもよく、又は拒絶理由を含むＳＩＰエラー応答を返信してもよい。このために、招待者識別の不可能を示すフィールド値は、図８に示すようなＲＴＣＰ ＡＣＫ応答メッセージ内の理由コードで定義される。
【００７６】
また、本発明は、図４の基本手続きにおいて、ＰｏＣサーバとＰｏＣクライアントとの間のアドホックグループ招待者情報に関するサービスセッティングに基づいて、ＰｏＣサーバとＰｏＣクライアントとの間の接続メッセージを処理する手続きを提供する。まず、ＰｏＣクライアントＢは、アドホックグループ招待者情報の受信が可能であるか、又は、招待者情報の使用を希望するサービスセッティング（例えば、Invitee Parties Identity Information Mode active）をＰｏＣサーバＢに設定する。この際、招待者情報サービスセッティングは、ＳＩＰ ＰＵＢＬＩＳＨ方式を使用して実現されてもよく、サービスセッティングに対する既存のＸＭＬスキーマを拡張することにより実現されてもよい。一方、格納されているサービスセッティング値の中で招待者情報受信モードの値が“真（true）”である場合には、この招待者情報を含むアドホックグループセッション招待メッセージを受信したＰｏＣサーバＢは、ＲＴＣＰ接続メッセージのフォーマットに従ってこの招待者情報の修正及び変更を行い、このアドホックグループセッション招待メッセージを受信側ＰｏＣクライアントに送信する。他方、サービスセッティング値の中で、招待者情報受信モードの値が“偽（false）”である場合には、ＰｏＣサーバＢは、関連する招待者情報を含まないＲＴＣＰ接続メッセージを受信側ＰｏＣクライアントに送信する。
【００７７】
以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び精神を逸脱することなく様々な変形が可能であるということは、当該技術分野における通常の知識を持つ者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。
【符号の説明】
【００７８】
１００ ＰｏＣ ＵＥ
１０２ ＰｏＣクライアント
１０４ ＸＤＭクライアント
１１０ アクセスネットワーク
１２０ コアネットワーク
１３０ ＸＭＬ文書管理サーバ
１４０ ＸＭＬ文書管理サーバ
１５０ ＰｏＣサーバ
１６０ アグリゲーションプロキシサーバ
１７０ 遠隔ＰｏＣネットワーク
３００ ＣＦ
３１０ ＰＦ
【特許請求の範囲】
【請求項１】
送信側ＰｏＣ(Push-to-Talk(PTT)-over-Cellular)クライアント、送信側ＰｏＣサーバ、受信側ＰｏＣクライアント、及び受信側ＰｏＣサーバを含むＰｏＣシステムにおいて、前記受信側ＰｏＣクライアントが前記送信側ＰｏＣクライアントによって要求されたグループセッションを開設する方法であって、
前記グループセッションに招待された少なくとも一つのユーザーリストを含む招待者情報を受信するためのサービスセッティングの登録を前記受信側ＰｏＣサーバに要求するステップと、
前記受信側ＰｏＣサーバから、前記サービスセッティングを考慮して生成されたＲＴＣＰ(Real-Time Control Protocol)接続メッセージを受信するステップと、
前記ＲＴＣＰ接続メッセージで前記招待者情報を確認し、前記招待者情報をユーザーに提供するステップと、
前記ユーザーから前記グループセッションの開設が許可されるか否かの入力を受信するステップと、
前記グループセッションの開設が許可されたか否かの入力を含むＲＴＣＰ応答を生成し、前記受信側ＰｏＣサーバに前記ＲＴＣＰ応答を伝送するステップと、
を具備することを特徴とする方法。
【請求項２】
前記ＲＴＣＰ接続メッセージは、前記招待者情報を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記ＲＴＣＰ接続メッセージは、前記受信側ＰｏＣクライアントの応答モード設定に関係なく強制的に手動応答を指示する自動応答無視(ＡＡＯ)要求パラメータをさらに含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記サービスセッティングは、前記招待者情報が受信されたか否かを指示する値を含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記ＲＴＣＰ応答メッセージは、前記グループセッション開設の許可を指示する情報を含み、
前記送信側ＰｏＣクライアントからメディアストリームを受信して前記ユーザーに提供するステップをさらに具備することを特徴とする請求項１に記載の方法。
【請求項６】
前記ＲＴＣＰ応答メッセージは、前記グループセッション開設の拒絶を指示する情報を含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記ＲＴＣＰ応答メッセージは、ユーザーによって前記グループセッション開設の拒絶を指示する理由コードをさらに含むことを特徴とする請求項６に記載の方法。
【請求項８】
送信側ＰｏＣ(Push-to-Talk(PTT)-over-Cellular)クライアント、送信側ＰｏＣサーバ、受信側ＰｏＣクライアント、及び受信側ＰｏＣサーバを含むＰｏＣシステムにおいて、前記受信側ＰｏＣクライアントが前記送信側ＰｏＣクライアントによって要求されたグループセッションを開設する方法であって、
招待者情報を含むインバイトメッセージを受信するステップと、
予め登録された前記受信側ＰｏＣクライアントのサービスセッティングを確認するステップと、
前記確認したサービスセッティングによって前記招待者情報を選択的に含むことによりＲＴＣＰ(Real-Time Control Protocol)接続メッセージを生成するステップと、
前記ＲＴＣＰ接続メッセージを前記受信側ＰｏＣクライアントに伝送するステップと、
前記ＲＴＣＰ接続メッセージに対するＲＴＣＰ応答メッセージを受信するステップと、
を具備することを特徴とする方法。
【請求項９】
前記サービスセッティングは、前記招待者情報が受信されたか否かを指示する値を含むことを特徴とする請求項８に記載の方法。
【請求項１０】
前記招待者情報は、前記グループセッションに招待された少なくとも一つのユーザーリストを含むことを特徴とする請求項８に記載の方法。
【請求項１１】
前記ＲＴＣＰ接続メッセージは、前記受信側ＰｏＣクライアントの応答モード設定に関係なく強制的に手動応答を指示する自動応答無視(ＡＡＯ)要求パラメータをさらに含むことを特徴とする請求項８に記載の方法。
【請求項１２】
前記ＲＴＣＰ応答メッセージが前記グループセッション開設の許可を指示する情報を含む場合に、
前記送信側ＰｏＣクライアントとのセッションを開設するステップと、
前記開設されたセッションで、前記送信側ＰｏＣクライアントからメディアストリームを受信して前記受信側ＰｏＣクライアントに伝送するステップと、
をさらに具備することを特徴とする請求項８に記載の方法。
【請求項１３】
前記ＲＴＣＰ応答メッセージが前記グループセッション開設の拒絶を指示する情報を含む場合に、
前記送信側ＰｏＣクライアントとのセッションを解除するステップをさらに具備することを特徴とする請求項８に記載の方法。
【請求項１４】
前記受信側ＰｏＣクライアントとの応答モードを確認するステップと、
前記応答モードが自動応答モードに設定される場合に、前記インバイトメッセージに対する応答メッセージを伝送するステップと、
をさらに具備することを特徴とする請求項８に記載の方法。
【請求項１５】
前記ＲＴＣＰ応答メッセージは、ユーザーによって前記グループセッション開設の拒絶を指示する理由コードをさらに含むことを特徴とする請求項１３に記載の方法。
【請求項１６】
送信側ＰｏＣ(Push-to-Talk(PTT)-over-Cellular)サーバに接続され、送信側ネットワークによって要求されるグループセッションの開設を制御する受信側ＰｏＣクライアントであって、
前記グループセッションに招待されたユーザーリストを含む招待者情報を受信するためのサービスセッティングの登録を前記受信側ＰｏＣサーバに要求し、
前記受信側ＰｏＣサーバから、前記サービスセッティングを考慮して生成されたＲＴＣＰ(Real-Time Control Protocol)接続メッセージを受信し、
前記ＲＴＣＰ接続メッセージで前記招待者情報を確認し、前記招待者情報をユーザーに提供し、
前記ユーザーから前記グループセッションの開設が許可されるか否かの入力を受信し、前記グループセッションの開設が許可されたか否かの入力を含むＲＴＣＰ応答を生成し、
前記受信側ＰｏＣサーバに前記ＲＴＣＰ応答を伝送する制御部を含むことを特徴とする受信側ＰｏＣクライアント。
【請求項１７】
前記サービスセッティングは、前記招待者情報が受信されたか否かを指示する値を含むことを特徴とする請求項１６に記載の受信側ＰｏＣクライアント。
【請求項１８】
前記制御部は、
前記グループセッション開設の許可を指示する入力を受信する場合に、前記グループセッション開設の許可を指示する情報を前記ＲＴＣＰ応答メッセージに含め、前記送信側ネットワークから受信されるメディアストリームを提供し、
前記グループセッション開設の拒絶を指示する入力を受信する場合には、前記グループセッション開設の拒絶を指示する情報を前記ＲＴＣＰ応答メッセージに含めることを特徴とする請求項１９に記載の受信側ＰｏＣクライアント。
【請求項１９】
送信側ネットワークから要求される受信側ＰｏＣ(Push-to-Talk(PTT)-over-Cellular)クライアントとのグループセッションを開設する受信側ＰｏＣサーバであって、
招待者情報を含むインバイトメッセージを受信し、
予め登録された前記受信側ＰｏＣクライアントのサービスセッティングを確認し、
前記確認したサービスセッティングによって前記招待者情報を選択的に含むことによりＲＴＣＰ(Real-Time Control Protocol)接続メッセージを生成し、
前記ＲＴＣＰ接続メッセージを前記受信側ＰｏＣクライアントに伝送し、
前記ＲＴＣＰ接続メッセージに対するＲＴＣＰ応答メッセージを受信する制御部を含むことを特徴とする受信側ＰｏＣサーバ。
【請求項２０】
前記サービスセッティングは、前記招待者情報が受信されたか否かを指示する値を含むことを特徴とする請求項１９に記載の受信側ＰｏＣサーバ。
【請求項１】
送信側ＰｏＣ(Push-to-Talk(PTT)-over-Cellular)クライアント、送信側ＰｏＣサーバ、受信側ＰｏＣクライアント、及び受信側ＰｏＣサーバを含むＰｏＣシステムにおいて、前記受信側ＰｏＣクライアントが前記送信側ＰｏＣクライアントによって要求されたグループセッションを開設する方法であって、
前記グループセッションに招待された少なくとも一つのユーザーリストを含む招待者情報を受信するためのサービスセッティングの登録を前記受信側ＰｏＣサーバに要求するステップと、
前記受信側ＰｏＣサーバから、前記サービスセッティングを考慮して生成されたＲＴＣＰ(Real-Time Control Protocol)接続メッセージを受信するステップと、
前記ＲＴＣＰ接続メッセージで前記招待者情報を確認し、前記招待者情報をユーザーに提供するステップと、
前記ユーザーから前記グループセッションの開設が許可されるか否かの入力を受信するステップと、
前記グループセッションの開設が許可されたか否かの入力を含むＲＴＣＰ応答を生成し、前記受信側ＰｏＣサーバに前記ＲＴＣＰ応答を伝送するステップと、
を具備することを特徴とする方法。
【請求項２】
前記ＲＴＣＰ接続メッセージは、前記招待者情報を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記ＲＴＣＰ接続メッセージは、前記受信側ＰｏＣクライアントの応答モード設定に関係なく強制的に手動応答を指示する自動応答無視(ＡＡＯ)要求パラメータをさらに含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記サービスセッティングは、前記招待者情報が受信されたか否かを指示する値を含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記ＲＴＣＰ応答メッセージは、前記グループセッション開設の許可を指示する情報を含み、
前記送信側ＰｏＣクライアントからメディアストリームを受信して前記ユーザーに提供するステップをさらに具備することを特徴とする請求項１に記載の方法。
【請求項６】
前記ＲＴＣＰ応答メッセージは、前記グループセッション開設の拒絶を指示する情報を含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記ＲＴＣＰ応答メッセージは、ユーザーによって前記グループセッション開設の拒絶を指示する理由コードをさらに含むことを特徴とする請求項６に記載の方法。
【請求項８】
送信側ＰｏＣ(Push-to-Talk(PTT)-over-Cellular)クライアント、送信側ＰｏＣサーバ、受信側ＰｏＣクライアント、及び受信側ＰｏＣサーバを含むＰｏＣシステムにおいて、前記受信側ＰｏＣクライアントが前記送信側ＰｏＣクライアントによって要求されたグループセッションを開設する方法であって、
招待者情報を含むインバイトメッセージを受信するステップと、
予め登録された前記受信側ＰｏＣクライアントのサービスセッティングを確認するステップと、
前記確認したサービスセッティングによって前記招待者情報を選択的に含むことによりＲＴＣＰ(Real-Time Control Protocol)接続メッセージを生成するステップと、
前記ＲＴＣＰ接続メッセージを前記受信側ＰｏＣクライアントに伝送するステップと、
前記ＲＴＣＰ接続メッセージに対するＲＴＣＰ応答メッセージを受信するステップと、
を具備することを特徴とする方法。
【請求項９】
前記サービスセッティングは、前記招待者情報が受信されたか否かを指示する値を含むことを特徴とする請求項８に記載の方法。
【請求項１０】
前記招待者情報は、前記グループセッションに招待された少なくとも一つのユーザーリストを含むことを特徴とする請求項８に記載の方法。
【請求項１１】
前記ＲＴＣＰ接続メッセージは、前記受信側ＰｏＣクライアントの応答モード設定に関係なく強制的に手動応答を指示する自動応答無視(ＡＡＯ)要求パラメータをさらに含むことを特徴とする請求項８に記載の方法。
【請求項１２】
前記ＲＴＣＰ応答メッセージが前記グループセッション開設の許可を指示する情報を含む場合に、
前記送信側ＰｏＣクライアントとのセッションを開設するステップと、
前記開設されたセッションで、前記送信側ＰｏＣクライアントからメディアストリームを受信して前記受信側ＰｏＣクライアントに伝送するステップと、
をさらに具備することを特徴とする請求項８に記載の方法。
【請求項１３】
前記ＲＴＣＰ応答メッセージが前記グループセッション開設の拒絶を指示する情報を含む場合に、
前記送信側ＰｏＣクライアントとのセッションを解除するステップをさらに具備することを特徴とする請求項８に記載の方法。
【請求項１４】
前記受信側ＰｏＣクライアントとの応答モードを確認するステップと、
前記応答モードが自動応答モードに設定される場合に、前記インバイトメッセージに対する応答メッセージを伝送するステップと、
をさらに具備することを特徴とする請求項８に記載の方法。
【請求項１５】
前記ＲＴＣＰ応答メッセージは、ユーザーによって前記グループセッション開設の拒絶を指示する理由コードをさらに含むことを特徴とする請求項１３に記載の方法。
【請求項１６】
送信側ＰｏＣ(Push-to-Talk(PTT)-over-Cellular)サーバに接続され、送信側ネットワークによって要求されるグループセッションの開設を制御する受信側ＰｏＣクライアントであって、
前記グループセッションに招待されたユーザーリストを含む招待者情報を受信するためのサービスセッティングの登録を前記受信側ＰｏＣサーバに要求し、
前記受信側ＰｏＣサーバから、前記サービスセッティングを考慮して生成されたＲＴＣＰ(Real-Time Control Protocol)接続メッセージを受信し、
前記ＲＴＣＰ接続メッセージで前記招待者情報を確認し、前記招待者情報をユーザーに提供し、
前記ユーザーから前記グループセッションの開設が許可されるか否かの入力を受信し、前記グループセッションの開設が許可されたか否かの入力を含むＲＴＣＰ応答を生成し、
前記受信側ＰｏＣサーバに前記ＲＴＣＰ応答を伝送する制御部を含むことを特徴とする受信側ＰｏＣクライアント。
【請求項１７】
前記サービスセッティングは、前記招待者情報が受信されたか否かを指示する値を含むことを特徴とする請求項１６に記載の受信側ＰｏＣクライアント。
【請求項１８】
前記制御部は、
前記グループセッション開設の許可を指示する入力を受信する場合に、前記グループセッション開設の許可を指示する情報を前記ＲＴＣＰ応答メッセージに含め、前記送信側ネットワークから受信されるメディアストリームを提供し、
前記グループセッション開設の拒絶を指示する入力を受信する場合には、前記グループセッション開設の拒絶を指示する情報を前記ＲＴＣＰ応答メッセージに含めることを特徴とする請求項１９に記載の受信側ＰｏＣクライアント。
【請求項１９】
送信側ネットワークから要求される受信側ＰｏＣ(Push-to-Talk(PTT)-over-Cellular)クライアントとのグループセッションを開設する受信側ＰｏＣサーバであって、
招待者情報を含むインバイトメッセージを受信し、
予め登録された前記受信側ＰｏＣクライアントのサービスセッティングを確認し、
前記確認したサービスセッティングによって前記招待者情報を選択的に含むことによりＲＴＣＰ(Real-Time Control Protocol)接続メッセージを生成し、
前記ＲＴＣＰ接続メッセージを前記受信側ＰｏＣクライアントに伝送し、
前記ＲＴＣＰ接続メッセージに対するＲＴＣＰ応答メッセージを受信する制御部を含むことを特徴とする受信側ＰｏＣサーバ。
【請求項２０】
前記サービスセッティングは、前記招待者情報が受信されたか否かを指示する値を含むことを特徴とする請求項１９に記載の受信側ＰｏＣサーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１１−２０５６６０（Ｐ２０１１−２０５６６０Ａ）
【公開日】平成２３年１０月１３日（２０１１．１０．１３）
【国際特許分類】
【出願番号】特願２０１１−１０４２２９（Ｐ２０１１−１０４２２９）
【出願日】平成２３年５月９日（２０１１．５．９）
【分割の表示】特願２００９−５１４２１０（Ｐ２００９−５１４２１０）の分割
【原出願日】平成１９年６月８日（２００７．６．８）
【出願人】（５０３４４７０３６）サムスン エレクトロニクス カンパニー リミテッド (2,221)
【Ｆターム（参考）】
【公開日】平成２３年１０月１３日（２０１１．１０．１３）
【国際特許分類】
【出願日】平成２３年５月９日（２０１１．５．９）
【分割の表示】特願２００９−５１４２１０（Ｐ２００９−５１４２１０）の分割
【原出願日】平成１９年６月８日（２００７．６．８）
【出願人】（５０３４４７０３６）サムスン エレクトロニクス カンパニー リミテッド (2,221)
【Ｆターム（参考）】
[ Back to top ]