マルチメディア通話サービスを遂行するためのマルチメディアセッション開設及び管理のためのサーバ
【課題】本発明の目的は、多様な種類のメディアタイプを支援するＰｏＣクライアント間のＰｏＣセッションの開設及び管理システムとその方法及び端末装置を提供することにある。
【解決手段】ＯＭＡ(Open Mobile Alliance)ＰｏＣマルチメディア通話サービスを遂行するＰｏＣクライアントが、複数のメディアタイプを支援し、ＰｏＣクライアントによって支援されるメディアタイプが共通でない場合に、ＰｏＣセッションは、セッションの開設後に最初の応答メッセージで伝送されるように設定されたメディアタイプのみを支援するように開設されることができる。また、新たに支援されるメディアタイプが提供され、あるいは既存のメディアタイプの受信が変動された場合に、セッションをアップデートによって効率的に管理する方法が提案される。
【解決手段】ＯＭＡ(Open Mobile Alliance)ＰｏＣマルチメディア通話サービスを遂行するＰｏＣクライアントが、複数のメディアタイプを支援し、ＰｏＣクライアントによって支援されるメディアタイプが共通でない場合に、ＰｏＣセッションは、セッションの開設後に最初の応答メッセージで伝送されるように設定されたメディアタイプのみを支援するように開設されることができる。また、新たに支援されるメディアタイプが提供され、あるいは既存のメディアタイプの受信が変動された場合に、セッションをアップデートによって効率的に管理する方法が提案される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディア通話サービスを遂行するためのマルチメディアＰｏＣ(Pushto talk over Cellular)セッション開設及び管理システムとその方法及びユーザー端末(User Equipment：ＵＥ)に関するもので、特に、ＰｏＣクライアントによって支援される多様なメディアタイプがＰｏＣセッション開設に共通でない場合、あるいは最初の応答メッセージに含まれた伝送可能なメディアタイプが送信側によって提供されるメディアタイプと異なる場合、このＰｏＣセッションで少なくとも一つの受信可能なＰｏＣクライアントによって支援されたメディアタイプのみを支援するＰｏＣセッション開設のためのシステムとその方法及びユーザー端末に関する。
【背景技術】
【０００２】
移動通信の重要な発展と通信ネットワークの拡大は、携帯電話を用いる多様な追加サービスとアプリケーションを提供する。同時に、位置サービス、マルチメディアサービス、及びＰＴＴ(Push-To-Talk)サービスのような多様な追加サービスに対する携帯電話ユーザーの要求も増加している。これら追加サービスの中で、ＰＴＴサービスは、従来の無線又はＴＲＳ(Trunked Radio System)によって提供されるグループ通話及び音声通話だけでなく、インスタントメッセンジャー機能及び状態表示機能のような多様な付加機能を支援する。
【０００３】
現在、移動通信ネットワークでＰＴＴ機能を使用するＰｏＣ(PTT-over-Cellular)サービスの標準化が、活発に論議されている。既存の移動通信サービスと区別されるＰｏＣサービスのユニークな特徴の一つは、ユーザーが複数のＰｏＣセッションに参加し、通話サービスを利用するためにこのＰｏＣセッションの間を移動することができるということである。ユーザーが通話サービスを使用するために複数のＰｏＣセッションの間を移動できる要求事項は、多重セッション機能に対する要求事項は移動通信サービスを規定する団体であるＯＭＡ(Open Mobile Alliance）に明示されている。
【０００４】
一方、ＰｏＣ Ｖ２.０システムは、ＰｏＣマルチメディア通話サービスを支援する。このＰｏＣマルチメディア通話サービスを支援するために、ＰｏＣ Ｖ２.０システムは、音声だけでなく、ビデオ、イメージ、及びテキストを新たなマルチメディアタイプとして定義する。
【０００５】
現在のＰｏＣシステムは、ユーザー端末(User Equipment：ＵＥ)の性能向上のため、ビデオ及び/又はイメージのような多重ストリームをディスプレイできる。上記したように、ＰｏＣ Ｖ２.０システムが従来のＰｏＣ Ｖ１.０のセッション開始方法及びシステムを使用すると、ＰｏＣ Ｖ２.０システムによって支援される多様なマルチメディアサービスは制限され、セッション開始時間が長くかかるという問題点があった。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】国際公開第２００６／００６８９７号
【特許文献２】特表２００６−５１３６１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
したがって、本発明は上記従来の問題点に鑑みてなされたものであって、その一態様による目的は、ＰｏＣマルチメディア通話サービスを遂行するＰｏＣクライアントが、複数のメディアタイプを支援し、ＰｏＣクライアントによって支援されるメディアタイプが共通でない場合、あるいは最初の応答メッセージに含まれた伝送可能メディアタイプが送信側によって提供されたメディアタイプと異なる場合に、該当ＰｏＣセッションで少なくとも一つの受信ＰｏＣクライアントによって支援されるメディアタイプのみを支援するＰｏＣセッションを開設するためのシステムとその方法及び端末装置(ＵＥ)を提供することにある。
【０００８】
本発明の他の態様による目的は、新たなメディアタイプが新たな参加者によって支援される場合、または既存のメディアタイプの受信者が変更される場合に、変更される情報を自動にアップデートしてセッションを管理するシステムとその方法及びＵＥを提供することにある。
【０００９】
また、本発明の他の態様による目的は、セッション開始クライアントから受信されるセッション参加要求(ＩＮＶＩＴＥ)メッセージに含まれたメディアタイプの属性(attribute）を格納し、最初の応答に対応してセッションが開設された後に、ＩＮＶＩＴＥメッセージで提供されるメディアタイプ及びメディア属性を支援する新たな参加者が該当セッションに参加する場合に、格納されたメディア属性をアップデートされるセッションで提供するようにセッションをアップデートするためのシステムとその方法及びＵＥを提供することにある。
【課題を解決するための手段】
【００１０】
上記のような目的を達成するために、本発明の一態様によれば、マルチメディア通話サービスを遂行するためのマルチメディアセッション開設及び管理のためのサーバであって、セッション開始要求クライアント及び少なくとも一つのセッション参加クライアントとのパケットデータ送受信を遂行するデータ送受信部と、セッション参加要求メッセージに含まれたメディア属性情報と少なくとも一つのメディアタイプを格納するメモリと、前記セッション参加要求メッセージの受信、メディア属性情報と少なくとも一つのメディアタイプの格納、セッション参加クライアントにより支援される少なくとも一つのメディアタイプを含む最初応答メッセージの受信、及び前記最初応答メッセージに含まれた少なくとも一つのメディアタイプとメモリに格納された前記少なくとも一つのメディアタイプとを比較して、前記メディアタイプを支援するマルチメディア通信セッションを開設するセッション開設要求クライアントに応答メッセージの伝送を制御するセッション処理部と、含むことを特徴とする。また、本発明の一態様によれば、マルチメディア通話サービスを遂行するためのマルチメディアＰｏＣセッション開設及び管理のためのＰｏＣシステムであって、メディアタイプ及びメディア属性情報を含むセッション参加要求(ＩＮＶＩＴＥ)メッセージをＰｏＣサーバに伝送するセッション開始要求ＰｏＣクライアントと、ＩＮＶＩＴＥメッセージに含まれたメディアタイプ及びメディア属性情報を格納し、最初の応答メッセージが受信されると、最初の応答メッセージでメディア伝送のために設定するメディアタイプのみを支援するＰｏＣセッションを開設するために、最初の応答メッセージに含まれたメディアタイプが伝送可能な状態であることを示す応答メッセージをセッション開始要求ＰｏＣクライアントに伝送するＰｏＣサーバとを含むことを特徴とする。
【００１１】
本発明の他の態様によれば、セッション開始要求ＰｏＣクライアント、少なくとも一つのセッション参加ＰｏＣクライアント、及びマルチメディアＰｏＣセッションを開設及び管理するためのＰｏＣサーバを含むＰｏＣシステムにおいて、マルチメディア通話サービスを遂行するためのマルチメディアＰｏＣセッションを開設及び管理するための方法であって、セッション開始要求ＰｏＣクライアントがメディアタイプ及びメディア属性情報を含むＩＮＶＩＴＥメッセージをＰｏＣサーバに伝送する第１のプロセスと、ＰｏＣサーバがＩＮＶＩＴＥメッセージに含まれたメディアタイプ及びメディア属性を格納する第２のプロセスと、最初の応答メッセージが受信されると、ＰｏＣサーバは、最初の応答メッセージに含まれたメディアタイプが伝送可能な状態であることを示す応答メッセージをセッション開始要求ＰｏＣクライアントに伝送してＰｏＣセッションを開設する第３のプロセスとを有することを特徴とする。
【００１２】
また、本発明の他の態様によれば、ＰｏＣシステムにおけるマルチメディア通話サービスを遂行するためのマルチメディアＰｏＣセッションの開設及び管理のための端末装置であって、ＰｏＣサーバとのパケットデータの送受信を遂行するデータ伝送部と、セッション開設のために要求されるメディアタイプ及びメディア属性情報を含むＩＮＶＩＴＥメッセージを伝送し、現在セッションで支援される特定のメディアタイプ情報を含むｒｅ-ＩＮＶＩＴＥメッセージが受信された場合に、ｒｅ-ＩＮＶＩＴＥメッセージに対する応答メッセージを伝送するためにデータ伝送部を制御する制御部とを含むことを特徴とする。
【００１３】
好ましく、ＰｏＣシステムは、ＩＮＶＩＴＥメッセージを送信するセッション開始要求ＰｏＣクライアントと、上記ＰｏＣクライアントからＩＮＶＩＴＥメッセージを受信し、ＩＮＶＩＴＥメッセージに対する応答メッセージをセッション開始要求ＰｏＣクライアントに伝送するＰｏＣサーバと、メディアタイプ情報を含む応答メッセージを格納するセッションメディアタイプ及び属性臨時格納部とを含む。
【００１４】
好ましく、メディアタイプ情報は、ＳＩＰ(Session Initiation Protocol)ＩＮＶＩＴＥメッセージとＳＩＰ２００‘ＯＫ’メッセージのボディー部分或いはＲＴＣＰ(Real-ime Transport Control Protocol)メッセージフォーマットにメディアタイプ情報のための新たなカラム(column)を追加する形態で通知できる。
【００１５】
本発明は、ＯＭＡ ＰｏＣマルチメディア通話サービスを遂行するＰｏＣクライアントが、ＰｏＣセッションの開設時にＰｏＣクライアントによって支援される多様なメディアタイプが相互に共通でない場合、或いは最初の応答メッセージに含まれた伝送可能メディアタイプが送信側で提供されたメディアタイプと異なる場合に、該当ＰｏＣセッションで少なくとも一つの受信ＰｏＣクライアントによって支援される(すなわち、該当メディアタイプを送受信できるＰｏＣクライアントが２個以上である)メディアタイプのみを支援するＰｏＣセッションを開設し、以後該当セッションで任意の参加者がセッションを終了し、あるいは新たな参加者がセッションに参加する場合に、セッションアップデートを通じて少なくとも一つの受信ＰｏＣクライアントによって支援されるメディアタイプだけを追加または除去するためのＰｏＣシステムにおけるセッション管理システムとその方法及び端末装置を提案する。
【発明の効果】
【００１６】
本発明は、マルチメディア通話サービスを遂行するＰｏＣクライアントが複数のメディアタイプを支援し、ＰｏＣクライアントによって支援されるメディアタイプが共通でない場合に、ＰｏＣセッションで少なくとも一つのターゲットＰｏＣクライアントによって支援されるメディアタイプのみを支援するＰｏＣセッションが開設されることができる。
【００１７】
また、本発明は、新たなメディアタイプが新たな参加ＰｏＣクライアントによって提供され、既存のセッションで支援されるメディアタイプの受信者が変更されると、変更をアップデートしてセッションを管理する方法を提供することによって、セッションが、新たなメディアタイプの追加又は既存のメディアタイプの除去に対応して活発に管理されることができる。
【００１８】
さらに、本発明は、メディアタイプ情報がアップデートされる必要がある場合に、追加手順なしに該当セッションにアップデート内容を反映するために、最初のＰｏＣセッション開始によって提供されたメディアタイプ及びメディア属性情報を格納し、それによって無線伝送の効率性を向上させ、ＰｏＣサービスのユーザー経験を向上させる効果がある。
【図面の簡単な説明】
【００１９】
【図１】一般のＰｏＣシステムを示す回路図である。
【図２】一般のＰｏＣサーバを示すブロック構成図である。
【図３】ＰｏＣサーバのＣＦ(Controlling PoC Function)及びＰＦ(Participating PoC Function)を示すブロック構成図である。
【図４】本発明の一実施形態により、相互に接続されたＰｏＣクライアントを含むＰｏＣ端末とＰｏＣサーバとを示すブロック構成図である。
【図５】本発明の一実施形態により、コンファレンス(conference)ＰｏＣサーバが多様なメディアタイプを要求するセッション参加要求(ＩＮＶＩＴＥ)メッセージを受信する場合に、マルチメディアＰｏＣセッションを開設するプロセスを示すフローチャートである。
【図６】本発明の一実施形態により、多様なメディアタイプを支援するＰｏＣクライアント間の効率的なセッションの開始及び管理のためのＰｏＣクライアントとＰｏＣサーバとの間の信号フローを示す図である。
【図７Ａ】本発明の一実施形態により、ＰｏＣセッションが開設された場合に、ＩＮＶＩＴＥメッセージに含まれたＳＤＰ(Session Description Protocol)オファー(offer)及びＵＰＤＡＴＥ又はｒｅ-ＩＮＶＩＴＥメッセージに含まれたＳＤＰオファーを示す図である。
【図７Ｂ】本発明の一実施形態により、ＰｏＣセッションが開設された場合に、ＩＮＶＩＴＥメッセージに含まれたＳＤＰ(Session Description Protocol)オファー(offer)及びＵＰＤＡＴＥ又はｒｅ-ＩＮＶＩＴＥメッセージに含まれたＳＤＰオファーを示す図である。
【図７Ｃ】本発明の一実施形態により、ＰｏＣセッションが開設された場合に、ＩＮＶＩＴＥメッセージに含まれたＳＤＰ(Session Description Protocol)オファー(offer)及びＵＰＤＡＴＥ又はｒｅ-ＩＮＶＩＴＥメッセージに含まれたＳＤＰオファーを示す図である。
【図８Ａ】本発明の一実施形態により、ＰｏＣセッションが開設された場合に、ＩＮＶＩＴＥメッセージに含まれたＳＤＰオファー及びＵＰＤＡＴＥ又はｒｅ-ＩＮＶＩＴＥメッセージに含まれたＳＤＰオファーを示す図である。
【図８Ｂ】本発明の一実施形態により、ＰｏＣセッションが開設された場合に、ＩＮＶＩＴＥメッセージに含まれたＳＤＰオファー及びＵＰＤＡＴＥ又はｒｅ-ＩＮＶＩＴＥメッセージに含まれたＳＤＰオファーを示す図である。
【図８Ｃ】本発明の一実施形態により、ＰｏＣセッションが開設された場合に、ＩＮＶＩＴＥメッセージに含まれたＳＤＰオファー及びＵＰＤＡＴＥ又はｒｅ-ＩＮＶＩＴＥメッセージに含まれたＳＤＰオファーを示す図である。
【発明を実施するための形態】
【００２０】
以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。
下記に、ＰＴＴシステム、特にセルラー移動通信ネットワークを使用するＰＴＴサービ
スを提供するＰｏＣシステムに本発明を適用する場合について説明する。
【００２１】
一般に、ＰｏＣシステムは、グループＰｏＣ通話のセッション参加情報を伝送するためにＳＩＰ(Session Initiation Protocol)及びＳＩＰ拡張プロトコルを使用し、グループ情報を獲得するためにＸＣＡＰ(XML Configuration Access Protocol)を使用する。後術する本発明の機能は、上記したプロトコルを用いて実現でき、本発明の基本構成はＰｏＣ Ｒｅｌ.１システムに基づいてなされる。
【００２２】
まず、本発明が適用される一般のＰｏＣシステムの構成について説明する。
図１は、通常のＰｏＣシステム及び関連ネットワーク構造を示す概念図である。
図１を参照すると、通常のＰｏＣシステムはＰｏＣ端末１００、ＸＤＭＳ(XML Document Management Server)１３０，１４０、及びＰｏＣサーバ１５０を含むことができる。ＰｏＣシステムは、アグリゲーションプロキシサーバ１６０をさらに含む。これら構成要素は、アクセスネットワーク１１０、ＳＩＰ/ＩＰ(Internet Protocol)コアネットワーク１２０、及び遠隔ＰｏＣネットワーク１７０を通じて接続される。
【００２３】
次に、上記の構成要素について説明する。
ＰｏＣ端末１００は、ＰｏＣクライアント１０２及びＸＤＭＣ(XML(eXtensible Markup Language) Document Management Client)１０４を含む。
【００２４】
ＰｏＣクライアント１０２は、ＰｏＣ端末１００に内蔵されるサービス要求者であって、ＰｏＣサービス加入者にＰｏＣサービスを提供するためのネットワークアクセスを遂行するためにＰｏＣ端末１００に備えられる。ＰｏＣサービス加入者は、ＰｏＣクライアントが内蔵されたＰｏＣ端末を通じてＰｏＣサービスを受信できる。以下、用語“ＰｏＣクライアント”は、ＰｏＣクライアントが内蔵されたＰｏＣ ＵＥ及びＰｏＣサービス加入者として使用される。また、特に明記されない限り、 ＰｏＣクライアントの参照符号は省略する。
【００２５】
ＰｏＣクライアントは、主にＰｏＣサービス加入者、すなわちＰｏＣユーザーの側面でＰｏＣセッションを開設し、既存のＰｏＣセッションに参加し、あるいは開設されているセッションを終了する役割を果たす。また、ＰｏＣクライアントは、トークバーストを生成及び伝送する機能、緊急個人警報(Instant Personal alert)を支援する機能、及びＰｏＣサービスにアクセスする場合に要求される認証機能を遂行する。ＰｏＣクライアントは、アクセスネットワーク１１０を通じて、ＳＩＰ/ＩＰマルチメディア支援コアネットワークであるＳＩＰ/ＩＰコアネットワーク１２０に接続されることができる。
【００２６】
ＳＩＰ/ＩＰコアネットワーク１２０は、ＰｏＣサービスを支援するために、ＰｏＣサーバ１５０、ＸＤＭＳ１３０，１４０に接続される。このとき、ＰｏＣサーバ１５０は、ＰｏＣセッションを維持及び管理する制御ＰｏＣ機能(Controlling PoC Function)を遂行し、あるいは一対一のＰｏＣ通話または一対多のＰｏＣ通話のために開設されたＰｏＣセッションに参加するための参加ＰｏＣ機能(Participating PoC Function)を遂行できる。
【００２７】
一方、ＰｏＣサービスは、コンファレンス通話のように、グループセッションを開設するサービスを含むことができる。このサービスのために、ＯＭＡ(Open Mobile Alliance)標準は、グループリストサービスのためのＸＤＭＣ１０４及びＸＤＭＳ１３０，１４０を定義する。図１は、ＰｏＣサービスのために使用されるＰｏＣ ＸＤＭＳ１４０と、他のサービスイネーブラ(enabler)のために共通に使用される共有ＸＤＭＳ１３０とを示す。グループ及びグループメンバーに関する情報は、ＰｏＣクライアントを通じてＸＤＭＳ１３０，１４０に入力されることができる。ＰｏＣクライアントは、ＸＤＭＳ１３０，１４０から伝送された個人又はグループリストを用いて呼出できるＰｏＣクライアントに関する情報を獲得できる。ＸＤＭＳ１３０，１４０におけるグループ及びグループメンバーの生成、変更、及び管理は、ＰｏＣサービス提供者が信頼できるインターネット又はイントラネットのような通信ネットワークを通じてなされることができる。グループリストを生成、変更、及び除去するＸＭＬ文書管理のプロトコルの詳細な説明は省略する。
【００２８】
グループサービスに対するグループリスト関連要求がＸＤＭＣ１０４から受信された場合に、アグリゲーションプロキシサーバ１６０は、適切な規則に従ってＸＤＭＳ１３０，１４０にグループリスト関連要求をルーティングする。
【００２９】
次に、図２を参照してＰｏＣサーバ１５０について説明する。
図２は、一般のＰｏＣサーバを示すブロック構成図である。
ＰｏＣサーバは、ＰｏＣセッションを全体的に保持及び管理する制御ＰｏＣ機能(Controlling PoC Function：以下、“ＣＦ”と称する）部とセッションを管理するための参加ＰｏＣ機能(Participating PoC Function：以下、“ＰＦ”と称する)部に分類されることができる。ＰｏＣサーバの機能別特性は、下記の＜表１＞及び＜表２＞を参照して説明する。
【００３０】
【表１】
【００３１】
＜表１＞に示すように、ＣＦは、ＰｏＣサーバの機能中にＰｏＣセッションを全体的に管理する役割をする。ＰｏＣサーバは、ＰｏＣクライアントからの発言権(floor)に対する要求を受信し、クライアントに権限を与える順序を配列し、その順にＰｏＣクライアントに発言権を与える。また、ＰｏＣサーバは、グループＰｏＣ呼び出しに参加するすべてのＰｏＣクライアントに特定のＰｏＣクライアントからのトークバーストを分配し、グループＰｏＣ呼び出しに参加したＰｏＣクライアントの情報を提供する。
【００３２】
下記の＜表２＞に示すように、ＰＦは、ＣＦと各ＰｏＣクライアントとの間でＰｏＣセッションを管理する。特に、ＰＦは、ＰｏＣクライアントが発言権を要求した場合、又はＣＦがＰｏＣクライアントに発言権を付与する場合に、ＰｏＣクライアントとＣＦとの間で発言権を中継する役割をする。また、ＰＦは、ＣＦとＰｏＣクライアントとの間でメディアを中継し、相互に異なるコーデック間のトランスコーディングし、２個の同時ＰｏＣセッションで同時に発言している場合には、一つのユーザーによって選択された２個のＰｏＣセッションのうちの一つをフィルタリングするためのフィルタリング機能を提供する。
【００３３】
【表２】
【００３４】
図３は、ＰｏＣサーバのＣＦとＰＦを図式的に説明するためのブロック構成図である。
図３を参照すると、各ＰｏＣクライアント１０２Ａ〜１０２Ｄは、ＰＦ３１０-Ａ〜３１０-Ｄを通じてＣＦ３００にアクセスしてＰｏＣセッションを設定する。ここで、発言権がＣＦ３００から話者(talker)として資格を有するＰｏＣクライアントに与えられた場合に、資格のあるＰｏＣクライアントに基づいたメディアは、各ＰｏＣクライアントに伝送される。このとき、話者として資格が与えられたＰｏＣクライアントは、グループセッションに参加しているＰｏＣクライアントに関する情報を確認した後のみ、発言することができる。
【００３５】
ＰｏＣシステムにおいて、通話接続のための呼処理技術は、送信側と受信側の要求及び状態により多様な手順を可能にする。このような送信側と受信側の設定によってＯＭＡによって要求されるＰｏＣシステムの特徴は、次のようである。
【００３６】
第一に、受信側は、ＰｏＣクライアントの要求によって自分の応答モードを設定でき、この応答モードは、自動応答モードと手動応答モードに分類される。自動応答モードで、該当情報が受信側によって指定されたＰｏＣクライアントリストに含まれると、該当ネットワークは、受信側の受動応答の代わりに送信側の即時応答を送信する。このネットワークは、ＰｏＣ端末が応答モード設定要求によって応答モード及び自動応答ユーザーリストを格納するため、ＰｏＣ端末の動作の代わりに自動応答を送信する。手動応答モードは、送信側が自動応答ユーザーリストに含まれていない場合、又は送信側が自動応答ユーザーリストに含まれているか否か不明な場合、あるいは受信側がすべてのユーザーに対して手動応答を設定した場合に該当する。ＰｏＣ通話要求は、受信ネットワークを介してＰｏＣ端末に伝送され、ＰｏＣクライアントの許可によって通話が連結される。
【００３７】
第２に、ＰｏＣシステムは、ＰｏＣクライアントがユーザーのホームネットワークに属するＰｏＣサーバとの接続が設定されたか否かに従ってｏｎ-ｄｅｍａｎｄセッションモード又は事前開設(pre-established)セッションモードにあり得る。事前開設セッションモードは、ＰｏＣクライアントが、自分の要求によってそのホームネットワークに属するＰｏＣサーバとの間で予めセッションを設定することを示す。事前開設セッションモードは、ＰｏＣクライアントが、メディアパラメータをＰｏＣサーバと予め交渉して今後使用されるＰｏＣサーバとメディアパラメータの再交渉なしに、迅速にセッションを開設するために必要である。
【００３８】
事前開設セッションは、ＳＩＰ ＩＮＶＩＴＥ方法を用いて、メインテキスト部、すなわちＳＤＰ ＭＩＭＥ(Session Description Protocol Multipurpose Internet Mail Extensions)に支援されるメディアパラメータを提供し、ＰｏＣサーバによって提供されるメディアパラメータを提供し、ＳＩＰサーバによって提供されるメディアパラメータに応答するＰｏＣクライアントによって予め設定される。このとき、ＰｏＣサーバから受信された応答メッセージに新たに設定されるコンファレンスＵＲＩ(conference Uniform Resource Identifier)を含む事前開設セッションの識別情報は、ＰｏＣクライアントに回答する。
【００３９】
事前開設セッションが使用される場合に、インターネットプロトコル(ＩＰ)アドレス、ポート番号、使用されるコーデック、及びトークバースト制御プロトコルは、事前交渉が可能である。ｏｎ-ｄｅｍａｎｄセッションモードは、ＰｏＣクライアントがセッションを予め開設しない状態を示し、他のＰｏＣクライアントがセッションを予め設定しない状態を示し、そして他のＰｏＣクライアントからＩＮＶＩＴＥメッセージを受信した後に、ＰｏＣクライアントがＰｏＣ呼接続手順を遂行することを示す。
【００４０】
ＰｏＣシステムで通話要求に応じて、応答モードの設定は、ネットワークの要素であるＰｏＣサーバとユーザー側の端末であるＰｏＣクライアントにすべて格納されることができる。
【００４１】
応答モードがＰｏＣクライアントを管理するホームネットワークに設定される場合に、応答モードは、ＰｏＣクライアントが属しているホームネットワーク内のＰＦとして作用するＰｏＣサーバに設定される。
【００４２】
このとき、ＰｏＣ通話が他のＰｏＣサーバから要求されると、ＰＦは、遅延なしにセッション進行メッセージを通話要求ネットワークに自動に応答する。したがって、自動応答モードが設定された場合には、セッションセットアップメッセージがＰｏＣクライアントに伝送される場合に比べて、通話要求手順が簡素化され、これによって初期発言権付与時間が短縮される。
【００４３】
しかしながら、ホームネットワークで自動応答モードが設定される場合に、ユーザーが所望する応答と異なる結果が状況に従って発生する可能性があるため、応答モードは、ＰｏＣクライアントに設定されることができる。このとき、ＰｏＣクライアントの応答モードがホームネットワークに設定された応答モードより高い優先度を有する。これは、ＰｏＣクライアントがその応答モードを変更してＰｏＣサーバに応答モード更新を要求する場合に、ネットワークでの信号遅延又は誤りによってリアルタイムで応答モードが反映されない場合に発生するプライバシー(privacy)問題を解決する。
【００４４】
要約すれば、ＰｏＣサービスは、ユーザーの応答モードをＰｏＣサーバ又はＰｏＣクライアントによって設定できるが、応答モードがユーザーの所望を最近に反映したＰｏＣクライアントによって決定され、このような決定に基づいてメディアストリーム(ユーザーの音声又は映像)が伝送される。
【００４５】
以下、上述した特徴を有するＰｏＣシステムでのＰｏＣマルチメディアセッションの開設手順について説明する。
送信側ＰｏＣクライアントは、ＳＩＰを用いて、マルチメディアセッション参加要求メッセージ(マルチメディアは、メディアタイプの選択によって多様なフォーマットのオーディオ、ビデオ、及びテキストを含むことができる)を送信して呼処理を要求する。このような呼処理要求に応答して、ターゲットＰｏＣクライアントは、該当ＰｏＣサーバでの応答モードの設定と既存セッションが存在するか否かによって多様に応答する。ＰｏＣ通話のための呼処理手順については、送信側ネットワーク及びターゲットネットワークの手順を例示して説明する。
【００４６】
送信側ＰｏＣクライアントは、ターゲットＰｏＣクライアントのＳＩＰアドレス情報を含むＳＩＰセッション参加要求(ＩＮＶＩＴＥ)メッセージを該当ＳＩＰ/ＩＰコアネットワークに伝送する。このＳＩＰ ＩＮＶＩＴＥメッセージは、送信側ＰｏＣクライアントのＰｏＣアドレス情報、要求されるメディアパラメータ、ＰｏＣサービスを知らせる特性値情報などのような要素をさらに含むことができる。要求されるセッションがマルチメディアに該当すると、“要求されるメディアパラメータ”は、オーディオとビデオのエンコーディング方法、ビットレート、ペイロードタイプのような多様な特性値を含むことができる。
【００４７】
ＳＩＰ ＩＮＶＩＴＥメッセージは、ＤＨＣＰ(Dynamic Host Configuration Protocol)サーバ又はＤＮＳ(Domain Name Server)での経路クエリー(query)を用いてＩＭＳネットワーク内の該当ＩＭＳ(IP Multimedia Subsystem)サーバ、すなわちＰ-ＣＳＰＦ(Primary Constrained Shortest Path First)及びＳ-ＣＳＰＦ(Secondary CSPF)を通じて参加ＰｏＣサーバ(ＰＦ)に伝送される。一般の通話が要求されると、ＰｏＣクライアントが接続された参加ＰｏＣサーバは、開設されるセッションのトークバーストを管理する制御ＰｏＣサーバと分離して実現されることができるため、ＰＦに伝送されたＳＩＰ ＩＮＶＩＴＥメッセージは、該当ＳＩＰ/ＩＰコアネットワークを通じて制御ＰｏＣサーバＣＦに伝送される。
【００４８】
ＣＦを含むＰｏＣセッション制御ネットワークは、ターゲットネットワークにＳＩＰ ＩＮＶＩＴＥメッセージを伝送し、このターゲットネットワークから応答メッセージを受信する。ターゲットネットワークから応答されるＳＩＰメッセージは、‘１ｘｘ’で表される臨時応答メッセージ、‘２ｘｘ’で表される成功応答メッセージ、又は‘４ｘｘ’〜‘６ｘｘ’で表される誤り応答メッセージであり得る。自動応答モードで、ＳＩＰ１８３‘ｓｅｓｓｉｏｎ ｐｒｏｇｒｅｓｓ’信号は、応答メッセージとして受信されることができ、この応答メッセージを用いて通話要求者のＩＭＳネットワークでＰｏＣサーバとＰｏＣクライアントとの間の接続が遂行されることができる。ターゲットＰｏＣクライアントの通話許可信号は、ＳＩＰ１８３‘ｓｅｓｓｉｏｎ ｐｒｏｇｒｅｓｓ’信号又はＳＩＰ２００‘ＯＫ’応答として伝送され、ＣＦ及びＰＦを含むＰｏＣサーバを通じて送信側ＰｏＣクライアントに伝送される。２００‘ＯＫ’応答又は１８３‘ｓｅｓｓｉｏｎ ｐｒｏｇｒｅｓｓ’信号がターゲットＰｏＣサーバから受信されると、ＣＦは、ＰｏＣ呼が接続されたと決定し、トークバースト発言権を付与するための‘ｆｌｏｏｒ ｇｒａｎｔｅｄ’信号を送信側ＰｏＣクライアントに伝送する。２００‘ＯＫ’応答又は１８３‘ｓｅｓｓｉｏｎ ｐｒｏｇｒｅｓｓ’信号によってトークバースト発言権の付与は、‘ｃｏｎｆｉｒｍｅｄ’又は‘ｕｎｃｏｎｆｉｒｍｅｄ’によって識別されることができる。‘ｕｎｃｏｎｆｉｒｍｅｄ’応答が受信されると、ＣＦは、バッファリング機能を必要とする。
【００４９】
ＳＩＰ ＩＮＶＩＴＥ要求メッセージに対する応答信号を受信した後に、送信側ＰｏＣクライアントは、トークバーストを伝送し、ＲＴＣＰ(Real-time Transport Control Protocol)を用いて伝送信号(例えば、通話接続音)を伝送するための‘ｆｌｏｏｒ ｇｒａｎｔｅｄ’信号を受信する。‘ｆｌｏｏｒ ｇｒａｎｔｅｄ’信号は、とイークバースト仲裁権を有するＣＦによって与えられ、ＰｏＣクライアントを管理するＰＦを通じてＰｏＣクライアントに伝送される。‘ｆｌｏｏｒ ｇｒａｎｔｅｄ’信号は、ＳＩＰの代わりにベアラの経路を使用するため、‘ｆｌｏｏｒ ｇｒａｎｔｅｄ’信号は、対案として用いるＩＭＳネットワークのようなＳＩＰ/ＩＰコアネットワークを利用せずに伝送されることができる。通話接続音を受信される送信側ＰｏＣクライアントは、メディアストリーム(例えば、音声ストリーム)をＲＴＰ(Real-time Transport Protocol)を用いて伝送する。
【００５０】
以下、当該技術分野で通常の知識を持った者が本発明を容易に実施できるように、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。
本発明は、ＰｏＣマルチメディア環境で最初の応答クライアントによって応答するメディアタイプに限定されるＲＴＰメディアを伝送する送信側ＰｏＣサーバ間のＰｏＣセッションを開設し、上記セッションでセッションアップデートを通じて少なくとも一つのターゲットＰｏＣクライアントによって支援されるメディアタイプのみを追加又は除去するセッション管理システムとその方法及び端末装置に関する。
【００５１】
ＰｏＣセッションの開設のために、ＰｏＣクライアントによって支援される多様なメディアタイプが相互に共通でない場合、あるいは最初の応答メッセージに含まれた伝送可能なメディアタイプが送信側によって提供されるメディアタイプと異なる場合に、ＰｏＣセッションで少なくとも一つの受信可能なＰｏＣクライアントによって支援されるメディアタイプのみを支援するＰｏＣセッションを開設するためのＰｏＣシステムを構成するＰｏＣクライアントとＰｏＣサーバの構成は、図４を参照して説明する。図４は、本発明の実施形態により、相互に接続される、ＰｏＣクライアント１０２を含むＰｏＣ端末１００とＰｏＣサーバ１５０を示すブロック構成図である。
【００５２】
図４を参照すると、ＰｏＣ端末１００は、ユーザーとのインターフェースのための装置であって、各キー入力にその固有のキー入力データを出力するユーザーインターフェース４０４を含む。また、ＰｏＣ端末１００は、ＰｏＣサーバ１５０とのパケットデータ通信を遂行するために、プロトコルスタックで構成されるデータ伝送部４１０を含む。ＰｏＣ端末１００は、データ伝送部４１０によって受信されたメディアデータをディスプレイし、ユーザーインターフェース４０４から出力されるデータをディスプレイするディスプレイ部４００を含む。さらに、ＰｏＣ端末１００は、制御部４０２を含む。制御部４０２は、ＰｏＣクライアント１０２のデータ送受信、ディスプレイ部４００のディスプレイ、チャット(chat)ＰｏＣグループに参加するための招待予約メッセージの生成と伝送、及び応答メッセージの受信を制御する。特に、ＰｏＣクライアント１０２がセッション開設ＰｏＣクライアントである場合に、制御部４０２は、セッション開設のためにユーザーによって要求されるメディアタイプ及びメディア属性情報を含むセッション参加要求(ＩＮＶＩＴＥ)メッセージをＰｏＣサーバ１５０に伝送する。また、現在セッションによって支援される特定のメディアタイプ情報を含むｒｅ-ＩＮＶＩＴＥメッセージがＰｏＣサーバ１５０から受信された場合に、制御部４０２は、このｒｅ-ＩＮＶＩＴＥメッセージに対応してＰｏＣサーバ１５０に応答メッセージを伝送する。一方、ＰｏＣクライアント１０２がセッション参加ＰｏＣクライアントである場合に、制御部４０２は、ＩＮＶＩＴＥメッセージに応答してＰｏＣサーバ１５０に支援可能なメディアタイプ情報を含む応答メッセージを伝送する。
【００５３】
ＰｏＣ端末１００は、ＰｏＣ端末１００の全般的な機能に関連した情報を格納し、ＰｏＣサービスに関連したデータ及び端末を識別するためのユーザーアカウント、及びユーザーによって設定され、あるいはＰｏＣサーバ１５０から提供される情報を格納するメモリ４０５を含む。特に、メモリ４０５は、受信された応答メッセージに含まれた支援可能なメディアタイプに関する情報を格納する。
【００５４】
ＰｏＣサーバ１５０は、プロトコルスタックで構成されるデータ伝送部４２０、多重マルチメディア通話サービス処理部４３０、メモリ４２１、及び参加ＰｏＣ機能コンポーザー(composer)４４０を含む。ＰｏＣサーバ１５０の動作については、下記の図５を参照して詳しく説明する。
【００５５】
図５は、本発明の一実施形態によるＰｏＣクライアントとＣＦとの間で多様なメディアタイプを支援するマルチメディアＰｏＣセッションを開設するためにＣＦを遂行するＰｏＣサーバにマルチメディアＰｏＣセッションを開設するプロセスを示すフローチャートである。
【００５６】
図５を参照すると、ステップ５００で、ＣＦがＩＮＶＩＴＥメッセージを受信すると、ＣＦは、ステップ５０２で、ＩＮＶＩＴＥメッセージに含まれたメディア属性情報を付加的メモリ４２１にキャッシュ(cach)し、このＩＮＶＩＴＥメッセージをターゲットＰｏＣクライアントに伝送する。
【００５７】
ＣＦは、ステップ５０４で、受信された応答メッセージがＩＮＶＩＴＥメッセージに対する最初の応答メッセージであるか否かを判定する。ステップ５０４で、受信された応答メッセージが最初の応答メッセージであると判定された場合に、ＣＦは、ステップ５０６で、最初の応答メッセージに含まれたセッション参加ＰｏＣクライアントによって支援されるメディアタイプが、ＩＮＶＩＴＥメッセージに含まれたメディアタイプと同一であるか否かを判定する。ステップ５０６で、メディアタイプがすべて同一であると判定された場合に、ＣＦは、ステップ５１４で、すべてのメディアにそれぞれＵＤＰ(User Datagram Protocol)ポート番号を割り当て、メディアを活性化する２００‘ＯＫ’応答メッセージを生成する。その後、ＣＦは、ステップ５１０で、送信側ＰｏＣクライアント、すなわちセッション開始要求ＰｏＣクライアントにこの２００‘ＯＫ’応答メッセージを伝送する。しかしながら、ステップ５０６で、メディアタイプが同一でないと判定された場合には、ＣＦは、ステップ５０８で、最初の応答メッセージに含まれたセッション参加ＰｏＣクライアントによって支援される各メディアタイプのみにＵＤＰポート番号を割り当て、メディアを活性化する２００‘ＯＫ’応答メッセージを生成する。ＵＤＰは、ＲＦＣ(Request For Comments)７６８に定義され、ＣＭＴＰ(Continuous Media Transport Protocol）として使用される。以後、ＣＦは、ステップ５１０で、送信側ＰｏＣクライアント、すなわちセッション開始要求ＰｏＣクライアントに２００‘ＯＫ’応答メッセージを伝送する。
【００５８】
ステップ５０４で、受信された応答メッセージが最初の応答メッセージでないと判定された場合には、ＣＦは、ステップ５１６で、ＵＤＰポートが割り当てられたメディアが、受信された応答メッセージに含まれているか否かを判定する。ステップ５１６で、割り当てられたポート番号を有し、活性化されるメディアタイプが受信された応答メッセージに含まれたと判定されると、ＣＦは、ステップ５１８で、該当ターゲットＰｏＣクライアントのＳＩＰ ＵＲＩ情報のみをコンファレンス情報としてアップデートする。以後、ＣＦは、ステップ５１２で、セッションを維持し、受信されたＲＴＰメディアを伝送する。ステップ５１６で、割り当てられたポート番号を有し、活性化されるメディアタイプが、受信された応答メッセージに含まれていない場合、すなわちＵＤＰポート番号が割り当てられていない各メディアに対して、ＣＦは、ステップ５２０で、受信された応答メッセージと格納されたメディア属性情報に含まれたメディアタイプを比較して得られた共通メディアタイプ情報を含むｒｅ-ＩＮＶＩＴＥメッセージを生成する。ＣＦは、ステップ５２２で、上記ｒｅ-ＩＮＶＩＴＥメッセージを送信側ＰｏＣクライアントに伝送する。ＣＦは、ステップ５２４で、送信側ＰｏＣクライアントから応答メッセージを受信し、セッションをアップデートする。その後、ＣＦは、ステップ５１２で、セッションを維持し、受信されたＲＴＰメディアを伝送する。
【００５９】
図６は、本発明によるＰｏＣマルチメディアサービスを提供するために、ＰｏＣクライアントとＰｏＣサーバとの間で多様なメディアタイプを支援するマルチメディアＰｏＣセッションを開設及び維持するＰｏＣクライアントとＰｏＣサーバとの間の信号フローを示す図である。特に、図６は、アドホック(ad-hoc)グループセッションを開設する実施形態を示しているが、本実施形態は、本明細書で提案する同一の原理によって所定の(pre-arranged)グループにも適用できる。
【００６０】
図６を参照すると、ステップ６００で、ＰｏＣセッションの開設を所望するＰｏＣクライアントＡ５０がＩＮＶＩＴＥメッセージをＣＦ５１に伝送すると、ＣＦ５１は、ステップ６０１〜６０５で、ＰｏＣセッションに招待されたターゲットＰｏＣクライアントにＩＮＶＩＴＥメッセージを伝送する。このセッション開設要求ＰｏＣクライアントＡ５０から伝送されたＩＮＶＩＴＥメッセージは、ＰｏＣクライアントＡ５０によって要求されるメディアタイプと、そのボディー部分でターゲットＰｏＣクライアントのアドレス情報とを含む。図６に示す本実施形態では、ＩＮＶＩＴＥメッセージに含まれたＰｏＣクライアントＡ５０によって要求されるメディアタイプが、オーディオ、ビデオ、及びテキストであると仮定する。ＣＦ５１は、ＰｏＣクライアントＡ５０から伝送されたＩＮＶＩＴＥメッセージに含まれたメディアタイプの詳細なメディア属性情報であるＲＴＰメディアマッピング情報、コーデックモード、及び符号化率情報のような情報を付加的メモリ４２１にキャッシュする。
【００６１】
ＣＦ５１からＩＮＶＩＴＥメッセージを受信した各ターゲットＰｏＣクライアントは、支援可能なメディアタイプ情報を含む応答メッセージをＣＦ５１に伝送する。図６に示した実施形態で、ＰｏＣクライアントＢ５３によって支援されるメディアタイプがオーディオタイプであり、ＰｏＣクライアントＣ５５によって支援されるメディアタイプがオーディオ及びテキストタイプであり、ＰｏＣクライアントＤによって支援されるメディアタイプがビデオとテキストタイプであり、ＰｏＣクライアントＥによって支援されるメディアタイプがオーディオタイプであると仮定する。
【００６２】
最初のＳＩＰ２００‘ＯＫ’応答メッセージが、ＩＮＶＩＴＥメッセージに応答してＰｏＣサーバＢ５２を通じてＰｏＣクライアントＢ５３から受信されると、ＣＦ５１は、ステップ６０６〜６０８で、最初のＳＩＰ２００‘ＯＫ’応答メッセージに含まれたＰｏＣクライアントＢ５３によって支援されるメディアタイプを分析する。ＣＦ５１は、最初のＳＩＰ２００‘ＯＫ’応答メッセージに含まれたＰｏＣクライアントＢ５３によって支援されるメディアタイプと、メモリ４２１に格納されたメディアタイプとを比較する。図６に示した本実施形態では、ＰｏＣクライアントＡ５０によって要求されるメディアタイプがオーディオ、ビデオ、及びテキストタイプであり、ＰｏＣクライアントＢ５３によって支援されるメディアタイプはオーディオタイプであるため、その比較結果は同一でないケースに該当する。この場合、ＣＦ５１は、最初のＳＩＰ２００‘ＯＫ’応答メッセージに含まれたＰｏＣクライアントＢ５３によって支援されるオーディオタイプのみにＵＤＰポート番号を割り当てる２００‘ＯＫ’応答メッセージを生成し、メディア伝送を活性化する(ここて、ＵＤＰポート番号は、本発明の一実施形態によって初期に提案されたすべてのメディアタイプに割り当てられることができる)。ＣＦ５１は、ステップ６０９で、ＰｏＣクライアントＡ５０に２００‘ＯＫ’応答メッセージを伝送する。このＣＦ５１は、最初に提供されたメディアタイプ、すなわちオーディオ、ビデオ、テキストタイプ、メディア属性情報及び最初応答したメディアタイプ、すなわちオーディオタイプを固有のコンファレンス情報として格納し、それによってセッションアップデートは、応答メッセージ内のメディアタイプ特性によって以後に遂行される。
【００６３】
ＰｏＣクライアントＢ５３によって支援されるメディアタイプが、メモリ４２１に格納されたメディアタイプと同一である場合に、ＣＦ５１は、すべてのメディアにＵＤＰポート番号を割り当て、メディアを活性化する２００‘ＯＫ’応答メッセージを生成する。その後、ＣＦ５１は、ＰｏＣクライアントＡ５０に２００‘ＯＫ’応答メッセージを伝送する。
【００６４】
一方、第２の応答メッセージが、ステップ６１０〜６１１でＰｏＣクライアントＣ５５から受信された場合、ＣＦ５１は、ＰｏＣクライアントＣ５５から伝送される２００‘ＯＫ’応答メッセージに含まれたメッセージボディーを分析してＰｏＣクライアント５５によって支援されるメディアタイプを判定する。上記したように、ＰｏＣクライアントＣ５５によって支援されるメディアタイプがオーディオ及びテキストタイプであるため、第２の応答メッセージは、オーディオ及びテキストタイプを支援する応答メッセージである。このとき、ＣＦ５１は、メモリ４２１に格納されたコンファレンス情報を読み取ることによって、ＰｏＣクライアントＡ５０とＣＦ５１との間でオーディオに加えてテキストを伝送するためにセッションアップデートを遂行する。オーディオとテキストを伝送するセッションのアップデートのために、ＣＦ５１は、ステップ６１２で、オーディオとテキストタイプ情報を含むｒｅ-ＩＮＶＩＴＥを生成し、このｒｅ-ＩＮＶＩＴＥをＰｏＣクライアントＡ５０に伝送する。ＣＦ５１は、ステップ６１３で、ＰｏＣクライアントＡ５０から応答メッセージを受信すると、セッションをアップデートする。
その後、ＣＦ５１は、セッションを維持し、受信されたＲＴＰメディアを伝送する。
【００６５】
また、ＣＦ５１は、ステップ６１３で、テキストを支援するために、セッションアップデート応答によって格納されたコンファレンス情報をアップデートする。このセッションアップデートは、格納されたメディア属性情報からテキストに対する属性情報を用いて生成されたｒｅ-ＩＮＶＩＴＥメッセージを使用する。以下、このｒｅ-ＩＮＶＩＴＥメッセージのボディー部分について、図６Ｃを参照して詳細に説明する。
【００６６】
２００‘ＯＫ’応答メッセージは、ステップ６１４，６１５で、他のＰｏＣクライアント、すなわちＰｏＣクライアントＥとＰｏＣクライアントＤから受信される場合に、２００‘ＯＫ’応答メッセージのそれぞれのボディー部分が分析され、各２００‘ＯＫ’応答メッセージに含まれたメディアタイプ情報が、ＰｏＣ該当クライアントＡ５０とＣＦ５１との間のセッションで支援されるメディアタイプに該当する場合には、セッションアップデートが遂行されずに、対応するＰｏＣクライアントのアイデンティティ情報のみがコンファレンス情報にアップデートされる。すなわち、ＰｏＣクライアントＥから受信された２００‘ＯＫ’応答メッセージによって、ＰｏＣクライアントＥによって支援されるメディアタイプであるオーディオタイプは、ＰｏＣクライアントＡ５０とＣＦ５１との間のセッションで支援されるメディアタイプであるため、別のメディアタイプアップデートは遂行されない。しかしながら、ＰｏＣクライアントＤから受信された２００‘ＯＫ’応答メッセージによって、ＰｏＣクライアントＤによって支援されるメディアタイプの中でビデオタイプが、新たに支援されるメディアタイプであるため、オーディオ、テキスト、ビデオタイプを伝送するセッションアップデートは、ステップ６１２，６１３のようにステップ６１６、６１７で遂行される。上述したように、ｒｅ-ＩＮＶＩＴＥメッセージは、ステップ６１６で、ビデオタイプの格納された属性情報を用いて生成され、ＰｏＣクライアントＡ５０に伝送され、２００‘ＯＫ’応答メッセージは、ｒｅ-ＩＮＶＩＴＥメッセージに応答して受信され、それによってオーディオ、ビデオ、及びテキストを支援するためのセッションをアップデートする。
【００６７】
その後、ＣＦ５１が、ステップ６１８で、ＰｏＣクライアントＦから２００‘ＯＫ’応答メッセージを受信しても、ＰｏＣクライアントＦによって支援されるメディアタイプであるオーディオ及びビデオタイプは、ＰｏＣクライアントＡ５０とＣＦ５１との間でセッションによって支援されるメディアタイプに該当するため、別途のメディアタイプアップデートは遂行されない。
【００６８】
図６でＡＣＫ(ACKnowledgement)信号及び発言権を管理するためのＭＢＣＰ(Media Burst Control Protocol）の詳細な手順は、便宜上省略する。しかしながら、上記したように追加的なメディアアップデートが遂行される場合に、ＳＩＰメッセージを用いてセッションをアップデートし、ＰｏＣクライアントＡ５０は、ＣＦ５１によって支援されるメディアタイプに従って該当メディアに対するメディアバースト要求メッセージを伝送し、ＣＦ５１によって支援されるメディアタイプに従ってメディアバースト付与メッセージを受信する。
【００６９】
初期招待されたグループメンバーと共に他のＰｏＣクライアントがセッションに参加する場合に、クライアントによって要求されるメディアタイプ及び属性情報が、セッションに存在するメディアタイプと異なると、ＰｏＣクライアントのセッション参加は、サービス提供者のポリシーによって拒絶又は許容することができる。ＰｏＣクライアントのセッション参加を許諾する場合に、メディアタイプをアップデートするセッションｒｅ-ＩＮＶＩＴＥメッセージ及びセッションで使用されない属性情報は、本発明の原理を使用するセッションに参加するすべてのＰｏＣクライアントから要求されることができる。このとき、セッションアップデートは、図６に示したように遂行される。
【００７０】
セッションｒｅ-ＩＮＶＩＴＥメッセージは、同一の目的でセッション特性をアップデートするための他のＳＩＰメッセージを用いて伝送されることができる。
【００７１】
図６に示した実施形態をより詳細に説明するために、図７及び図８は、対応するＳＩＰメッセージの中からメディアタイプ及び属性情報のみを示す。図７Ａ、図７Ｂ、図７Ｃは、図６に示したステップ６００，６０９，６１２で、伝送されたＳＩＰメッセージに含まれたＳＤＰボディー部分のメディアタイプ情報を各々示す。ステップ６０９で、応答メッセージは、図７Ａで提案されたオーディオ、ビデオ、及びテキストの中からオーディオのみを伝送できる状態にあり、他のメディアタイプは、図７Ｂに示すように、そのＵＤＰポート番号が０に設定されることによって伝送されることができない。テキストは付加的に支援されるため、ステップ６１２で、オーディオ及びテキストは、図７Ｃに示すように、テキストに対してＵＤＰポート番号を割り当てることによって伝送されることができる。ステップ６１６で、メディアは、すべてのメディアタイプに対してＵＤＰポート番号を割り当てることによって伝送されることができる。
【００７２】
図８Ａ、図８Ｂ、図８Ｃは、図７Ａ、図７Ｂ、図７Ｃの他の実施形態であって、図６に示したステップ６００，６０９，６１２で、伝送されたそれぞれのＳＩＰメッセージに含まれるＳＤＰボディー部分のメディアタイプ情報を示す。ステップ６０９で、応答メッセージは、図８Ａに提案されたオーディオ、ビデオ、及びテキストの中からオーディオのみを伝送できる状態にあり、他のメディアタイプは、図８Ｂに示すように‘ｉｎａｃｔｉｖｅ'、すなわち他のメディアタイプに、対応するメディアタイプが伝送できないことを示すメディア特性値にによって伝送されることができない。テキストがステップ６１２で追加的に支援されるため、図８Ｃのように、‘ｉｎａｃｔｉｖｅ’のメディア特性値は、ビデオのみに適用されることができる。ステップ６１６で、すべてのメディアタイプは、‘ｉｎａｃｔｉｖｅ’のメディア特性値を除去することによって伝送されることができる。
【００７３】
また、セッションに使用されないメディアタイプ及び属性情報をアップデートする方法において、ＲＴＣＰ ＡＰＰメッセージ、すなわちＭＢＣＰメッセージを伝送することができる。最初の応答メッセージに対応して、図６でＰｏＣクライアントＡ５０とＣＦ５１との間では初期に提案されたすべてのメディアタイプに対してＵＤＰポート番号を割り当て、メディアパラメータ(コーデック、発言権管理プロトコル、及びＩＰアドレス）の交渉を完了したセッションが開設される。すなわち、ステップ６０９で、２００‘ＯＫ’メッセージが受信された後に、ビデオ及びテキストに対するＵＤＰポート番号とコーデック情報が交渉され、該当メディアタイプが伝送されたか否かを示すメディア特性値が‘ｉｎａｃｔｉｖｅ’として設定された部分活性化セッションは、ＰｏＣクライアントＡ５０とＣＦ５１との間で開設される。メディアタイプの発言権管理プロトコルも交渉されるため、該当メディアタイプに対するＭＢＣＰメッセージを伝送するＲＴＣＰのポート番号及びＭＩＭＥパラメータも設定される。したがって、図６の説明と類似した手順を通じて、ＣＦ５１が他のＰｏＣクライアントから非活性化メディアタイプを支援する応答メッセージを受信すると、ＣＦ５１は、ＲＴＣＰチャンネルを介してＭＢＣＰメッセージを伝送することによってＰｏＣクライアントＡ５０とＣＦ５１との間の部分活性化セッションをアップデートする。
【００７４】
このような方法で、最初の応答メッセージの受信後に、新たなメディアタイプを支援する応答メッセージを受信する場合に、ＣＦ５１は、伝送特性値をアップデートするＭＢＣＰメッセージをＰｏＣクライアントＡ５０に伝送し、以後、ＭＢＣＰ ＡＣＫが受信されると、ＣＦ５１は、該当メディアタイプが新たなメディアタイプに対して‘ｓｅｎｄｒｅｃｖ'に伝送されるか否かを示すメディア特性値を変更する。また、ＰｏＣクライアントＡ５０は、ＣＦ５１から受信される特定メディアタイプに対するＭＢＣＰメッセージに基づいて新たなメディアタイプに対するメディア特性値を‘ｉｎａｃｔｉｖｅ'から‘ｓｅｎｄｒｅｃｖ'に変更することによって、新たなメディアタイプを伝送するためにセッションをアップデートする。
【００７５】
例えば、この方法により、図６に示したステップ６１２及び６１６でｒｅ-ＩＮＶＩＴＥメッセージは、ＭＢＣＰメッセージ(例えば、ＭＢＣＰ接続メッセージ)に代替可能であり、ステップ６１３及び６１７でＭＢＣＰ ＡＣＫメッセージを受信することによって非活性化メディアタイプであるテキストとビデオが各々活性化される。通常、本発明で使用される‘メディアタイプ’は、オーディオ、ビデオ、イメージ、テキストのようなメディア特性を区分する情報として使用される。また、この‘メディアタイプ’は、発明の拡張された技術として同一のメディアタイプを区別する最小の基本単位で扱われる。例えば、２個の相互に異なるビデオ(第１のビデオ及び第２のビデオ)が存在すると、すなわち同一のメディアタイプである第１のビデオと第２のビデオが各々存在すると、その第１及び第２のビデオは、各々接続されたメディアパラメータの特性によって相互に異なるメディアタイプとして考えられる。したがって、‘メディアタイプ’は、同一のメディアタイプを示すことができ、メディアストリームを区分する最小の基本単位として拡張して使用することもできる。
【００７６】
したがって、拡張された技術の実施形態として、送信側ＰｏＣクライアントが第１のオーディオ、第２のオーディオ、第１のビデオ、第１のビデオのメディアタイプを含むセッション開設を要求した場合に、ホームＰｏＣサーバは、ターゲットネットワークから受信されたＳＩＰ応答メッセージで採択されたメディアタイプに関係なく、初期提案された全体メディアタイプ(第１のオーディオ、第２のオーディオ、第１のビデオ、及び第１のビデオ）を伝送するＰｏＣセッションを開設することができる。
【００７７】
以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲を外れない限り、様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。したがって、本発明の範囲は、前述の実施形態に限定されるものではなく、特許請求の範囲の記載及びこれと均等なものに基づいて定められるべきである。
【符号の説明】
【００７８】
１００ ＰｏＣ端末
１０２ ＰｏＣクライアント
１２０ ＳＩＰ／ＩＰコアネットワーク
１５０ ＰｏＣサーバ
４００ ディスプレイ部
４０２ 制御部
４０４ ユーザーインターフェース
４０５ メモリ
４１０ データ伝送部
４２０ データ伝送部
４２１ メモリ
４３０ 多重マルチメディア通話サービス処理部
４４０ 参加ＰｏＣ機能コンポーザー
【技術分野】
【０００１】
本発明は、マルチメディア通話サービスを遂行するためのマルチメディアＰｏＣ(Pushto talk over Cellular)セッション開設及び管理システムとその方法及びユーザー端末(User Equipment：ＵＥ)に関するもので、特に、ＰｏＣクライアントによって支援される多様なメディアタイプがＰｏＣセッション開設に共通でない場合、あるいは最初の応答メッセージに含まれた伝送可能なメディアタイプが送信側によって提供されるメディアタイプと異なる場合、このＰｏＣセッションで少なくとも一つの受信可能なＰｏＣクライアントによって支援されたメディアタイプのみを支援するＰｏＣセッション開設のためのシステムとその方法及びユーザー端末に関する。
【背景技術】
【０００２】
移動通信の重要な発展と通信ネットワークの拡大は、携帯電話を用いる多様な追加サービスとアプリケーションを提供する。同時に、位置サービス、マルチメディアサービス、及びＰＴＴ(Push-To-Talk)サービスのような多様な追加サービスに対する携帯電話ユーザーの要求も増加している。これら追加サービスの中で、ＰＴＴサービスは、従来の無線又はＴＲＳ(Trunked Radio System)によって提供されるグループ通話及び音声通話だけでなく、インスタントメッセンジャー機能及び状態表示機能のような多様な付加機能を支援する。
【０００３】
現在、移動通信ネットワークでＰＴＴ機能を使用するＰｏＣ(PTT-over-Cellular)サービスの標準化が、活発に論議されている。既存の移動通信サービスと区別されるＰｏＣサービスのユニークな特徴の一つは、ユーザーが複数のＰｏＣセッションに参加し、通話サービスを利用するためにこのＰｏＣセッションの間を移動することができるということである。ユーザーが通話サービスを使用するために複数のＰｏＣセッションの間を移動できる要求事項は、多重セッション機能に対する要求事項は移動通信サービスを規定する団体であるＯＭＡ(Open Mobile Alliance）に明示されている。
【０００４】
一方、ＰｏＣ Ｖ２.０システムは、ＰｏＣマルチメディア通話サービスを支援する。このＰｏＣマルチメディア通話サービスを支援するために、ＰｏＣ Ｖ２.０システムは、音声だけでなく、ビデオ、イメージ、及びテキストを新たなマルチメディアタイプとして定義する。
【０００５】
現在のＰｏＣシステムは、ユーザー端末(User Equipment：ＵＥ)の性能向上のため、ビデオ及び/又はイメージのような多重ストリームをディスプレイできる。上記したように、ＰｏＣ Ｖ２.０システムが従来のＰｏＣ Ｖ１.０のセッション開始方法及びシステムを使用すると、ＰｏＣ Ｖ２.０システムによって支援される多様なマルチメディアサービスは制限され、セッション開始時間が長くかかるという問題点があった。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】国際公開第２００６／００６８９７号
【特許文献２】特表２００６−５１３６１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
したがって、本発明は上記従来の問題点に鑑みてなされたものであって、その一態様による目的は、ＰｏＣマルチメディア通話サービスを遂行するＰｏＣクライアントが、複数のメディアタイプを支援し、ＰｏＣクライアントによって支援されるメディアタイプが共通でない場合、あるいは最初の応答メッセージに含まれた伝送可能メディアタイプが送信側によって提供されたメディアタイプと異なる場合に、該当ＰｏＣセッションで少なくとも一つの受信ＰｏＣクライアントによって支援されるメディアタイプのみを支援するＰｏＣセッションを開設するためのシステムとその方法及び端末装置(ＵＥ)を提供することにある。
【０００８】
本発明の他の態様による目的は、新たなメディアタイプが新たな参加者によって支援される場合、または既存のメディアタイプの受信者が変更される場合に、変更される情報を自動にアップデートしてセッションを管理するシステムとその方法及びＵＥを提供することにある。
【０００９】
また、本発明の他の態様による目的は、セッション開始クライアントから受信されるセッション参加要求(ＩＮＶＩＴＥ)メッセージに含まれたメディアタイプの属性(attribute）を格納し、最初の応答に対応してセッションが開設された後に、ＩＮＶＩＴＥメッセージで提供されるメディアタイプ及びメディア属性を支援する新たな参加者が該当セッションに参加する場合に、格納されたメディア属性をアップデートされるセッションで提供するようにセッションをアップデートするためのシステムとその方法及びＵＥを提供することにある。
【課題を解決するための手段】
【００１０】
上記のような目的を達成するために、本発明の一態様によれば、マルチメディア通話サービスを遂行するためのマルチメディアセッション開設及び管理のためのサーバであって、セッション開始要求クライアント及び少なくとも一つのセッション参加クライアントとのパケットデータ送受信を遂行するデータ送受信部と、セッション参加要求メッセージに含まれたメディア属性情報と少なくとも一つのメディアタイプを格納するメモリと、前記セッション参加要求メッセージの受信、メディア属性情報と少なくとも一つのメディアタイプの格納、セッション参加クライアントにより支援される少なくとも一つのメディアタイプを含む最初応答メッセージの受信、及び前記最初応答メッセージに含まれた少なくとも一つのメディアタイプとメモリに格納された前記少なくとも一つのメディアタイプとを比較して、前記メディアタイプを支援するマルチメディア通信セッションを開設するセッション開設要求クライアントに応答メッセージの伝送を制御するセッション処理部と、含むことを特徴とする。また、本発明の一態様によれば、マルチメディア通話サービスを遂行するためのマルチメディアＰｏＣセッション開設及び管理のためのＰｏＣシステムであって、メディアタイプ及びメディア属性情報を含むセッション参加要求(ＩＮＶＩＴＥ)メッセージをＰｏＣサーバに伝送するセッション開始要求ＰｏＣクライアントと、ＩＮＶＩＴＥメッセージに含まれたメディアタイプ及びメディア属性情報を格納し、最初の応答メッセージが受信されると、最初の応答メッセージでメディア伝送のために設定するメディアタイプのみを支援するＰｏＣセッションを開設するために、最初の応答メッセージに含まれたメディアタイプが伝送可能な状態であることを示す応答メッセージをセッション開始要求ＰｏＣクライアントに伝送するＰｏＣサーバとを含むことを特徴とする。
【００１１】
本発明の他の態様によれば、セッション開始要求ＰｏＣクライアント、少なくとも一つのセッション参加ＰｏＣクライアント、及びマルチメディアＰｏＣセッションを開設及び管理するためのＰｏＣサーバを含むＰｏＣシステムにおいて、マルチメディア通話サービスを遂行するためのマルチメディアＰｏＣセッションを開設及び管理するための方法であって、セッション開始要求ＰｏＣクライアントがメディアタイプ及びメディア属性情報を含むＩＮＶＩＴＥメッセージをＰｏＣサーバに伝送する第１のプロセスと、ＰｏＣサーバがＩＮＶＩＴＥメッセージに含まれたメディアタイプ及びメディア属性を格納する第２のプロセスと、最初の応答メッセージが受信されると、ＰｏＣサーバは、最初の応答メッセージに含まれたメディアタイプが伝送可能な状態であることを示す応答メッセージをセッション開始要求ＰｏＣクライアントに伝送してＰｏＣセッションを開設する第３のプロセスとを有することを特徴とする。
【００１２】
また、本発明の他の態様によれば、ＰｏＣシステムにおけるマルチメディア通話サービスを遂行するためのマルチメディアＰｏＣセッションの開設及び管理のための端末装置であって、ＰｏＣサーバとのパケットデータの送受信を遂行するデータ伝送部と、セッション開設のために要求されるメディアタイプ及びメディア属性情報を含むＩＮＶＩＴＥメッセージを伝送し、現在セッションで支援される特定のメディアタイプ情報を含むｒｅ-ＩＮＶＩＴＥメッセージが受信された場合に、ｒｅ-ＩＮＶＩＴＥメッセージに対する応答メッセージを伝送するためにデータ伝送部を制御する制御部とを含むことを特徴とする。
【００１３】
好ましく、ＰｏＣシステムは、ＩＮＶＩＴＥメッセージを送信するセッション開始要求ＰｏＣクライアントと、上記ＰｏＣクライアントからＩＮＶＩＴＥメッセージを受信し、ＩＮＶＩＴＥメッセージに対する応答メッセージをセッション開始要求ＰｏＣクライアントに伝送するＰｏＣサーバと、メディアタイプ情報を含む応答メッセージを格納するセッションメディアタイプ及び属性臨時格納部とを含む。
【００１４】
好ましく、メディアタイプ情報は、ＳＩＰ(Session Initiation Protocol)ＩＮＶＩＴＥメッセージとＳＩＰ２００‘ＯＫ’メッセージのボディー部分或いはＲＴＣＰ(Real-ime Transport Control Protocol)メッセージフォーマットにメディアタイプ情報のための新たなカラム(column)を追加する形態で通知できる。
【００１５】
本発明は、ＯＭＡ ＰｏＣマルチメディア通話サービスを遂行するＰｏＣクライアントが、ＰｏＣセッションの開設時にＰｏＣクライアントによって支援される多様なメディアタイプが相互に共通でない場合、或いは最初の応答メッセージに含まれた伝送可能メディアタイプが送信側で提供されたメディアタイプと異なる場合に、該当ＰｏＣセッションで少なくとも一つの受信ＰｏＣクライアントによって支援される(すなわち、該当メディアタイプを送受信できるＰｏＣクライアントが２個以上である)メディアタイプのみを支援するＰｏＣセッションを開設し、以後該当セッションで任意の参加者がセッションを終了し、あるいは新たな参加者がセッションに参加する場合に、セッションアップデートを通じて少なくとも一つの受信ＰｏＣクライアントによって支援されるメディアタイプだけを追加または除去するためのＰｏＣシステムにおけるセッション管理システムとその方法及び端末装置を提案する。
【発明の効果】
【００１６】
本発明は、マルチメディア通話サービスを遂行するＰｏＣクライアントが複数のメディアタイプを支援し、ＰｏＣクライアントによって支援されるメディアタイプが共通でない場合に、ＰｏＣセッションで少なくとも一つのターゲットＰｏＣクライアントによって支援されるメディアタイプのみを支援するＰｏＣセッションが開設されることができる。
【００１７】
また、本発明は、新たなメディアタイプが新たな参加ＰｏＣクライアントによって提供され、既存のセッションで支援されるメディアタイプの受信者が変更されると、変更をアップデートしてセッションを管理する方法を提供することによって、セッションが、新たなメディアタイプの追加又は既存のメディアタイプの除去に対応して活発に管理されることができる。
【００１８】
さらに、本発明は、メディアタイプ情報がアップデートされる必要がある場合に、追加手順なしに該当セッションにアップデート内容を反映するために、最初のＰｏＣセッション開始によって提供されたメディアタイプ及びメディア属性情報を格納し、それによって無線伝送の効率性を向上させ、ＰｏＣサービスのユーザー経験を向上させる効果がある。
【図面の簡単な説明】
【００１９】
【図１】一般のＰｏＣシステムを示す回路図である。
【図２】一般のＰｏＣサーバを示すブロック構成図である。
【図３】ＰｏＣサーバのＣＦ(Controlling PoC Function)及びＰＦ(Participating PoC Function)を示すブロック構成図である。
【図４】本発明の一実施形態により、相互に接続されたＰｏＣクライアントを含むＰｏＣ端末とＰｏＣサーバとを示すブロック構成図である。
【図５】本発明の一実施形態により、コンファレンス(conference)ＰｏＣサーバが多様なメディアタイプを要求するセッション参加要求(ＩＮＶＩＴＥ)メッセージを受信する場合に、マルチメディアＰｏＣセッションを開設するプロセスを示すフローチャートである。
【図６】本発明の一実施形態により、多様なメディアタイプを支援するＰｏＣクライアント間の効率的なセッションの開始及び管理のためのＰｏＣクライアントとＰｏＣサーバとの間の信号フローを示す図である。
【図７Ａ】本発明の一実施形態により、ＰｏＣセッションが開設された場合に、ＩＮＶＩＴＥメッセージに含まれたＳＤＰ(Session Description Protocol)オファー(offer)及びＵＰＤＡＴＥ又はｒｅ-ＩＮＶＩＴＥメッセージに含まれたＳＤＰオファーを示す図である。
【図７Ｂ】本発明の一実施形態により、ＰｏＣセッションが開設された場合に、ＩＮＶＩＴＥメッセージに含まれたＳＤＰ(Session Description Protocol)オファー(offer)及びＵＰＤＡＴＥ又はｒｅ-ＩＮＶＩＴＥメッセージに含まれたＳＤＰオファーを示す図である。
【図７Ｃ】本発明の一実施形態により、ＰｏＣセッションが開設された場合に、ＩＮＶＩＴＥメッセージに含まれたＳＤＰ(Session Description Protocol)オファー(offer)及びＵＰＤＡＴＥ又はｒｅ-ＩＮＶＩＴＥメッセージに含まれたＳＤＰオファーを示す図である。
【図８Ａ】本発明の一実施形態により、ＰｏＣセッションが開設された場合に、ＩＮＶＩＴＥメッセージに含まれたＳＤＰオファー及びＵＰＤＡＴＥ又はｒｅ-ＩＮＶＩＴＥメッセージに含まれたＳＤＰオファーを示す図である。
【図８Ｂ】本発明の一実施形態により、ＰｏＣセッションが開設された場合に、ＩＮＶＩＴＥメッセージに含まれたＳＤＰオファー及びＵＰＤＡＴＥ又はｒｅ-ＩＮＶＩＴＥメッセージに含まれたＳＤＰオファーを示す図である。
【図８Ｃ】本発明の一実施形態により、ＰｏＣセッションが開設された場合に、ＩＮＶＩＴＥメッセージに含まれたＳＤＰオファー及びＵＰＤＡＴＥ又はｒｅ-ＩＮＶＩＴＥメッセージに含まれたＳＤＰオファーを示す図である。
【発明を実施するための形態】
【００２０】
以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。
下記に、ＰＴＴシステム、特にセルラー移動通信ネットワークを使用するＰＴＴサービ
スを提供するＰｏＣシステムに本発明を適用する場合について説明する。
【００２１】
一般に、ＰｏＣシステムは、グループＰｏＣ通話のセッション参加情報を伝送するためにＳＩＰ(Session Initiation Protocol)及びＳＩＰ拡張プロトコルを使用し、グループ情報を獲得するためにＸＣＡＰ(XML Configuration Access Protocol)を使用する。後術する本発明の機能は、上記したプロトコルを用いて実現でき、本発明の基本構成はＰｏＣ Ｒｅｌ.１システムに基づいてなされる。
【００２２】
まず、本発明が適用される一般のＰｏＣシステムの構成について説明する。
図１は、通常のＰｏＣシステム及び関連ネットワーク構造を示す概念図である。
図１を参照すると、通常のＰｏＣシステムはＰｏＣ端末１００、ＸＤＭＳ(XML Document Management Server)１３０，１４０、及びＰｏＣサーバ１５０を含むことができる。ＰｏＣシステムは、アグリゲーションプロキシサーバ１６０をさらに含む。これら構成要素は、アクセスネットワーク１１０、ＳＩＰ/ＩＰ(Internet Protocol)コアネットワーク１２０、及び遠隔ＰｏＣネットワーク１７０を通じて接続される。
【００２３】
次に、上記の構成要素について説明する。
ＰｏＣ端末１００は、ＰｏＣクライアント１０２及びＸＤＭＣ(XML(eXtensible Markup Language) Document Management Client)１０４を含む。
【００２４】
ＰｏＣクライアント１０２は、ＰｏＣ端末１００に内蔵されるサービス要求者であって、ＰｏＣサービス加入者にＰｏＣサービスを提供するためのネットワークアクセスを遂行するためにＰｏＣ端末１００に備えられる。ＰｏＣサービス加入者は、ＰｏＣクライアントが内蔵されたＰｏＣ端末を通じてＰｏＣサービスを受信できる。以下、用語“ＰｏＣクライアント”は、ＰｏＣクライアントが内蔵されたＰｏＣ ＵＥ及びＰｏＣサービス加入者として使用される。また、特に明記されない限り、 ＰｏＣクライアントの参照符号は省略する。
【００２５】
ＰｏＣクライアントは、主にＰｏＣサービス加入者、すなわちＰｏＣユーザーの側面でＰｏＣセッションを開設し、既存のＰｏＣセッションに参加し、あるいは開設されているセッションを終了する役割を果たす。また、ＰｏＣクライアントは、トークバーストを生成及び伝送する機能、緊急個人警報(Instant Personal alert)を支援する機能、及びＰｏＣサービスにアクセスする場合に要求される認証機能を遂行する。ＰｏＣクライアントは、アクセスネットワーク１１０を通じて、ＳＩＰ/ＩＰマルチメディア支援コアネットワークであるＳＩＰ/ＩＰコアネットワーク１２０に接続されることができる。
【００２６】
ＳＩＰ/ＩＰコアネットワーク１２０は、ＰｏＣサービスを支援するために、ＰｏＣサーバ１５０、ＸＤＭＳ１３０，１４０に接続される。このとき、ＰｏＣサーバ１５０は、ＰｏＣセッションを維持及び管理する制御ＰｏＣ機能(Controlling PoC Function)を遂行し、あるいは一対一のＰｏＣ通話または一対多のＰｏＣ通話のために開設されたＰｏＣセッションに参加するための参加ＰｏＣ機能(Participating PoC Function)を遂行できる。
【００２７】
一方、ＰｏＣサービスは、コンファレンス通話のように、グループセッションを開設するサービスを含むことができる。このサービスのために、ＯＭＡ(Open Mobile Alliance)標準は、グループリストサービスのためのＸＤＭＣ１０４及びＸＤＭＳ１３０，１４０を定義する。図１は、ＰｏＣサービスのために使用されるＰｏＣ ＸＤＭＳ１４０と、他のサービスイネーブラ(enabler)のために共通に使用される共有ＸＤＭＳ１３０とを示す。グループ及びグループメンバーに関する情報は、ＰｏＣクライアントを通じてＸＤＭＳ１３０，１４０に入力されることができる。ＰｏＣクライアントは、ＸＤＭＳ１３０，１４０から伝送された個人又はグループリストを用いて呼出できるＰｏＣクライアントに関する情報を獲得できる。ＸＤＭＳ１３０，１４０におけるグループ及びグループメンバーの生成、変更、及び管理は、ＰｏＣサービス提供者が信頼できるインターネット又はイントラネットのような通信ネットワークを通じてなされることができる。グループリストを生成、変更、及び除去するＸＭＬ文書管理のプロトコルの詳細な説明は省略する。
【００２８】
グループサービスに対するグループリスト関連要求がＸＤＭＣ１０４から受信された場合に、アグリゲーションプロキシサーバ１６０は、適切な規則に従ってＸＤＭＳ１３０，１４０にグループリスト関連要求をルーティングする。
【００２９】
次に、図２を参照してＰｏＣサーバ１５０について説明する。
図２は、一般のＰｏＣサーバを示すブロック構成図である。
ＰｏＣサーバは、ＰｏＣセッションを全体的に保持及び管理する制御ＰｏＣ機能(Controlling PoC Function：以下、“ＣＦ”と称する）部とセッションを管理するための参加ＰｏＣ機能(Participating PoC Function：以下、“ＰＦ”と称する)部に分類されることができる。ＰｏＣサーバの機能別特性は、下記の＜表１＞及び＜表２＞を参照して説明する。
【００３０】
【表１】
【００３１】
＜表１＞に示すように、ＣＦは、ＰｏＣサーバの機能中にＰｏＣセッションを全体的に管理する役割をする。ＰｏＣサーバは、ＰｏＣクライアントからの発言権(floor)に対する要求を受信し、クライアントに権限を与える順序を配列し、その順にＰｏＣクライアントに発言権を与える。また、ＰｏＣサーバは、グループＰｏＣ呼び出しに参加するすべてのＰｏＣクライアントに特定のＰｏＣクライアントからのトークバーストを分配し、グループＰｏＣ呼び出しに参加したＰｏＣクライアントの情報を提供する。
【００３２】
下記の＜表２＞に示すように、ＰＦは、ＣＦと各ＰｏＣクライアントとの間でＰｏＣセッションを管理する。特に、ＰＦは、ＰｏＣクライアントが発言権を要求した場合、又はＣＦがＰｏＣクライアントに発言権を付与する場合に、ＰｏＣクライアントとＣＦとの間で発言権を中継する役割をする。また、ＰＦは、ＣＦとＰｏＣクライアントとの間でメディアを中継し、相互に異なるコーデック間のトランスコーディングし、２個の同時ＰｏＣセッションで同時に発言している場合には、一つのユーザーによって選択された２個のＰｏＣセッションのうちの一つをフィルタリングするためのフィルタリング機能を提供する。
【００３３】
【表２】
【００３４】
図３は、ＰｏＣサーバのＣＦとＰＦを図式的に説明するためのブロック構成図である。
図３を参照すると、各ＰｏＣクライアント１０２Ａ〜１０２Ｄは、ＰＦ３１０-Ａ〜３１０-Ｄを通じてＣＦ３００にアクセスしてＰｏＣセッションを設定する。ここで、発言権がＣＦ３００から話者(talker)として資格を有するＰｏＣクライアントに与えられた場合に、資格のあるＰｏＣクライアントに基づいたメディアは、各ＰｏＣクライアントに伝送される。このとき、話者として資格が与えられたＰｏＣクライアントは、グループセッションに参加しているＰｏＣクライアントに関する情報を確認した後のみ、発言することができる。
【００３５】
ＰｏＣシステムにおいて、通話接続のための呼処理技術は、送信側と受信側の要求及び状態により多様な手順を可能にする。このような送信側と受信側の設定によってＯＭＡによって要求されるＰｏＣシステムの特徴は、次のようである。
【００３６】
第一に、受信側は、ＰｏＣクライアントの要求によって自分の応答モードを設定でき、この応答モードは、自動応答モードと手動応答モードに分類される。自動応答モードで、該当情報が受信側によって指定されたＰｏＣクライアントリストに含まれると、該当ネットワークは、受信側の受動応答の代わりに送信側の即時応答を送信する。このネットワークは、ＰｏＣ端末が応答モード設定要求によって応答モード及び自動応答ユーザーリストを格納するため、ＰｏＣ端末の動作の代わりに自動応答を送信する。手動応答モードは、送信側が自動応答ユーザーリストに含まれていない場合、又は送信側が自動応答ユーザーリストに含まれているか否か不明な場合、あるいは受信側がすべてのユーザーに対して手動応答を設定した場合に該当する。ＰｏＣ通話要求は、受信ネットワークを介してＰｏＣ端末に伝送され、ＰｏＣクライアントの許可によって通話が連結される。
【００３７】
第２に、ＰｏＣシステムは、ＰｏＣクライアントがユーザーのホームネットワークに属するＰｏＣサーバとの接続が設定されたか否かに従ってｏｎ-ｄｅｍａｎｄセッションモード又は事前開設(pre-established)セッションモードにあり得る。事前開設セッションモードは、ＰｏＣクライアントが、自分の要求によってそのホームネットワークに属するＰｏＣサーバとの間で予めセッションを設定することを示す。事前開設セッションモードは、ＰｏＣクライアントが、メディアパラメータをＰｏＣサーバと予め交渉して今後使用されるＰｏＣサーバとメディアパラメータの再交渉なしに、迅速にセッションを開設するために必要である。
【００３８】
事前開設セッションは、ＳＩＰ ＩＮＶＩＴＥ方法を用いて、メインテキスト部、すなわちＳＤＰ ＭＩＭＥ(Session Description Protocol Multipurpose Internet Mail Extensions)に支援されるメディアパラメータを提供し、ＰｏＣサーバによって提供されるメディアパラメータを提供し、ＳＩＰサーバによって提供されるメディアパラメータに応答するＰｏＣクライアントによって予め設定される。このとき、ＰｏＣサーバから受信された応答メッセージに新たに設定されるコンファレンスＵＲＩ(conference Uniform Resource Identifier)を含む事前開設セッションの識別情報は、ＰｏＣクライアントに回答する。
【００３９】
事前開設セッションが使用される場合に、インターネットプロトコル(ＩＰ)アドレス、ポート番号、使用されるコーデック、及びトークバースト制御プロトコルは、事前交渉が可能である。ｏｎ-ｄｅｍａｎｄセッションモードは、ＰｏＣクライアントがセッションを予め開設しない状態を示し、他のＰｏＣクライアントがセッションを予め設定しない状態を示し、そして他のＰｏＣクライアントからＩＮＶＩＴＥメッセージを受信した後に、ＰｏＣクライアントがＰｏＣ呼接続手順を遂行することを示す。
【００４０】
ＰｏＣシステムで通話要求に応じて、応答モードの設定は、ネットワークの要素であるＰｏＣサーバとユーザー側の端末であるＰｏＣクライアントにすべて格納されることができる。
【００４１】
応答モードがＰｏＣクライアントを管理するホームネットワークに設定される場合に、応答モードは、ＰｏＣクライアントが属しているホームネットワーク内のＰＦとして作用するＰｏＣサーバに設定される。
【００４２】
このとき、ＰｏＣ通話が他のＰｏＣサーバから要求されると、ＰＦは、遅延なしにセッション進行メッセージを通話要求ネットワークに自動に応答する。したがって、自動応答モードが設定された場合には、セッションセットアップメッセージがＰｏＣクライアントに伝送される場合に比べて、通話要求手順が簡素化され、これによって初期発言権付与時間が短縮される。
【００４３】
しかしながら、ホームネットワークで自動応答モードが設定される場合に、ユーザーが所望する応答と異なる結果が状況に従って発生する可能性があるため、応答モードは、ＰｏＣクライアントに設定されることができる。このとき、ＰｏＣクライアントの応答モードがホームネットワークに設定された応答モードより高い優先度を有する。これは、ＰｏＣクライアントがその応答モードを変更してＰｏＣサーバに応答モード更新を要求する場合に、ネットワークでの信号遅延又は誤りによってリアルタイムで応答モードが反映されない場合に発生するプライバシー(privacy)問題を解決する。
【００４４】
要約すれば、ＰｏＣサービスは、ユーザーの応答モードをＰｏＣサーバ又はＰｏＣクライアントによって設定できるが、応答モードがユーザーの所望を最近に反映したＰｏＣクライアントによって決定され、このような決定に基づいてメディアストリーム(ユーザーの音声又は映像)が伝送される。
【００４５】
以下、上述した特徴を有するＰｏＣシステムでのＰｏＣマルチメディアセッションの開設手順について説明する。
送信側ＰｏＣクライアントは、ＳＩＰを用いて、マルチメディアセッション参加要求メッセージ(マルチメディアは、メディアタイプの選択によって多様なフォーマットのオーディオ、ビデオ、及びテキストを含むことができる)を送信して呼処理を要求する。このような呼処理要求に応答して、ターゲットＰｏＣクライアントは、該当ＰｏＣサーバでの応答モードの設定と既存セッションが存在するか否かによって多様に応答する。ＰｏＣ通話のための呼処理手順については、送信側ネットワーク及びターゲットネットワークの手順を例示して説明する。
【００４６】
送信側ＰｏＣクライアントは、ターゲットＰｏＣクライアントのＳＩＰアドレス情報を含むＳＩＰセッション参加要求(ＩＮＶＩＴＥ)メッセージを該当ＳＩＰ/ＩＰコアネットワークに伝送する。このＳＩＰ ＩＮＶＩＴＥメッセージは、送信側ＰｏＣクライアントのＰｏＣアドレス情報、要求されるメディアパラメータ、ＰｏＣサービスを知らせる特性値情報などのような要素をさらに含むことができる。要求されるセッションがマルチメディアに該当すると、“要求されるメディアパラメータ”は、オーディオとビデオのエンコーディング方法、ビットレート、ペイロードタイプのような多様な特性値を含むことができる。
【００４７】
ＳＩＰ ＩＮＶＩＴＥメッセージは、ＤＨＣＰ(Dynamic Host Configuration Protocol)サーバ又はＤＮＳ(Domain Name Server)での経路クエリー(query)を用いてＩＭＳネットワーク内の該当ＩＭＳ(IP Multimedia Subsystem)サーバ、すなわちＰ-ＣＳＰＦ(Primary Constrained Shortest Path First)及びＳ-ＣＳＰＦ(Secondary CSPF)を通じて参加ＰｏＣサーバ(ＰＦ)に伝送される。一般の通話が要求されると、ＰｏＣクライアントが接続された参加ＰｏＣサーバは、開設されるセッションのトークバーストを管理する制御ＰｏＣサーバと分離して実現されることができるため、ＰＦに伝送されたＳＩＰ ＩＮＶＩＴＥメッセージは、該当ＳＩＰ/ＩＰコアネットワークを通じて制御ＰｏＣサーバＣＦに伝送される。
【００４８】
ＣＦを含むＰｏＣセッション制御ネットワークは、ターゲットネットワークにＳＩＰ ＩＮＶＩＴＥメッセージを伝送し、このターゲットネットワークから応答メッセージを受信する。ターゲットネットワークから応答されるＳＩＰメッセージは、‘１ｘｘ’で表される臨時応答メッセージ、‘２ｘｘ’で表される成功応答メッセージ、又は‘４ｘｘ’〜‘６ｘｘ’で表される誤り応答メッセージであり得る。自動応答モードで、ＳＩＰ１８３‘ｓｅｓｓｉｏｎ ｐｒｏｇｒｅｓｓ’信号は、応答メッセージとして受信されることができ、この応答メッセージを用いて通話要求者のＩＭＳネットワークでＰｏＣサーバとＰｏＣクライアントとの間の接続が遂行されることができる。ターゲットＰｏＣクライアントの通話許可信号は、ＳＩＰ１８３‘ｓｅｓｓｉｏｎ ｐｒｏｇｒｅｓｓ’信号又はＳＩＰ２００‘ＯＫ’応答として伝送され、ＣＦ及びＰＦを含むＰｏＣサーバを通じて送信側ＰｏＣクライアントに伝送される。２００‘ＯＫ’応答又は１８３‘ｓｅｓｓｉｏｎ ｐｒｏｇｒｅｓｓ’信号がターゲットＰｏＣサーバから受信されると、ＣＦは、ＰｏＣ呼が接続されたと決定し、トークバースト発言権を付与するための‘ｆｌｏｏｒ ｇｒａｎｔｅｄ’信号を送信側ＰｏＣクライアントに伝送する。２００‘ＯＫ’応答又は１８３‘ｓｅｓｓｉｏｎ ｐｒｏｇｒｅｓｓ’信号によってトークバースト発言権の付与は、‘ｃｏｎｆｉｒｍｅｄ’又は‘ｕｎｃｏｎｆｉｒｍｅｄ’によって識別されることができる。‘ｕｎｃｏｎｆｉｒｍｅｄ’応答が受信されると、ＣＦは、バッファリング機能を必要とする。
【００４９】
ＳＩＰ ＩＮＶＩＴＥ要求メッセージに対する応答信号を受信した後に、送信側ＰｏＣクライアントは、トークバーストを伝送し、ＲＴＣＰ(Real-time Transport Control Protocol)を用いて伝送信号(例えば、通話接続音)を伝送するための‘ｆｌｏｏｒ ｇｒａｎｔｅｄ’信号を受信する。‘ｆｌｏｏｒ ｇｒａｎｔｅｄ’信号は、とイークバースト仲裁権を有するＣＦによって与えられ、ＰｏＣクライアントを管理するＰＦを通じてＰｏＣクライアントに伝送される。‘ｆｌｏｏｒ ｇｒａｎｔｅｄ’信号は、ＳＩＰの代わりにベアラの経路を使用するため、‘ｆｌｏｏｒ ｇｒａｎｔｅｄ’信号は、対案として用いるＩＭＳネットワークのようなＳＩＰ/ＩＰコアネットワークを利用せずに伝送されることができる。通話接続音を受信される送信側ＰｏＣクライアントは、メディアストリーム(例えば、音声ストリーム)をＲＴＰ(Real-time Transport Protocol)を用いて伝送する。
【００５０】
以下、当該技術分野で通常の知識を持った者が本発明を容易に実施できるように、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。
本発明は、ＰｏＣマルチメディア環境で最初の応答クライアントによって応答するメディアタイプに限定されるＲＴＰメディアを伝送する送信側ＰｏＣサーバ間のＰｏＣセッションを開設し、上記セッションでセッションアップデートを通じて少なくとも一つのターゲットＰｏＣクライアントによって支援されるメディアタイプのみを追加又は除去するセッション管理システムとその方法及び端末装置に関する。
【００５１】
ＰｏＣセッションの開設のために、ＰｏＣクライアントによって支援される多様なメディアタイプが相互に共通でない場合、あるいは最初の応答メッセージに含まれた伝送可能なメディアタイプが送信側によって提供されるメディアタイプと異なる場合に、ＰｏＣセッションで少なくとも一つの受信可能なＰｏＣクライアントによって支援されるメディアタイプのみを支援するＰｏＣセッションを開設するためのＰｏＣシステムを構成するＰｏＣクライアントとＰｏＣサーバの構成は、図４を参照して説明する。図４は、本発明の実施形態により、相互に接続される、ＰｏＣクライアント１０２を含むＰｏＣ端末１００とＰｏＣサーバ１５０を示すブロック構成図である。
【００５２】
図４を参照すると、ＰｏＣ端末１００は、ユーザーとのインターフェースのための装置であって、各キー入力にその固有のキー入力データを出力するユーザーインターフェース４０４を含む。また、ＰｏＣ端末１００は、ＰｏＣサーバ１５０とのパケットデータ通信を遂行するために、プロトコルスタックで構成されるデータ伝送部４１０を含む。ＰｏＣ端末１００は、データ伝送部４１０によって受信されたメディアデータをディスプレイし、ユーザーインターフェース４０４から出力されるデータをディスプレイするディスプレイ部４００を含む。さらに、ＰｏＣ端末１００は、制御部４０２を含む。制御部４０２は、ＰｏＣクライアント１０２のデータ送受信、ディスプレイ部４００のディスプレイ、チャット(chat)ＰｏＣグループに参加するための招待予約メッセージの生成と伝送、及び応答メッセージの受信を制御する。特に、ＰｏＣクライアント１０２がセッション開設ＰｏＣクライアントである場合に、制御部４０２は、セッション開設のためにユーザーによって要求されるメディアタイプ及びメディア属性情報を含むセッション参加要求(ＩＮＶＩＴＥ)メッセージをＰｏＣサーバ１５０に伝送する。また、現在セッションによって支援される特定のメディアタイプ情報を含むｒｅ-ＩＮＶＩＴＥメッセージがＰｏＣサーバ１５０から受信された場合に、制御部４０２は、このｒｅ-ＩＮＶＩＴＥメッセージに対応してＰｏＣサーバ１５０に応答メッセージを伝送する。一方、ＰｏＣクライアント１０２がセッション参加ＰｏＣクライアントである場合に、制御部４０２は、ＩＮＶＩＴＥメッセージに応答してＰｏＣサーバ１５０に支援可能なメディアタイプ情報を含む応答メッセージを伝送する。
【００５３】
ＰｏＣ端末１００は、ＰｏＣ端末１００の全般的な機能に関連した情報を格納し、ＰｏＣサービスに関連したデータ及び端末を識別するためのユーザーアカウント、及びユーザーによって設定され、あるいはＰｏＣサーバ１５０から提供される情報を格納するメモリ４０５を含む。特に、メモリ４０５は、受信された応答メッセージに含まれた支援可能なメディアタイプに関する情報を格納する。
【００５４】
ＰｏＣサーバ１５０は、プロトコルスタックで構成されるデータ伝送部４２０、多重マルチメディア通話サービス処理部４３０、メモリ４２１、及び参加ＰｏＣ機能コンポーザー(composer)４４０を含む。ＰｏＣサーバ１５０の動作については、下記の図５を参照して詳しく説明する。
【００５５】
図５は、本発明の一実施形態によるＰｏＣクライアントとＣＦとの間で多様なメディアタイプを支援するマルチメディアＰｏＣセッションを開設するためにＣＦを遂行するＰｏＣサーバにマルチメディアＰｏＣセッションを開設するプロセスを示すフローチャートである。
【００５６】
図５を参照すると、ステップ５００で、ＣＦがＩＮＶＩＴＥメッセージを受信すると、ＣＦは、ステップ５０２で、ＩＮＶＩＴＥメッセージに含まれたメディア属性情報を付加的メモリ４２１にキャッシュ(cach)し、このＩＮＶＩＴＥメッセージをターゲットＰｏＣクライアントに伝送する。
【００５７】
ＣＦは、ステップ５０４で、受信された応答メッセージがＩＮＶＩＴＥメッセージに対する最初の応答メッセージであるか否かを判定する。ステップ５０４で、受信された応答メッセージが最初の応答メッセージであると判定された場合に、ＣＦは、ステップ５０６で、最初の応答メッセージに含まれたセッション参加ＰｏＣクライアントによって支援されるメディアタイプが、ＩＮＶＩＴＥメッセージに含まれたメディアタイプと同一であるか否かを判定する。ステップ５０６で、メディアタイプがすべて同一であると判定された場合に、ＣＦは、ステップ５１４で、すべてのメディアにそれぞれＵＤＰ(User Datagram Protocol)ポート番号を割り当て、メディアを活性化する２００‘ＯＫ’応答メッセージを生成する。その後、ＣＦは、ステップ５１０で、送信側ＰｏＣクライアント、すなわちセッション開始要求ＰｏＣクライアントにこの２００‘ＯＫ’応答メッセージを伝送する。しかしながら、ステップ５０６で、メディアタイプが同一でないと判定された場合には、ＣＦは、ステップ５０８で、最初の応答メッセージに含まれたセッション参加ＰｏＣクライアントによって支援される各メディアタイプのみにＵＤＰポート番号を割り当て、メディアを活性化する２００‘ＯＫ’応答メッセージを生成する。ＵＤＰは、ＲＦＣ(Request For Comments)７６８に定義され、ＣＭＴＰ(Continuous Media Transport Protocol）として使用される。以後、ＣＦは、ステップ５１０で、送信側ＰｏＣクライアント、すなわちセッション開始要求ＰｏＣクライアントに２００‘ＯＫ’応答メッセージを伝送する。
【００５８】
ステップ５０４で、受信された応答メッセージが最初の応答メッセージでないと判定された場合には、ＣＦは、ステップ５１６で、ＵＤＰポートが割り当てられたメディアが、受信された応答メッセージに含まれているか否かを判定する。ステップ５１６で、割り当てられたポート番号を有し、活性化されるメディアタイプが受信された応答メッセージに含まれたと判定されると、ＣＦは、ステップ５１８で、該当ターゲットＰｏＣクライアントのＳＩＰ ＵＲＩ情報のみをコンファレンス情報としてアップデートする。以後、ＣＦは、ステップ５１２で、セッションを維持し、受信されたＲＴＰメディアを伝送する。ステップ５１６で、割り当てられたポート番号を有し、活性化されるメディアタイプが、受信された応答メッセージに含まれていない場合、すなわちＵＤＰポート番号が割り当てられていない各メディアに対して、ＣＦは、ステップ５２０で、受信された応答メッセージと格納されたメディア属性情報に含まれたメディアタイプを比較して得られた共通メディアタイプ情報を含むｒｅ-ＩＮＶＩＴＥメッセージを生成する。ＣＦは、ステップ５２２で、上記ｒｅ-ＩＮＶＩＴＥメッセージを送信側ＰｏＣクライアントに伝送する。ＣＦは、ステップ５２４で、送信側ＰｏＣクライアントから応答メッセージを受信し、セッションをアップデートする。その後、ＣＦは、ステップ５１２で、セッションを維持し、受信されたＲＴＰメディアを伝送する。
【００５９】
図６は、本発明によるＰｏＣマルチメディアサービスを提供するために、ＰｏＣクライアントとＰｏＣサーバとの間で多様なメディアタイプを支援するマルチメディアＰｏＣセッションを開設及び維持するＰｏＣクライアントとＰｏＣサーバとの間の信号フローを示す図である。特に、図６は、アドホック(ad-hoc)グループセッションを開設する実施形態を示しているが、本実施形態は、本明細書で提案する同一の原理によって所定の(pre-arranged)グループにも適用できる。
【００６０】
図６を参照すると、ステップ６００で、ＰｏＣセッションの開設を所望するＰｏＣクライアントＡ５０がＩＮＶＩＴＥメッセージをＣＦ５１に伝送すると、ＣＦ５１は、ステップ６０１〜６０５で、ＰｏＣセッションに招待されたターゲットＰｏＣクライアントにＩＮＶＩＴＥメッセージを伝送する。このセッション開設要求ＰｏＣクライアントＡ５０から伝送されたＩＮＶＩＴＥメッセージは、ＰｏＣクライアントＡ５０によって要求されるメディアタイプと、そのボディー部分でターゲットＰｏＣクライアントのアドレス情報とを含む。図６に示す本実施形態では、ＩＮＶＩＴＥメッセージに含まれたＰｏＣクライアントＡ５０によって要求されるメディアタイプが、オーディオ、ビデオ、及びテキストであると仮定する。ＣＦ５１は、ＰｏＣクライアントＡ５０から伝送されたＩＮＶＩＴＥメッセージに含まれたメディアタイプの詳細なメディア属性情報であるＲＴＰメディアマッピング情報、コーデックモード、及び符号化率情報のような情報を付加的メモリ４２１にキャッシュする。
【００６１】
ＣＦ５１からＩＮＶＩＴＥメッセージを受信した各ターゲットＰｏＣクライアントは、支援可能なメディアタイプ情報を含む応答メッセージをＣＦ５１に伝送する。図６に示した実施形態で、ＰｏＣクライアントＢ５３によって支援されるメディアタイプがオーディオタイプであり、ＰｏＣクライアントＣ５５によって支援されるメディアタイプがオーディオ及びテキストタイプであり、ＰｏＣクライアントＤによって支援されるメディアタイプがビデオとテキストタイプであり、ＰｏＣクライアントＥによって支援されるメディアタイプがオーディオタイプであると仮定する。
【００６２】
最初のＳＩＰ２００‘ＯＫ’応答メッセージが、ＩＮＶＩＴＥメッセージに応答してＰｏＣサーバＢ５２を通じてＰｏＣクライアントＢ５３から受信されると、ＣＦ５１は、ステップ６０６〜６０８で、最初のＳＩＰ２００‘ＯＫ’応答メッセージに含まれたＰｏＣクライアントＢ５３によって支援されるメディアタイプを分析する。ＣＦ５１は、最初のＳＩＰ２００‘ＯＫ’応答メッセージに含まれたＰｏＣクライアントＢ５３によって支援されるメディアタイプと、メモリ４２１に格納されたメディアタイプとを比較する。図６に示した本実施形態では、ＰｏＣクライアントＡ５０によって要求されるメディアタイプがオーディオ、ビデオ、及びテキストタイプであり、ＰｏＣクライアントＢ５３によって支援されるメディアタイプはオーディオタイプであるため、その比較結果は同一でないケースに該当する。この場合、ＣＦ５１は、最初のＳＩＰ２００‘ＯＫ’応答メッセージに含まれたＰｏＣクライアントＢ５３によって支援されるオーディオタイプのみにＵＤＰポート番号を割り当てる２００‘ＯＫ’応答メッセージを生成し、メディア伝送を活性化する(ここて、ＵＤＰポート番号は、本発明の一実施形態によって初期に提案されたすべてのメディアタイプに割り当てられることができる)。ＣＦ５１は、ステップ６０９で、ＰｏＣクライアントＡ５０に２００‘ＯＫ’応答メッセージを伝送する。このＣＦ５１は、最初に提供されたメディアタイプ、すなわちオーディオ、ビデオ、テキストタイプ、メディア属性情報及び最初応答したメディアタイプ、すなわちオーディオタイプを固有のコンファレンス情報として格納し、それによってセッションアップデートは、応答メッセージ内のメディアタイプ特性によって以後に遂行される。
【００６３】
ＰｏＣクライアントＢ５３によって支援されるメディアタイプが、メモリ４２１に格納されたメディアタイプと同一である場合に、ＣＦ５１は、すべてのメディアにＵＤＰポート番号を割り当て、メディアを活性化する２００‘ＯＫ’応答メッセージを生成する。その後、ＣＦ５１は、ＰｏＣクライアントＡ５０に２００‘ＯＫ’応答メッセージを伝送する。
【００６４】
一方、第２の応答メッセージが、ステップ６１０〜６１１でＰｏＣクライアントＣ５５から受信された場合、ＣＦ５１は、ＰｏＣクライアントＣ５５から伝送される２００‘ＯＫ’応答メッセージに含まれたメッセージボディーを分析してＰｏＣクライアント５５によって支援されるメディアタイプを判定する。上記したように、ＰｏＣクライアントＣ５５によって支援されるメディアタイプがオーディオ及びテキストタイプであるため、第２の応答メッセージは、オーディオ及びテキストタイプを支援する応答メッセージである。このとき、ＣＦ５１は、メモリ４２１に格納されたコンファレンス情報を読み取ることによって、ＰｏＣクライアントＡ５０とＣＦ５１との間でオーディオに加えてテキストを伝送するためにセッションアップデートを遂行する。オーディオとテキストを伝送するセッションのアップデートのために、ＣＦ５１は、ステップ６１２で、オーディオとテキストタイプ情報を含むｒｅ-ＩＮＶＩＴＥを生成し、このｒｅ-ＩＮＶＩＴＥをＰｏＣクライアントＡ５０に伝送する。ＣＦ５１は、ステップ６１３で、ＰｏＣクライアントＡ５０から応答メッセージを受信すると、セッションをアップデートする。
その後、ＣＦ５１は、セッションを維持し、受信されたＲＴＰメディアを伝送する。
【００６５】
また、ＣＦ５１は、ステップ６１３で、テキストを支援するために、セッションアップデート応答によって格納されたコンファレンス情報をアップデートする。このセッションアップデートは、格納されたメディア属性情報からテキストに対する属性情報を用いて生成されたｒｅ-ＩＮＶＩＴＥメッセージを使用する。以下、このｒｅ-ＩＮＶＩＴＥメッセージのボディー部分について、図６Ｃを参照して詳細に説明する。
【００６６】
２００‘ＯＫ’応答メッセージは、ステップ６１４，６１５で、他のＰｏＣクライアント、すなわちＰｏＣクライアントＥとＰｏＣクライアントＤから受信される場合に、２００‘ＯＫ’応答メッセージのそれぞれのボディー部分が分析され、各２００‘ＯＫ’応答メッセージに含まれたメディアタイプ情報が、ＰｏＣ該当クライアントＡ５０とＣＦ５１との間のセッションで支援されるメディアタイプに該当する場合には、セッションアップデートが遂行されずに、対応するＰｏＣクライアントのアイデンティティ情報のみがコンファレンス情報にアップデートされる。すなわち、ＰｏＣクライアントＥから受信された２００‘ＯＫ’応答メッセージによって、ＰｏＣクライアントＥによって支援されるメディアタイプであるオーディオタイプは、ＰｏＣクライアントＡ５０とＣＦ５１との間のセッションで支援されるメディアタイプであるため、別のメディアタイプアップデートは遂行されない。しかしながら、ＰｏＣクライアントＤから受信された２００‘ＯＫ’応答メッセージによって、ＰｏＣクライアントＤによって支援されるメディアタイプの中でビデオタイプが、新たに支援されるメディアタイプであるため、オーディオ、テキスト、ビデオタイプを伝送するセッションアップデートは、ステップ６１２，６１３のようにステップ６１６、６１７で遂行される。上述したように、ｒｅ-ＩＮＶＩＴＥメッセージは、ステップ６１６で、ビデオタイプの格納された属性情報を用いて生成され、ＰｏＣクライアントＡ５０に伝送され、２００‘ＯＫ’応答メッセージは、ｒｅ-ＩＮＶＩＴＥメッセージに応答して受信され、それによってオーディオ、ビデオ、及びテキストを支援するためのセッションをアップデートする。
【００６７】
その後、ＣＦ５１が、ステップ６１８で、ＰｏＣクライアントＦから２００‘ＯＫ’応答メッセージを受信しても、ＰｏＣクライアントＦによって支援されるメディアタイプであるオーディオ及びビデオタイプは、ＰｏＣクライアントＡ５０とＣＦ５１との間でセッションによって支援されるメディアタイプに該当するため、別途のメディアタイプアップデートは遂行されない。
【００６８】
図６でＡＣＫ(ACKnowledgement)信号及び発言権を管理するためのＭＢＣＰ(Media Burst Control Protocol）の詳細な手順は、便宜上省略する。しかしながら、上記したように追加的なメディアアップデートが遂行される場合に、ＳＩＰメッセージを用いてセッションをアップデートし、ＰｏＣクライアントＡ５０は、ＣＦ５１によって支援されるメディアタイプに従って該当メディアに対するメディアバースト要求メッセージを伝送し、ＣＦ５１によって支援されるメディアタイプに従ってメディアバースト付与メッセージを受信する。
【００６９】
初期招待されたグループメンバーと共に他のＰｏＣクライアントがセッションに参加する場合に、クライアントによって要求されるメディアタイプ及び属性情報が、セッションに存在するメディアタイプと異なると、ＰｏＣクライアントのセッション参加は、サービス提供者のポリシーによって拒絶又は許容することができる。ＰｏＣクライアントのセッション参加を許諾する場合に、メディアタイプをアップデートするセッションｒｅ-ＩＮＶＩＴＥメッセージ及びセッションで使用されない属性情報は、本発明の原理を使用するセッションに参加するすべてのＰｏＣクライアントから要求されることができる。このとき、セッションアップデートは、図６に示したように遂行される。
【００７０】
セッションｒｅ-ＩＮＶＩＴＥメッセージは、同一の目的でセッション特性をアップデートするための他のＳＩＰメッセージを用いて伝送されることができる。
【００７１】
図６に示した実施形態をより詳細に説明するために、図７及び図８は、対応するＳＩＰメッセージの中からメディアタイプ及び属性情報のみを示す。図７Ａ、図７Ｂ、図７Ｃは、図６に示したステップ６００，６０９，６１２で、伝送されたＳＩＰメッセージに含まれたＳＤＰボディー部分のメディアタイプ情報を各々示す。ステップ６０９で、応答メッセージは、図７Ａで提案されたオーディオ、ビデオ、及びテキストの中からオーディオのみを伝送できる状態にあり、他のメディアタイプは、図７Ｂに示すように、そのＵＤＰポート番号が０に設定されることによって伝送されることができない。テキストは付加的に支援されるため、ステップ６１２で、オーディオ及びテキストは、図７Ｃに示すように、テキストに対してＵＤＰポート番号を割り当てることによって伝送されることができる。ステップ６１６で、メディアは、すべてのメディアタイプに対してＵＤＰポート番号を割り当てることによって伝送されることができる。
【００７２】
図８Ａ、図８Ｂ、図８Ｃは、図７Ａ、図７Ｂ、図７Ｃの他の実施形態であって、図６に示したステップ６００，６０９，６１２で、伝送されたそれぞれのＳＩＰメッセージに含まれるＳＤＰボディー部分のメディアタイプ情報を示す。ステップ６０９で、応答メッセージは、図８Ａに提案されたオーディオ、ビデオ、及びテキストの中からオーディオのみを伝送できる状態にあり、他のメディアタイプは、図８Ｂに示すように‘ｉｎａｃｔｉｖｅ'、すなわち他のメディアタイプに、対応するメディアタイプが伝送できないことを示すメディア特性値にによって伝送されることができない。テキストがステップ６１２で追加的に支援されるため、図８Ｃのように、‘ｉｎａｃｔｉｖｅ’のメディア特性値は、ビデオのみに適用されることができる。ステップ６１６で、すべてのメディアタイプは、‘ｉｎａｃｔｉｖｅ’のメディア特性値を除去することによって伝送されることができる。
【００７３】
また、セッションに使用されないメディアタイプ及び属性情報をアップデートする方法において、ＲＴＣＰ ＡＰＰメッセージ、すなわちＭＢＣＰメッセージを伝送することができる。最初の応答メッセージに対応して、図６でＰｏＣクライアントＡ５０とＣＦ５１との間では初期に提案されたすべてのメディアタイプに対してＵＤＰポート番号を割り当て、メディアパラメータ(コーデック、発言権管理プロトコル、及びＩＰアドレス）の交渉を完了したセッションが開設される。すなわち、ステップ６０９で、２００‘ＯＫ’メッセージが受信された後に、ビデオ及びテキストに対するＵＤＰポート番号とコーデック情報が交渉され、該当メディアタイプが伝送されたか否かを示すメディア特性値が‘ｉｎａｃｔｉｖｅ’として設定された部分活性化セッションは、ＰｏＣクライアントＡ５０とＣＦ５１との間で開設される。メディアタイプの発言権管理プロトコルも交渉されるため、該当メディアタイプに対するＭＢＣＰメッセージを伝送するＲＴＣＰのポート番号及びＭＩＭＥパラメータも設定される。したがって、図６の説明と類似した手順を通じて、ＣＦ５１が他のＰｏＣクライアントから非活性化メディアタイプを支援する応答メッセージを受信すると、ＣＦ５１は、ＲＴＣＰチャンネルを介してＭＢＣＰメッセージを伝送することによってＰｏＣクライアントＡ５０とＣＦ５１との間の部分活性化セッションをアップデートする。
【００７４】
このような方法で、最初の応答メッセージの受信後に、新たなメディアタイプを支援する応答メッセージを受信する場合に、ＣＦ５１は、伝送特性値をアップデートするＭＢＣＰメッセージをＰｏＣクライアントＡ５０に伝送し、以後、ＭＢＣＰ ＡＣＫが受信されると、ＣＦ５１は、該当メディアタイプが新たなメディアタイプに対して‘ｓｅｎｄｒｅｃｖ'に伝送されるか否かを示すメディア特性値を変更する。また、ＰｏＣクライアントＡ５０は、ＣＦ５１から受信される特定メディアタイプに対するＭＢＣＰメッセージに基づいて新たなメディアタイプに対するメディア特性値を‘ｉｎａｃｔｉｖｅ'から‘ｓｅｎｄｒｅｃｖ'に変更することによって、新たなメディアタイプを伝送するためにセッションをアップデートする。
【００７５】
例えば、この方法により、図６に示したステップ６１２及び６１６でｒｅ-ＩＮＶＩＴＥメッセージは、ＭＢＣＰメッセージ(例えば、ＭＢＣＰ接続メッセージ)に代替可能であり、ステップ６１３及び６１７でＭＢＣＰ ＡＣＫメッセージを受信することによって非活性化メディアタイプであるテキストとビデオが各々活性化される。通常、本発明で使用される‘メディアタイプ’は、オーディオ、ビデオ、イメージ、テキストのようなメディア特性を区分する情報として使用される。また、この‘メディアタイプ’は、発明の拡張された技術として同一のメディアタイプを区別する最小の基本単位で扱われる。例えば、２個の相互に異なるビデオ(第１のビデオ及び第２のビデオ)が存在すると、すなわち同一のメディアタイプである第１のビデオと第２のビデオが各々存在すると、その第１及び第２のビデオは、各々接続されたメディアパラメータの特性によって相互に異なるメディアタイプとして考えられる。したがって、‘メディアタイプ’は、同一のメディアタイプを示すことができ、メディアストリームを区分する最小の基本単位として拡張して使用することもできる。
【００７６】
したがって、拡張された技術の実施形態として、送信側ＰｏＣクライアントが第１のオーディオ、第２のオーディオ、第１のビデオ、第１のビデオのメディアタイプを含むセッション開設を要求した場合に、ホームＰｏＣサーバは、ターゲットネットワークから受信されたＳＩＰ応答メッセージで採択されたメディアタイプに関係なく、初期提案された全体メディアタイプ(第１のオーディオ、第２のオーディオ、第１のビデオ、及び第１のビデオ）を伝送するＰｏＣセッションを開設することができる。
【００７７】
以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲を外れない限り、様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。したがって、本発明の範囲は、前述の実施形態に限定されるものではなく、特許請求の範囲の記載及びこれと均等なものに基づいて定められるべきである。
【符号の説明】
【００７８】
１００ ＰｏＣ端末
１０２ ＰｏＣクライアント
１２０ ＳＩＰ／ＩＰコアネットワーク
１５０ ＰｏＣサーバ
４００ ディスプレイ部
４０２ 制御部
４０４ ユーザーインターフェース
４０５ メモリ
４１０ データ伝送部
４２０ データ伝送部
４２１ メモリ
４３０ 多重マルチメディア通話サービス処理部
４４０ 参加ＰｏＣ機能コンポーザー
【特許請求の範囲】
【請求項１】
マルチメディア通話サービスを遂行するためのマルチメディアセッション開設及び管理のためのサーバであって、
セッション開始要求クライアント及び少なくとも一つのセッション参加クライアントとのパケットデータ送受信を遂行するデータ送受信部と、
セッション参加要求メッセージに含まれたメディア属性情報と少なくとも一つのメディアタイプを格納するメモリと、
前記セッション参加要求メッセージの受信、メディア属性情報と少なくとも一つのメディアタイプの格納、セッション参加クライアントにより支援される少なくとも一つのメディアタイプを含む最初応答メッセージの受信、及び前記最初応答メッセージに含まれた少なくとも一つのメディアタイプとメモリに格納された前記少なくとも一つのメディアタイプとを比較して、前記メディアタイプを支援するマルチメディア通信セッションを開設するセッション開設要求クライアントに応答メッセージの伝送を制御するセッション処理部と、含むことを特徴とするサーバ。
【請求項１】
マルチメディア通話サービスを遂行するためのマルチメディアセッション開設及び管理のためのサーバであって、
セッション開始要求クライアント及び少なくとも一つのセッション参加クライアントとのパケットデータ送受信を遂行するデータ送受信部と、
セッション参加要求メッセージに含まれたメディア属性情報と少なくとも一つのメディアタイプを格納するメモリと、
前記セッション参加要求メッセージの受信、メディア属性情報と少なくとも一つのメディアタイプの格納、セッション参加クライアントにより支援される少なくとも一つのメディアタイプを含む最初応答メッセージの受信、及び前記最初応答メッセージに含まれた少なくとも一つのメディアタイプとメモリに格納された前記少なくとも一つのメディアタイプとを比較して、前記メディアタイプを支援するマルチメディア通信セッションを開設するセッション開設要求クライアントに応答メッセージの伝送を制御するセッション処理部と、含むことを特徴とするサーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図８Ａ】
【図８Ｂ】
【図８Ｃ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図８Ａ】
【図８Ｂ】
【図８Ｃ】
【公開番号】特開２０１２−８５３１７（Ｐ２０１２−８５３１７Ａ）
【公開日】平成２４年４月２６日（２０１２．４．２６）
【国際特許分類】
【出願番号】特願２０１１−２５０７１９（Ｐ２０１１−２５０７１９）
【出願日】平成２３年１１月１６日（２０１１．１１．１６）
【分割の表示】特願２００９−５３１３２０（Ｐ２００９−５３１３２０）の分割
【原出願日】平成１９年１０月２日（２００７．１０．２）
【出願人】（５０３４４７０３６）サムスン エレクトロニクス カンパニー リミテッド (2,221)
【Ｆターム（参考）】
【公開日】平成２４年４月２６日（２０１２．４．２６）
【国際特許分類】
【出願日】平成２３年１１月１６日（２０１１．１１．１６）
【分割の表示】特願２００９−５３１３２０（Ｐ２００９−５３１３２０）の分割
【原出願日】平成１９年１０月２日（２００７．１０．２）
【出願人】（５０３４４７０３６）サムスン エレクトロニクス カンパニー リミテッド (2,221)
【Ｆターム（参考）】
[ Back to top ]