"マルチメディア通話サービスを遂行するためのマルチメディアセッション開設及び管理のためのサーバであって、セッション開始要求クライアント及び少なくとも一つのセッション参加クライアントとのパケットデータ送受信を遂行するデータ送受信部と、セッション参加要求メッセージに含まれたメディア属性情報と少なくとも一つのメディアタイプを格納するメモリと、前記セッション参加要求メッセージの受信、メディア属性情報と少なくとも一つのメディアタイプの格納、セッション参加クライアントにより支援される少なくとも一つのメディアタイプを含む最初応答メッセージの受信、及び前記最初応答メッセージに含まれた少なくとも一つのメディアタイプとメモリに格納された前記少なくとも一つのメディアタイプとを比較して、前記メディアタイプを支援するマルチメディア通信セッションを開設するセッション開設要求クライアントに応答メッセージの伝送を制御するセッション処理部と、含むことを特徴とするサーバ。したがって、本発明は上記従来の問題点に鑑みてなされたものであって、その一態様による目的は、PoCマルチメディア通話サービスを遂行するPoCクライアントが、複数のメディアタイプを支援し、PoCクライアントによって支援されるメディアタイプが共通でない場合、あるいは最初の応答メッセージに含まれた伝送可能メディアタイプが送信側によって提供されたメディアタイプと異なる場合に、該当PoCセッションで少なくとも一つの受信PoCクライアントによって支援されるメディアタイプのみを支援するPoCセッションを開設するためのシステムとその方法及び端末装置を提供することにある。本発明の他の態様による目的は、新たなメディアタイプが新たな参加者によって支援される場合、または既存のメディアタイプの受信者が変更される場合に、変更される情報を自動にアップデートしてセッションを管理するシステムとその方法及びUEを提供することにある。また、本発明の他の態様による目的は、セッション開始クライアントから受信されるセッション参加要求メッセージに含まれたメディアタイプの属性attributeを格納し、最初の応答に対応してセッションが開設された後に、INVITEメッセージで提供されるメディアタイプ及びメディア属性を支援する新たな参加者が該当セッションに参加する場合に、格納されたメディア属性をアップデートされるセッションで提供するようにセッションをアップデートするためのシステムとその方法及びUEを提供することにある。上記のような目的を達成するために、本発明の一態様によれば、マルチメディア通話サービスを遂行するためのマルチメディアセッション開設及び管理のためのサーバであって、セッション開始要求クライアント及び少なくとも一つのセッション参加クライアントとのパケットデータ送受信を遂行するデータ送受信部と、セッション参加要求メッセージに含まれたメディア属性情報と少なくとも一つのメディアタイプを格納するメモリと、前記セッション参加要求メッセージの受信、メディア属性情報と少なくとも一つのメディアタイプの格納、セッション参加クライアントにより支援される少なくとも一つのメディアタイプを含む最初応答メッセージの受信、及び前記最初応答メッセージに含まれた少なくとも一つのメディアタイプとメモリに格納された前記少なくとも一つのメディアタイプとを比較して、前記メディアタイプを支援するマルチメディア通信セッションを開設するセッション開設要求クライアントに応答メッセージの伝送を制御するセッション処理部と、含むことを特徴とする。また、本発明の一態様によれば、マルチメディア通話サービスを遂行するためのマルチメディアPoCセッション開設及び管理のためのPoCシステムであって、メディアタイプ及びメディア属性情報を含むセッション参加要求メッセージをPoCサーバに伝送するセッション開始要求PoCクライアントと、INVITEメッセージに含まれたメディアタイプ及びメディア属性情報を格納し、最初の応答メッセージが受信されると、最初の応答メッセージでメディア伝送のために設定するメディアタイプのみを支援するPoCセッションを開設するために、最初の応答メッセージに含まれたメディアタイプが伝送可能な状態であることを示す応答メッセージをセッション開始要求PoCクライアントに伝送するPoCサーバとを含むことを特徴とする。本発明の他の態様によれば、セッション開始要求PoCクライアント、少なくとも一つのセッション参加PoCクライアント、及びマルチメディアPoCセッションを開設及び管理するためのPoCサーバを含むPoCシステムにおいて、マルチメディア通話サービスを遂行するためのマルチメディアPoCセッションを開設及び管理するための方法であって、セッション開始要求PoCクライアントがメディアタイプ及びメディア属性情報を含むINVITEメッセージをPoCサーバに伝送する第1のプロセスと、PoCサーバがINVITEメッセージに含まれたメディアタイプ及びメディア属性を格納する第2のプロセスと、最初の応答メッセージが受信されると、PoCサーバは、最初の応答メッセージに含まれたメディアタイプが伝送可能な状態であることを示す応答メッセージをセッション開始要求PoCクライアントに伝送してPoCセッションを開設する第3のプロセスとを有することを特徴とする。また、本発明の他の態様によれば、PoCシステムにおけるマルチメディア通話サービスを遂行するためのマルチメディアPoCセッションの開設及び管理のための端末装置であって、PoCサーバとのパケットデータの送受信を遂行するデータ伝送部と、セッション開設のために要求されるメディアタイプ及びメディア属性情報を含むINVITEメッセージを伝送し、現在セッションで支援される特定のメディアタイプ情報を含むreINVITEメッセージが受信された場合に、reINVITEメッセージに対する応答メッセージを伝送するためにデータ伝送部を制御する制御部とを含むことを特徴とする。好ましく、PoCシステムは、INVITEメッセージを送信するセッション開始要求PoCクライアントと、上記PoCクライアントからINVITEメッセージを受信し、INVITEメッセージに対する応答メッセージをセッション開始要求PoCクライアントに伝送するPoCサーバと、メディアタイプ情報を含む応答メッセージを格納するセッションメディアタイプ及び属性臨時格納部とを含む。好ましく、メディアタイプ情報は、SIPINVITEメッセージとSIP200‘OK’メッセージのボディー部分或いはRTCPメッセージフォーマットにメディアタイプ情報のための新たなカラムを追加する形態で通知できる。本発明は、OMAPoCマルチメディア通話サービスを遂行するPoCクライアントが、PoCセッションの開設時にPoCクライアントによって支援される多様なメディアタイプが相互に共通でない場合、或いは最初の応答メッセージに含まれた伝送可能メディアタイプが送信側で提供されたメディアタイプと異なる場合に、該当PoCセッションで少なくとも一つの受信PoCクライアントによって支援されるメディアタイプのみを支援するPoCセッションを開設し、以後該当セッションで任意の参加者がセッションを終了し、あるいは新たな参加者がセッションに参加する場合に、セッションアップデートを通じて少なくとも一つの受信PoCクライアントによって支援されるメディアタイプだけを追加または除去するためのPoCシステムにおけるセッション管理システムとその方法及び端末装置を提案する。本発明は、マルチメディア通話サービスを遂行するPoCクライアントが複数のメディアタイプを支援し、PoCクライアントによって支援されるメディアタイプが共通でない場合に、PoCセッションで少なくとも一つのターゲットPoCクライアントによって支援されるメディアタイプのみを支援するPoCセッションが開設されることができる。また、本発明は、新たなメディアタイプが新たな参加PoCクライアントによって提供され、既存のセッションで支援されるメディアタイプの受信者が変更されると、変更をアップデートしてセッションを管理する方法を提供することによって、セッションが、新たなメディアタイプの追加又は既存のメディアタイプの除去に対応して活発に管理されることができる。さらに、本発明は、メディアタイプ情報がアップデートされる必要がある場合に、追加手順なしに該当セッションにアップデート内容を反映するために、最初のPoCセッション開始によって提供されたメディアタイプ及びメディア属性情報を格納し、それによって無線伝送の効率性を向上させ、PoCサービスのユーザー経験を向上させる効果がある。以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。下記に、PTTシステム、特にセルラー移動通信ネットワークを使用するPTTサービスを提供するPoCシステムに本発明を適用する場合について説明する。一般に、PoCシステムは、グループPoC通話のセッション参加情報を伝送するためにSIP及びSIP拡張プロトコルを使用し、グループ情報を獲得するためにXCAPを使用する。後術する本発明の機能は、上記したプロトコルを用いて実現でき、本発明の基本構成はPoCRel1システムに基づいてなされる。まず、本発明が適用される一般のPoCシステムの構成について説明する。図1は、通常のPoCシステム及び関連ネットワーク構造を示す概念図である。図1を参照すると、通常のPoCシステムはPoC端末100、XDMS130,140、及びPoCサーバ150を含むことができる。PoCシステムは、アグリゲーションプロキシサーバ160をさらに含む。これら構成要素は、アクセスネットワーク110、SIPIPコアネットワーク120、及び遠隔PoCネットワーク170を通じて接続される。次に、上記の構成要素について説明する。PoC端末100は、PoCクライアント102及びXDMCDocumentManagementClient104を含む。PoCクライアント102は、PoC端末100に内蔵されるサービス要求者であって、PoCサービス加入者にPoCサービスを提供するためのネットワークアクセスを遂行するためにPoC端末100に備えられる。PoCサービス加入者は、PoCクライアントが内蔵されたPoC端末を通じてPoCサービスを受信できる。以下、用語PoCクライアントは、PoCクライアントが内蔵されたPoCUE及びPoCサービス加入者として使用される。また、特に明記されない限り、PoCクライアントの参照符号は省略する。PoCクライアントは、主にPoCサービス加入者、すなわちPoCユーザーの側面でPoCセッションを開設し、既存のPoCセッションに参加し、あるいは開設されているセッションを終了する役割を果たす。また、PoCクライアントは、トークバーストを生成及び伝送する機能、緊急個人警報を支援する機能、及びPoCサービスにアクセスする場合に要求される認証機能を遂行する。PoCクライアントは、アクセスネットワーク110を通じて、SIPIPマルチメディア支援コアネットワークであるSIPIPコアネットワーク120に接続されることができる。SIPIPコアネットワーク120は、PoCサービスを支援するために、PoCサーバ150、XDMS130,140に接続される。このとき、PoCサーバ150は、PoCセッションを維持及び管理する制御PoC機能を遂行し、あるいは一対一のPoC通話または一対多のPoC通話のために開設されたPoCセッションに参加するための参加PoC機能を遂行できる。一方、PoCサービスは、コンファレンス通話のように、グループセッションを開設するサービスを含むことができる。このサービスのために、OMA標準は、グループリストサービスのためのXDMC104及びXDMS130,140を定義する。図1は、PoCサービスのために使用されるPoCXDMS140と、他のサービスイネーブラのために共通に使用される共有XDMS130とを示す。グループ及びグループメンバーに関する情報は、PoCクライアントを通じてXDMS130,140に入力されることができる。PoCクライアントは、XDMS130,140から伝送された個人又はグループリストを用いて呼出できるPoCクライアントに関する情報を獲得できる。XDMS130,140におけるグループ及びグループメンバーの生成、変更、及び管理は、PoCサービス提供者が信頼できるインターネット又はイントラネットのような通信ネットワークを通じてなされることができる。グループリストを生成、変更、及び除去するXML文書管理のプロトコルの詳細な説明は省略する。グループサービスに対するグループリスト関連要求がXDMC104から受信された場合に、アグリゲーションプロキシサーバ160は、適切な規則に従ってXDMS130,140にグループリスト関連要求をルーティングする。次に、図2を参照してPoCサーバ150について説明する。図2は、一般のPoCサーバを示すブロック構成図である。PoCサーバは、PoCセッションを全体的に保持及び管理する制御PoC機能部に分類されることができる。PoCサーバの機能別特性は、下記の<表1>及び<表2>を参照して説明する。<表1>に示すように、CFは、PoCサーバの機能中にPoCセッションを全体的に管理する役割をする。PoCサーバは、PoCクライアントからの発言権に対する要求を受信し、クライアントに権限を与える順序を配列し、その順にPoCクライアントに発言権を与える。また、PoCサーバは、グループPoC呼び出しに参加するすべてのPoCクライアントに特定のPoCクライアントからのトークバーストを分配し、グループPoC呼び出しに参加したPoCクライアントの情報を提供する。下記の<表2>に示すように、PFは、CFと各PoCクライアントとの間でPoCセッションを管理する。特に、PFは、PoCクライアントが発言権を要求した場合、又はCFがPoCクライアントに発言権を付与する場合に、PoCクライアントとCFとの間で発言権を中継する役割をする。また、PFは、CFとPoCクライアントとの間でメディアを中継し、相互に異なるコーデック間のトランスコーディングし、2個の同時PoCセッションで同時に発言している場合には、一つのユーザーによって選択された2個のPoCセッションのうちの一つをフィルタリングするためのフィルタリング機能を提供する。図3は、PoCサーバのCFとPFを図式的に説明するためのブロック構成図である。図3を参照すると、各PoCクライアント102A~102Dは、PF310A~310Dを通じてCF300にアクセスしてPoCセッションを設定する。ここで、発言権がCF300から話者として資格を有するPoCクライアントに与えられた場合に、資格のあるPoCクライアントに基づいたメディアは、各PoCクライアントに伝送される。このとき、話者として資格が与えられたPoCクライアントは、グループセッションに参加しているPoCクライアントに関する情報を確認した後のみ、発言することができる。PoCシステムにおいて、通話接続のための呼処理技術は、送信側と受信側の要求及び状態により多様な手順を可能にする。このような送信側と受信側の設定によってOMAによって要求されるPoCシステムの特徴は、次のようである。第一に、受信側は、PoCクライアントの要求によって自分の応答モードを設定でき、この応答モードは、自動応答モードと手動応答モードに分類される。自動応答モードで、該当情報が受信側によって指定されたPoCクライアントリストに含まれると、該当ネットワークは、受信側の受動応答の代わりに送信側の即時応答を送信する。このネットワークは、PoC端末が応答モード設定要求によって応答モード及び自動応答ユーザーリストを格納するため、PoC端末の動作の代わりに自動応答を送信する。手動応答モードは、送信側が自動応答ユーザーリストに含まれていない場合、又は送信側が自動応答ユーザーリストに含まれているか否か不明な場合、あるいは受信側がすべてのユーザーに対して手動応答を設定した場合に該当する。PoC通話要求は、受信ネットワークを介してPoC端末に伝送され、PoCクライアントの許可によって通話が連結される。第2に、PoCシステムは、PoCクライアントがユーザーのホームネットワークに属するPoCサーバとの接続が設定されたか否かに従ってondemandセッションモード又は事前開設セッションモードにあり得る。事前開設セッションモードは、PoCクライアントが、自分の要求によってそのホームネットワークに属するPoCサーバとの間で予めセッションを設定することを示す。事前開設セッションモードは、PoCクライアントが、メディアパラメータをPoCサーバと予め交渉して今後使用されるPoCサーバとメディアパラメータの再交渉なしに、迅速にセッションを開設するために必要である。事前開設セッションは、SIPINVITE方法を用いて、メインテキスト部、すなわちSDPMIMEに支援されるメディアパラメータを提供し、PoCサーバによって提供されるメディアパラメータを提供し、SIPサーバによって提供されるメディアパラメータに応答するPoCクライアントによって予め設定される。このとき、PoCサーバから受信された応答メッセージに新たに設定されるコンファレンスURIを含む事前開設セッションの識別情報は、PoCクライアントに回答する。事前開設セッションが使用される場合に、インターネットプロトコルアドレス、ポート番号、使用されるコーデック、及びトークバースト制御プロトコルは、事前交渉が可能である。ondemandセッションモードは、PoCクライアントがセッションを予め開設しない状態を示し、他のPoCクライアントがセッションを予め設定しない状態を示し、そして他のPoCクライアントからINVITEメッセージを受信した後に、PoCクライアントがPoC呼接続手順を遂行することを示す。PoCシステムで通話要求に応じて、応答モードの設定は、ネットワークの要素であるPoCサーバとユーザー側の端末であるPoCクライアントにすべて格納されることができる。応答モードがPoCクライアントを管理するホームネットワークに設定される場合に、応答モードは、PoCクライアントが属しているホームネットワーク内のPFとして作用するPoCサーバに設定される。このとき、PoC通話が他のPoCサーバから要求されると、PFは、遅延なしにセッション進行メッセージを通話要求ネットワークに自動に応答する。したがって、自動応答モードが設定された場合には、セッションセットアップメッセージがPoCクライアントに伝送される場合に比べて、通話要求手順が簡素化され、これによって初期発言権付与時間が短縮される。しかしながら、ホームネットワークで自動応答モードが設定される場合に、ユーザーが所望する応答と異なる結果が状況に従って発生する可能性があるため、応答モードは、PoCクライアントに設定されることができる。このとき、PoCクライアントの応答モードがホームネットワークに設定された応答モードより高い優先度を有する。これは、PoCクライアントがその応答モードを変更してPoCサーバに応答モード更新を要求する場合に、ネットワークでの信号遅延又は誤りによってリアルタイムで応答モードが反映されない場合に発生するプライバシー問題を解決する。要約すれば、PoCサービスは、ユーザーの応答モードをPoCサーバ又はPoCクライアントによって設定できるが、応答モードがユーザーの所望を最近に反映したPoCクライアントによって決定され、このような決定に基づいてメディアストリームが伝送される。以下、上述した特徴を有するPoCシステムでのPoCマルチメディアセッションの開設手順について説明する。送信側PoCクライアントは、SIPを用いて、マルチメディアセッション参加要求メッセージを送信して呼処理を要求する。このような呼処理要求に応答して、ターゲットPoCクライアントは、該当PoCサーバでの応答モードの設定と既存セッションが存在するか否かによって多様に応答する。PoC通話のための呼処理手順については、送信側ネットワーク及びターゲットネットワークの手順を例示して説明する。送信側PoCクライアントは、ターゲットPoCクライアントのSIPアドレス情報を含むSIPセッション参加要求メッセージを該当SIPIPコアネットワークに伝送する。このSIPINVITEメッセージは、送信側PoCクライアントのPoCアドレス情報、要求されるメディアパラメータ、PoCサービスを知らせる特性値情報などのような要素をさらに含むことができる。要求されるセッションがマルチメディアに該当すると、要求されるメディアパラメータは、オーディオとビデオのエンコーディング方法、ビットレート、ペイロードタイプのような多様な特性値を含むことができる。SIPINVITEメッセージは、DHCPサーバ又はDNSでの経路クエリーを用いてIMSネットワーク内の該当IMSサーバ、すなわちPCSPF及びSCSPFを通じて参加PoCサーバに伝送される。一般の通話が要求されると、PoCクライアントが接続された参加PoCサーバは、開設されるセッションのトークバーストを管理する制御PoCサーバと分離して実現されることができるため、PFに伝送されたSIPINVITEメッセージは、該当SIPIPコアネットワークを通じて制御PoCサーバCFに伝送される。CFを含むPoCセッション制御ネットワークは、ターゲットネットワークにSIPINVITEメッセージを伝送し、このターゲットネットワークから応答メッセージを受信する。ターゲットネットワークから応答されるSIPメッセージは、‘1xx’で表される臨時応答メッセージ、‘2xx’で表される成功応答メッセージ、又は‘4xx’~‘6xx’で表される誤り応答メッセージであり得る。自動応答モードで、SIP183‘sessionprogress’信号は、応答メッセージとして受信されることができ、この応答メッセージを用いて通話要求者のIMSネットワークでPoCサーバとPoCクライアントとの間の接続が遂行されることができる。ターゲットPoCクライアントの通話許可信号は、SIP183‘sessionprogress’信号又はSIP200‘OK’応答として伝送され、CF及びPFを含むPoCサーバを通じて送信側PoCクライアントに伝送される。200‘OK’応答又は183‘sessionprogress’信号がターゲットPoCサーバから受信されると、CFは、PoC呼が接続されたと決定し、トークバースト発言権を付与するための‘floorgranted’信号を送信側PoCクライアントに伝送する。200‘OK’応答又は183‘sessionprogress’信号によってトークバースト発言権の付与は、‘confirmed’又は‘unconfirmed’によって識別されることができる。‘unconfirmed’応答が受信されると、CFは、バッファリング機能を必要とする。SIPINVITE要求メッセージに対する応答信号を受信した後に、送信側PoCクライアントは、トークバーストを伝送し、RTCPを用いて伝送信号を伝送するための‘floorgranted’信号を受信する。‘floorgranted’信号は、とイークバースト仲裁権を有するCFによって与えられ、PoCクライアントを管理するPFを通じてPoCクライアントに伝送される。‘floorgranted’信号は、SIPの代わりにベアラの経路を使用するため、‘floorgranted’信号は、対案として用いるIMSネットワークのようなSIPIPコアネットワークを利用せずに伝送されることができる。通話接続音を受信される送信側PoCクライアントは、メディアストリームをRTPを用いて伝送する。以下、当該技術分野で通常の知識を持った者が本発明を容易に実施できるように、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。本発明は、PoCマルチメディア環境で最初の応答クライアントによって応答するメディアタイプに限定されるRTPメディアを伝送する送信側PoCサーバ間のPoCセッションを開設し、上記セッションでセッションアップデートを通じて少なくとも一つのターゲットPoCクライアントによって支援されるメディアタイプのみを追加又は除去するセッション管理システムとその方法及び端末装置に関する。PoCセッションの開設のために、PoCクライアントによって支援される多様なメディアタイプが相互に共通でない場合、あるいは最初の応答メッセージに含まれた伝送可能なメディアタイプが送信側によって提供されるメディアタイプと異なる場合に、PoCセッションで少なくとも一つの受信可能なPoCクライアントによって支援されるメディアタイプのみを支援するPoCセッションを開設するためのPoCシステムを構成するPoCクライアントとPoCサーバの構成は、図4を参照して説明する。図4は、本発明の実施形態により、相互に接続される、PoCクライアント102を含むPoC端末100とPoCサーバ150を示すブロック構成図である。図4を参照すると、PoC端末100は、ユーザーとのインターフェースのための装置であって、各キー入力にその固有のキー入力データを出力するユーザーインターフェース404を含む。また、PoC端末100は、PoCサーバ150とのパケットデータ通信を遂行するために、プロトコルスタックで構成されるデータ伝送部410を含む。PoC端末100は、データ伝送部410によって受信されたメディアデータをディスプレイし、ユーザーインターフェース404から出力されるデータをディスプレイするディスプレイ部400を含む。さらに、PoC端末100は、制御部402を含む。制御部402は、PoCクライアント102のデータ送受信、ディスプレイ部400のディスプレイ、チャットPoCグループに参加するための招待予約メッセージの生成と伝送、及び応答メッセージの受信を制御する。特に、PoCクライアント102がセッション開設PoCクライアントである場合に、制御部402は、セッション開設のためにユーザーによって要求されるメディアタイプ及びメディア属性情報を含むセッション参加要求メッセージをPoCサーバ150に伝送する。また、現在セッションによって支援される特定のメディアタイプ情報を含むreINVITEメッセージがPoCサーバ150から受信された場合に、制御部402は、このreINVITEメッセージに対応してPoCサーバ150に応答メッセージを伝送する。一方、PoCクライアント102がセッション参加PoCクライアントである場合に、制御部402は、INVITEメッセージに応答してPoCサーバ150に支援可能なメディアタイプ情報を含む応答メッセージを伝送する。PoC端末100は、PoC端末100の全般的な機能に関連した情報を格納し、PoCサービスに関連したデータ及び端末を識別するためのユーザーアカウント、及びユーザーによって設定され、あるいはPoCサーバ150から提供される情報を格納するメモリ405を含む。特に、メモリ405は、受信された応答メッセージに含まれた支援可能なメディアタイプに関する情報を格納する。PoCサーバ150は、プロトコルスタックで構成されるデータ伝送部420、多重マルチメディア通話サービス処理部430、メモリ421、及び参加PoC機能コンポーザー440を含む。PoCサーバ150の動作については、下記の図5を参照して詳しく説明する。図5は、本発明の一実施形態によるPoCクライアントとCFとの間で多様なメディアタイプを支援するマルチメディアPoCセッションを開設するためにCFを遂行するPoCサーバにマルチメディアPoCセッションを開設するプロセスを示すフローチャートである。図5を参照すると、ステップ500で、CFがINVITEメッセージを受信すると、CFは、ステップ502で、INVITEメッセージに含まれたメディア属性情報を付加的メモリ421にキャッシュし、このINVITEメッセージをターゲットPoCクライアントに伝送する。CFは、ステップ504で、受信された応答メッセージがINVITEメッセージに対する最初の応答メッセージであるか否かを判定する。ステップ504で、受信された応答メッセージが最初の応答メッセージであると判定された場合に、CFは、ステップ506で、最初の応答メッセージに含まれたセッション参加PoCクライアントによって支援されるメディアタイプが、INVITEメッセージに含まれたメディアタイプと同一であるか否かを判定する。ステップ506で、メディアタイプがすべて同一であると判定された場合に、CFは、ステップ514で、すべてのメディアにそれぞれUDPポート番号を割り当て、メディアを活性化する200‘OK’応答メッセージを生成する。その後、CFは、ステップ510で、送信側PoCクライアント、すなわちセッション開始要求PoCクライアントにこの200‘OK’応答メッセージを伝送する。しかしながら、ステップ506で、メディアタイプが同一でないと判定された場合には、CFは、ステップ508で、最初の応答メッセージに含まれたセッション参加PoCクライアントによって支援される各メディアタイプのみにUDPポート番号を割り当て、メディアを活性化する200‘OK’応答メッセージを生成する。UDPは、RFC768に定義され、CMTPグループセッションを開設する実施形態を示しているが、本実施形態は、本明細書で提案する同一の原理によって所定のグループにも適用できる。図6を参照すると、ステップ600で、PoCセッションの開設を所望するPoCクライアントA50がINVITEメッセージをCF51に伝送すると、CF51は、ステップ601~605で、PoCセッションに招待されたターゲットPoCクライアントにINVITEメッセージを伝送する。このセッション開設要求PoCクライアントA50から伝送されたINVITEメッセージは、PoCクライアントA50によって要求されるメディアタイプと、そのボディー部分でターゲットPoCクライアントのアドレス情報とを含む。図6に示す本実施形態では、INVITEメッセージに含まれたPoCクライアントA50によって要求されるメディアタイプが、オーディオ、ビデオ、及びテキストであると仮定する。CF51は、PoCクライアントA50から伝送されたINVITEメッセージに含まれたメディアタイプの詳細なメディア属性情報であるRTPメディアマッピング情報、コーデックモード、及び符号化率情報のような情報を付加的メモリ421にキャッシュする。CF51からINVITEメッセージを受信した各ターゲットPoCクライアントは、支援可能なメディアタイプ情報を含む応答メッセージをCF51に伝送する。図6に示した実施形態で、PoCクライアントB53によって支援されるメディアタイプがオーディオタイプであり、PoCクライアントC55によって支援されるメディアタイプがオーディオ及びテキストタイプであり、PoCクライアントDによって支援されるメディアタイプがビデオとテキストタイプであり、PoCクライアントEによって支援されるメディアタイプがオーディオタイプであると仮定する。最初のSIP200‘OK’応答メッセージが、INVITEメッセージに応答してPoCサーバB52を通じてPoCクライアントB53から受信されると、CF51は、ステップ606~608で、最初のSIP200‘OK’応答メッセージに含まれたPoCクライアントB53によって支援されるメディアタイプを分析する。CF51は、最初のSIP200‘OK’応答メッセージに含まれたPoCクライアントB53によって支援されるメディアタイプと、メモリ421に格納されたメディアタイプとを比較する。図6に示した本実施形態では、PoCクライアントA50によって要求されるメディアタイプがオーディオ、ビデオ、及びテキストタイプであり、PoCクライアントB53によって支援されるメディアタイプはオーディオタイプであるため、その比較結果は同一でないケースに該当する。この場合、CF51は、最初のSIP200‘OK’応答メッセージに含まれたPoCクライアントB53によって支援されるオーディオタイプのみにUDPポート番号を割り当てる200‘OK’応答メッセージを生成し、メディア伝送を活性化する。CF51は、ステップ609で、PoCクライアントA50に200‘OK’応答メッセージを伝送する。このCF51は、最初に提供されたメディアタイプ、すなわちオーディオ、ビデオ、テキストタイプ、メディア属性情報及び最初応答したメディアタイプ、すなわちオーディオタイプを固有のコンファレンス情報として格納し、それによってセッションアップデートは、応答メッセージ内のメディアタイプ特性によって以後に遂行される。PoCクライアントB53によって支援されるメディアタイプが、メモリ421に格納されたメディアタイプと同一である場合に、CF51は、すべてのメディアにUDPポート番号を割り当て、メディアを活性化する200‘OK’応答メッセージを生成する。その後、CF51は、PoCクライアントA50に200‘OK’応答メッセージを伝送する。一方、第2の応答メッセージが、ステップ610~611でPoCクライアントC55から受信された場合、CF51は、PoCクライアントC55から伝送される200‘OK’応答メッセージに含まれたメッセージボディーを分析してPoCクライアント55によって支援されるメディアタイプを判定する。上記したように、PoCクライアントC55によって支援されるメディアタイプがオーディオ及びテキストタイプであるため、第2の応答メッセージは、オーディオ及びテキストタイプを支援する応答メッセージである。このとき、CF51は、メモリ421に格納されたコンファレンス情報を読み取ることによって、PoCクライアントA50とCF51との間でオーディオに加えてテキストを伝送するためにセッションアップデートを遂行する。オーディオとテキストを伝送するセッションのアップデートのために、CF51は、ステップ612で、オーディオとテキストタイプ情報を含むreINVITEを生成し、このreINVITEをPoCクライアントA50に伝送する。CF51は、ステップ613で、PoCクライアントA50から応答メッセージを受信すると、セッションをアップデートする。その後、CF51は、セッションを維持し、受信されたRTPメディアを伝送する。また、CF51は、ステップ613で、テキストを支援するために、セッションアップデート応答によって格納されたコンファレンス情報をアップデートする。このセッションアップデートは、格納されたメディア属性情報からテキストに対する属性情報を用いて生成されたreINVITEメッセージを使用する。以下、このreINVITEメッセージのボディー部分について、図6Cを参照して詳細に説明する。200‘OK’応答メッセージは、ステップ614,615で、他のPoCクライアント、すなわちPoCクライアントEとPoCクライアントDから受信される場合に、200‘OK’応答メッセージのそれぞれのボディー部分が分析され、各200‘OK’応答メッセージに含まれたメディアタイプ情報が、PoC該当クライアントA50とCF51との間のセッションで支援されるメディアタイプに該当する場合には、セッションアップデートが遂行されずに、対応するPoCクライアントのアイデンティティ情報のみがコンファレンス情報にアップデートされる。すなわち、PoCクライアントEから受信された200‘OK’応答メッセージによって、PoCクライアントEによって支援されるメディアタイプであるオーディオタイプは、PoCクライアントA50とCF51との間のセッションで支援されるメディアタイプであるため、別のメディアタイプアップデートは遂行されない。しかしながら、PoCクライアントDから受信された200‘OK’応答メッセージによって、PoCクライアントDによって支援されるメディアタイプの中でビデオタイプが、新たに支援されるメディアタイプであるため、オーディオ、テキスト、ビデオタイプを伝送するセッションアップデートは、ステップ612,613のようにステップ616、617で遂行される。上述したように、reINVITEメッセージは、ステップ616で、ビデオタイプの格納された属性情報を用いて生成され、PoCクライアントA50に伝送され、200‘OK’応答メッセージは、reINVITEメッセージに応答して受信され、それによってオーディオ、ビデオ、及びテキストを支援するためのセッションをアップデートする。その後、CF51が、ステップ618で、PoCクライアントFから200‘OK’応答メッセージを受信しても、PoCクライアントFによって支援されるメディアタイプであるオーディオ及びビデオタイプは、PoCクライアントA50とCF51との間でセッションによって支援されるメディアタイプに該当するため、別途のメディアタイプアップデートは遂行されない。図6でACK信号及び発言権を管理するためのMBCPに代替可能であり、ステップ613及び617でMBCPACKメッセージを受信することによって非活性化メディアタイプであるテキストとビデオが各々活性化される。通常、本発明で使用される‘メディアタイプ’は、オーディオ、ビデオ、イメージ、テキストのようなメディア特性を区分する情報として使用される。また、この‘メディアタイプ’は、発明の拡張された技術として同一のメディアタイプを区別する最小の基本単位で扱われる。例えば、2個の相互に異なるビデオが存在すると、すなわち同一のメディアタイプである第1のビデオと第2のビデオが各々存在すると、その第1及び第2のビデオは、各々接続されたメディアパラメータの特性によって相互に異なるメディアタイプとして考えられる。したがって、‘メディアタイプ’は、同一のメディアタイプを示すことができ、メディアストリームを区分する最小の基本単位として拡張して使用することもできる。したがって、拡張された技術の実施形態として、送信側PoCクライアントが第1のオーディオ、第2のオーディオ、第1のビデオ、第1のビデオのメディアタイプを含むセッション開設を要求した場合に、ホームPoCサーバは、ターゲットネットワークから受信されたSIP応答メッセージで採択されたメディアタイプに関係なく、初期提案された全体メディアタイプ第1のオーディオ、第2のオーディオ、第1のビデオ、及び第1のビデオを伝送するPoCセッションを開設することができる。以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲を外れない限り、様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。したがって、本発明の範囲は、前述の実施形態に限定されるものではなく、特許請求の範囲の記載及びこれと均等なものに基づいて定められるべきである。"