JP2008521335A - ＰｏＣシステムの応答モードに基盤するＰｏＣ呼処理方法及びシステム - Google Patents

Abstract

本発明は、ＰｏＣ（Push to talk Over Cellular）通話のためのセッション設定方法及びシステムに関する。本発明のセッション設定方法では、ＰｏＣサーバーとＰｏＣクライアントとの応答モードが一致しない場合、エラーメッセージがＰｏＣサーバーに転送される。また、サーバーの自動応答を示す新しいデータフィールドをリアルタイム転送制御プロトコル（Real-time Transport Protocol：ＲＴＣＰ）メッセージのペイロードに挿入することによって、ＰｏＣ通話のための呼処理を改善し、該当ＰｏＣサーバーとＰｏＣクライアントとの応答モードが一致しない場合、追加されたデータフィールドを用いて端末機の機能を拡張させる。

Description

本発明は、ＰｏＣ（Push to talk Over Cellular：以下、ＰｏＣという）通話のためのセッション設定方法に関し、より詳細には、受信側ＰｏＣユーザが自身のＰｏＣ端末機にホームＰｏＣサーバーと事前設定セッション（pre-established session）を設定し、また、ＰｏＣサーバーに自動応答モード（AUTO-ANSWER mode）を設定した場合、ＰｏＣサーバーと端末機との応答モードの不一致を考慮して呼を処理することができるＰｏＣシステムクライアントの応答モードに基盤するＰｏＣ呼処理方法及びシステムに関する。

移動通信技術が画期的に発展し、移動通信網が拡大されるにしたがって、携帯電話を用いた多様なサービスやアプリケーションが提供されている。しかも、携帯電話のユーザの要求も増加し、位置サービス、マルチメディアサービス、ＰＴＴ（push to push）サービスのような多様な付加サービスに拡大されている。このような付加サービスのうちＰＴＴサービスは、従来、無線機やＴＲＳなどで可能であったグループ通話と音声通話はもちろん、インスタントメッセンジャー、状態表示など多様な付加機能をサポートする。

現在、移動通信網においてこのようなＰＴＴ機能を用いたＰｏＣサービスに対する標準化が論議されている。ＰｏＣサービスの固有な特徴のうち１つは、ユーザが複数のＰｏＣセッションに参加することができるので、セッション間を移動しつつ通話サービスを利用することができるという点である。ユーザが複数のセッション間を移動しつつ通話サービスを利用することができるという特徴は、移動通信サービスを定義する団体であるＯＭＡ（Open Mobile Alliance）の要求事項に明示されている。

図１は、従来のＰｏＣサービスシステムを示すブロック図である。図１を参照すれば、ＰｏＣクライアント１０は、移動局、すなわちＰｏＣ端末機に内蔵されるサービス要請者であり、アクセス網２０を介してＳＩＰ（session Initiation Protocol）及びＩＰ（Internet Protocol）マルチメディア機能をサポートするＳＩＰ／ＩＰコア網３０に連結される。

前記ＰｏＣクライアント１０は、ＰｏＣユーザ端末機に常駐しながらＰｏＣサービスへの接続を可能にする。前記ＰｏＣクライアント１０の主な機能は、ＰｏＣセッションを開始し、現在進行中のＰｏＣセッションに参加し、ＰｏＣセッションを終了することである。前記ＰｏＣクライアント１０は、トークバーストを形成して伝達し、インスタントパーソナルアラート(Instant Personal alert)をサポートし、Ｐｏｃサービスに接続する時、認証を行う。以下、別の言及がない限り、ＰｏＣクライアント１０は、ＰＴＴサービス加入者と同じ意味として使われる。

ＳＩＰ／ＩＰコア網３０は、ＰｏＣサービスをサポートするために、ＰｏＣサーバ６０と、ＧＬＭＳ（Group List and Management System）５０、及びプレゼンスサーバ７０に連結される。

前記ＰｏＣサーバ６０は、ＰｏＣセッションを維持、管理するためのControlling PoC Function機能、又は、一対一(one-to-one)のＰｏＣ通話や一対多(one-to-many)のＰｏＣ通話（グループＰｏＣ通話）のためにＰｏＣセッションに参加するためのParticipating PoC Function機能を有する。前述したように、遠隔ＰｏＣネットワーク８０は、前記ＰｏＣクライアント１０からプレゼンスサーバ７０まで、ＰｏＣクライアント１０、アクセス網２０、ＳＩＰ／ＩＰコア網３０、ＧＬＭＳマネジャー４０、ＧＬＭＳ５０、ＰｏＣサーバ６０、プレゼンスサーバ７０を含む。

前記ＰｏＣサーバの機能は、ＰｏＣセッションを全般的に維持、管理するためのControlling PoC Function（以下、ＣＦという）と、各ＰｏＣセッションを維持、管理するためのParticipating PoC Function（以下、ＰＦという）とに分けられる。前記ＣＦ及びＰＦの機能を各々表１及び表２を参照して説明する。

表１のように、ＣＦは、ＰｏＣセッションを維持する役目をする。前記ＰｏＣサーバは、ＰｏＣクライアントの話す権利（floor）に対する要請を受け入れて、クライアントが権限を付与する順序を定め、クライアントにその順序に権限を付与する。また、前記ＰｏＣサーバは、特定のＰｏＣクライアントからのトークバーストをグループＰｏＣ通話に参加した全てのクライアントに分配し、前記グループＰｏＣ通話に参加したＰｏＣクライアントに関する情報を提供する。

下記表２のように、ＰＦは、ＣＦと各ＰｏＣクライアント間のＰｏＣセッションを管理する。ＰＦは、発言権をＣＦからクライアントに中継する役目をする。ＰＦは、ＣＦとＰｏＣクライアントとの間にメディアを中継し、異なるコーデック間にトランコーディングを提供し、２つのＰｏＣセッションで同時に対話が進行される時、２つのＰｏＣセッションのうちユーザが選択した１つをフィルタリングする機能を提供する。

前述のように構成されたＰｏＣシステムにおいてＰｏＣユーザは、自身の端末機を介してＧＬＭＳマネジャー４０にグループ及びグループメンバーに関する情報を入力したり、ＧＬＭＳマネジャー４０から転送された個人あるいはグループ目録を通じて自身が呼び出しできるＰｏＣユーザの情報を確認することができる。前記ＧＬＭＳマネジャー４０でグループ及びグループメンバーの生成、修正及び管理を行うことができる他の方法は、インターネットやイントラネットなどＰｏＣサービス提供者が信頼できる通信網を通じて入力するためのものである。

ＰｏＣ通話サービスを利用するために、ＰｏＣユーザは、前記ＳＩＰ／ＩＰコア網３０に自身のＰｏＣアドレスを登録する。この時、前記ＳＩＰ／ＩＰコア網３０は、ＰｏＣユーザの要請に基づいてＰｏＣユーザに関する情報を格納する。したがって、他のＰｏＣユーザがＰｏＣグループ通話をしようとする場合には、まず、自身の情報を前記ＳＩＰ／ＩＰコア網３０に登録し、ＧＬＭＳ５０から転送されたグループ識別情報を用いて自身のＳＩＰ／ＩＰコア網３０に通話要請をする。この時、前記ＳＩＰ／ＩＰコア網３０は、要請するＰｏＣユーザ情報を用いてアドレス決定とドメイン位置を決定した後、要請するＰｏＣユーザが登録されたホームＰｏＣサーバー６０にＰｏＣ通話要請を転送する。前記ＰｏＣサーバー６０は、このようなＰｏＣ通話要請に対してＰｏＣセッション開設を準備し、ＧＬＭＳ５０からユーザ各々の情報を獲得し、該当ＳＩＰ／ＩＰコア網に通話要請信号を伝達する。この時、イントラドメイン内のユーザに対する通話要請の場合、前記ＰｏＣサーバー６０は、ＰＦ及びＣＦの機能を共に行う。通話が要請されたＰｏＣユーザを管理する前記ＰｏＣサーバー６０は、自身に伝達されたＰｏＣユーザ情報を利用し、ＳＩＰ／ＩＰコア網の位置を決定し、ＰｏＣユーザに通話要請をするようになる。

本発明は、現在標準化中のＩＰマルチメディアＣＮ網を利用し、ハフデュプレクス（half duplex）形態の通信を利用し、ユーザのグループ及び所在情報を用いて通話要請によるインスタント通話を可能にするＰｏＣシステムの通話を設定するための呼処理技術に関する。特に、このようなＰｏＣ通話設定のための呼処理では、送信側と受信側の要求及び状況によって多様な手続が行われることができる。送信側と受信側の設定によってＯＭＡで要求するＰｏＣシステムの特徴は、次の通りである。

第一に、受信側は、ＰｏＣユーザの要求によって自身の応答モードを設定することができ、前記応答モードは、大きく自動応答モードと受動応答モードとに分けられる。

前記自動応答モードは、受信側で指定したＰｏＣユーザ目録に含まれる場合、受信側の受動的な応答に代えて、該当ネットワークから送信側に直ちに応答を送ることを意味する。ＰｏＣサーバーは、端末機の応答モード設定要求によって応答モードと該当ユーザ目録を格納する機能を有するので、ネットワークで端末機の動作に代えて、自動的に応答を送る。一方、前記受動応答モードは、受信側の自動応答ユーザ目録に含まれていないか、包含可否が不明な場合、または全てのユーザに対して受動的に応答するように設定された場合に該当し、ＰｏＣ通話要請が受信ネットワークを経てユーザの端末機まで転送され、ＰｏＣユーザの許諾により通話が連結されることを意味する。

第二に、前記ＰｏＣシステムは、ユーザのホームネットワーク内のＰｏＣサーバーとの連結及び設定可否によって要求（on-demand）セッションモードと事前設定（pre-established）セッションモードとに分けられる。

前記事前設定セッションモードは、ＰｏＣユーザが自身の要求によってＰｏＣクライアントと自身のホームネットワークに属するＰｏＣサーバーとの間にあらかじめ特定のセッションを設定することを意味する。このような事前設定セッションは、ＰｏＣユーザがメディアパラメータをＰｏＣサーバーと事前に交渉し、今後使われるサーバー−クライアント間のメディアパラメータに対する再交渉無しに速い呼設定を具現する機能である。前記事前設定セッションは、ＰｏＣクライアントがＳＩＰ ＩＮＶＩＴＥ方法を通じてセッション記述プロトコル（ＳＤＰ：Session Description Protocol）本体までサポートされるメディアパラメータを提供し、サーバーが提供するメディアパラメータに対して応答することによって具現される。前記事前設定セッションを設定するために、ＰｏＣクライアントは、コンファレンスＵＲＩ（conference ＵＲＩ）を含むサーバーからの応答メッセージに新しく設定される事前設定セッションの識別情報をＰｏＣユーザに伝達する。このような事前設定セッションを利用する場合、ＩＰアドレス、ポート番号、使われるコーデック及びトークバースト制御プロトコルの事前設定が可能である。

前記要求セッションモードは、ＰｏＣユーザが事前設定セッションを設定しない状態を意味し、他のＰｏＣユーザの招待メッセージを受信した後、ＰｏＣ呼連結手続を行う。

一方、ＯＭＡで標準化中のＰｏＣスペックは、前述した通信システムの基本的機能よりは、次のような特徴を有している。

まず、ＰｏＣシステムは、受信者があらかじめ設定した許可されたＰｏＣユーザに対してＰｏＣ受信者の応答モードに関係なく自動で応答を送り、受信端末機で通話を連結する受動応答無視（manual answer override、以下、ＭＡＯという）モードをサポートする。ＭＡＯ要請は、許可された通話要請者に限ってサポートされ、ＭＡＯ指示子は、ＰｏＣ通話要請（ＩＮＶＩＴＥ）メッセージに含まれて伝達される。このようなＭＡＯ要請は、非常対応通信、災難構造通信、構造応答通信のような緊急な目的と公共サービスに適合したＰｏＣ機能といえる。しかし、このようなＭＡＯは、ＯＭＡ標準文書でオペレーターによって選択的に具現可能な機能である。しかも、ＰｏＣクライアントが自身が属するホームネットワークでＭＡＯをサポートしても、相手ネットワークでサポートしなければ、この機能は作動しない。

次に、ＰｏＣシステムで通話要請に対する応答モードの設定は、ネットワークの構成要素であるＰｏＣサーバー及びユーザ側の端末機であるＰｏＣクライアントで共に格納されることができる。特にＰｏＣクライアントを管理するホームネットワークに応答モードを設定する時、ＰｏＣクライアントを含むホームネットワーク内のＰＦ機能を行うＰｏＣサーバーで応答モードが具現される。このようにネットワーク側の応答モードを設定する場合、他のＰｏＣサーバーからＰｏＣ通話が要請されれば、ＰＦが自動でセッション進行メッセージを通話要請ネットワークに伝達することによって、ＰｏＣクライアントまでセッション設定メッセージが伝達された後に応答される手続に比べて通話要請手続が簡素となる。

しかし、ネットワークで自動で応答を行う場合、状況によってユーザの応答と異なる結果を招くことができるので、ＰｏＣユーザは、自身のクライアントに応答モードを設定することができ、この時、ユーザのクライアントの応答モードがネットワーク上に設定された応答モードに優先する特徴がある。これは、ＰｏＣユーザが自身の応答モードを端末機を用いて変更し、ＰｏＣサーバーに応答モード更新を要求する時、無線接続網やＩＰコア網で信号遅延またはエラーに起因してリアルタイムで応答モードが反映されない時に発生するプライバシー問題を解決するためのものである。すなわち、ＰｏＣサービスは、ユーザの応答モードをＰｏＣサーバー及びＰｏＣクライアントに共に設定することができるが、ユーザの意思によって決定される行動を通じてＰｏＣセッション連結に基盤してメディア（実際ユーザの音声）ストリームが伝達される。

前記ＰｏＣシステムの様々な機能と特徴を考慮する時、多様なＰｏＣ呼処理手続が発生することができる。本発明では、ＰｏＣ通話受信側のＰｏＣサーバーとクライアント間にセッションがあらかじめ設定され、ＰｏＣサーバーに自動応答モードが設定された場合、送信側の一般的なＰｏＣ通話要請（選択的なＭＡＯが要請されていない場合）に対して自動応答を表示するメッセージ情報を提供し、終端ＰｏＣ端末機の応答モード設定に連動してＰｏＣ通話要請に対する呼処理を行う方法に関する。

以下、前述した特徴を有するＰｏＣシステムで従来のＰｏＣセッション連結手続を図２及び図３を参照して説明する。図２及び図３は、一般的なＰｏＣ通話要請者がＳＩＰプロトコルを用いて要請メッセージを伝達することによって、呼処理を要請し、受信側には、自動応答モードが設定され、事前設定セッションが存在する場合、通話送信側及び通話受信側の呼処理手続を各々示している。

まず、図２を参照すれば、ステップ１でＰｏＣクライアントＡは、自身が対話しようとする受信者のＳＩＰアドレス情報を含むＩＮＶＩＴＥ要請をＳＩＰ／ＩＰコアＡに送る。この時、前記通話要請には、通話要請クライアントのＰｏＣアドレス情報、必要なメディアパラメータ、ＰｏＣサービスを示す特性情報などの要素を含み、ＤＨＣＰサーバーやＤＮＳサーバー（不図示）での経路質疑を通じてＩＭＳネットワーク内の該当サーバー（例えば、Ｐ−ＣＳＣＦ及びＳ−ＣＳＣＦ（不図示））を経由して参加（participating）ＰｏＣサーバーに伝達される（ステップ２）。一般的な通話要請時、ＰｏＣユーザに連結された参加ＰｏＣサーバーは、開設されたセッションのトークバーストを管理する制御ＰｏＣサーバーと分離して具現されることができるので、ステップ１及び２で送られたＩＮＶＩＴＥ要請は、各ネットワークのＳＩＰ／ＩＰコア網を経由して制御ＰｏＣサーバーＸに伝達される（ステップ３〜５）。

ＣＦを含む制御網は、前記ステップ５で伝達された通話要請メッセージを該当ＳＩＰ／ＩＰコア網に伝達した後、応答メッセージを受信する。受信側ネットワークで応答されるＳＩＰメッセージは、１ＸＸタイプの臨時応答メッセージ、２ＸＸタイプの成功応答メッセージまたは４ＸＸ〜６ＸＸタイプのエラー応答メッセージであるが、本発明では、正常的な呼処理手続を中心に説明する。前記１ＸＸ〜６ＸＸタイプのメッセージは、この技術分野でよく知られているので、ここでは詳細な説明を省略する。ステップ５の以後、ＣＦは、ＡＵＴＯ−ＡＮＳＷＥＲ応答やＯＫ応答を受信することができる。図２でＡＵＴＯ−ＡＮＳＷＥＲ応答の場合、ＣＦは、ＳＩＰ １８３“Session progress”信号を受信することができ、通話要請者のＩＭＳネットワーク内でＰｏＣサーバーとクライアント間の連結を進行することができる。受信者の通話許諾信号は、前記ＳＩＰ １８３“Session Progress”信号やＳＩＰ２００“ＯＫ”応答として送られ、ＣＦ及びＰＦのＰｏＣサーバーを経由してＰｏＣクライアントＡに伝達される（ステップ６〜１０）。一方、ＣＦは、前記受信側ＰｏＣサーバーから２００ ＯＫ応答や１８３ Session Progress信号を受信した後、ＰｏＣ呼が連結されたことを判断し、クライアントＡにトークバースト発言権を付与する発言権付与信号を伝達する（ステップ１１、１２）。前記ＰｏＣクライアントＡは、ステップ６〜１２でＩＮＶＩＴＥ要請に対応する確認応答信号を受信した後、トークバースト転送許可信号（通話連結音）を伝達するために、発言権付与信号をＲＴＣＰメッセージを用いて受信する（ステップ１１、１２）。この時、前記発言権付与信号は、トークバースト交渉権限を有するＣＦで生成され、該当ＰｏＣクライアントを管理するＰＦを介してＰｏＣクライアントに転送され、ＳＩＰプロトコルよりはベアラー（bearer）の経路を用いてＳＩＰ／ＩＰコア網を経由せずに伝達されることができる。次に、このような通話連結音を確認したＰｏＣユーザは、メディア（代表的に音声）ストリームをＲＴＰプロトコルを用いて伝達する。

図３は、送信側の通話手続に対応して受信側のサーバーとクライアントとの間にセッションがあらかじめ設定された場合、受信側の従来の手続を示す流れ図である（この時、事前設定セッションを設定するＰｏＣサーバーとＰｏＣクライアントとの間のメディア特性値は、新しいセッションが要請されても、変化なしにそのまま使われることを仮定する）。

送信側ネットワークから受信されたＩＮＶＩＴＥ要請（通話要請メッセージ）は、ＩＭＳネットワークの呼処理手続によって受信側ＰｏＣクライアントのホームネットワークに属するＰｏＣサーバーに伝達される（ステップ１〜３）。この時、ＰＦ Ｂ（ＰｏＣサーバーＢ）は、自身の応答モード設定値を自動応答モードで設定するので、前記通話要請メッセージに対応して送信側ネットワークにＳＩＰ２００“ＯＫ”メッセージを送る（ステップ４〜６）。また、事前設定セッションを変更する必要がないので、前記ＰＦ Ｂは、自身と連結されているＰｏＣクライアントには通話要請メッセージを送らない。

一方、ＩＭＳ経路を介して回答されたＯＫ応答を受信した制御網のＰｏＣサーバーは、送信側ＰｏＣクライアントにＯＫ応答を伝達し、ＰｏＣ呼処理手続を終了し（ステップ７）、送信側ＰｏＣクライアントにトークバースト発言権を付与する発言権付与信号を伝達する（ステップ８）。一方、ＣＦは、発言権を付与するＲＴＣＰメッセージを送ると同時に、前記発言権を有するＰｏＣユーザのＰｏＣアドレスまたはディスプレイ名前を含む発信トークバースト信号を受信側ＰｏＣユーザに伝達し（ステップ９、１０）、前記受信ＰｏＣクライアントが以後伝達されるメディアストリームの送信者情報をあらかじめ受信することができるようにする。トークバースト信号は、（図２のように）ＳＩＰプロトコルでないベアラー経路を利用するので、ＳＩＰ／ＩＰコア網を経由せずに伝達されることができる。一方、送信側で送ったメディア（音声）ストリームは、メディアベアラーの経路を介してＲＴＰプロトコルを用いてクライアントＢに伝達され、通話が始まる。

図４は、図３のステップ１で送信側が要請するＩＮＶＩＴＥ要請に含まれる情報要素を示す表である。前記通話要請メッセージは、ＰｏＣ通話要請者及び受信者のＰｏＣアドレス、クライアントやサーバーで与えられるメディアパラメータ情報、ＰｏＣ通話を示す指示子、ＰｏＣサーバー内に設定される指示子、送受信ネットワーク間に交渉するトークバースト制御プロトコルなどを含む。

事前設定セッションを管理するＰｏＣサーバーが事前設定セッションが存在するＰｏＣクライアントに対して自動応答モードを設定する場合、従来の技術による前記通話要請処理手続でＰＦは、ＡＵＴＯ−ＡＮＳＷＥＲを伝達せずに、直ちにＯＫ応答を回答する。

このような受信側ＰｏＣサーバーでのＯＫ応答は、送信側ネットワークに伝達され、送信側ＰｏＣクライアントは、ＯＫ応答信号と一緒にトークバースト許諾信号を受信し、実際メディアストリームを転送する。また、ＰｏＣサーバーであるＣＦは、２００ ＯＫ信号を受信したので、伝達されるメディアストリームに対してバッファリングを行うことなく、受信側ネットワークに直ちに伝達する。そして受信側ネットワークのＰｏＣサーバーは、伝達されたメディアストリームのために別途のＳＩＰ信号を伴わないので、ＲＴＰプロトコルを使用し、直ちに受信ＰｏＣクライアントにメディアストリームを転送する。

前述のように、事前設定セッションと自動応答モードが設定されたセッション手続及びメディア伝達手続にしたがう場合、受信側ＰｏＣクライアントの応答モードが自動で設定されていなければ（すなわち一時的な応答モードの変更に起因してサーバーと端末との間に設定された応答モードで異なる競争条件が発生する場合。競争条件とは、ＰｏＣサーバーのモードが時間遅延などに起因してＰｏＣクライアントのモードと異なる状態を意味する。例えば、ＰｏＣクライアントがＰｏＣサーバーのモードを自動応答モードから受動応答モードに変更することを要請する。この場合、ＰｏＣクライアントが要請した時刻からＰｏＣサーバーがＰｏＣクライアントの要請を反映して自身のモードを変更した時刻までの時間遅延を競争条件といえる）、受信側ＰｏＣクライアントが伝達されるメディアストリームを処理するための情報が得られないという問題点がある。

従って、本発明は、事前設定セッションに自動応答モードが設定されていて、受信側ＰｏＣクライアントの応答モード変更が反映されていない場合、伝達されるメディアストリームを受信端末で処理するために、ＰｏＣクライアントに応答モード情報を伝達することによって、ＰｏＣクライアントの変更された応答モードに即刻対応して呼処理が円滑に行われるＰｏＣシステムクライアントの応答モードに基盤する呼処理方法及びシステムを提供することを目的とする。

本発明の一態様によれば、受信側ＰｏＣクライアントと受信側ＰｏＣサーバーとの間にセッションがあらかじめ設定され、前記受信側ＰｏＣサーバーに自動応答モードが設定されているＰｏＣネットワークにおいての呼処理方法であって、前記方法は、前記受信側ＰｏＣサーバーが発信側ＰｏＣサーバーから転送される通話要請メッセージを受信する段階と、前記受信側ＰｏＣサーバーが通話要請メッセージに対する応答信号を伝達する段階と、前記受信側ＰｏＣクライアントにメディアストリームが転送されることを通知する情報を受信する段階と、を含む。

本発明の他の態様によれば、受信側ＰｏＣクライアントと受信側ＰｏＣサーバーとの間にセッションがあらかじめ設定され、前記受信側ＰｏＣサーバーに自動応答モードが設定されているＰｏＣネットワークにおいての呼処理システムであって、前記システムは、発信側ＰｏＣサーバーから転送される通話要請メッセージを受信し、前記通話要請メッセージに対する応答メッセージを伝達する前記受信側ＰｏＣサーバーと、前記受信側ＰｏＣサーバーからメディアストリームが受信されることを通知する情報を受信する前記受信側ＰｏＣクライアントと、を含む。

受信側ＰｏＣクライアントと受信側ＰｏＣサーバーが自動応答モードで作動し、セッションがあらかじめ設定された受信側ＰｏＣシステムで送信側ＰｏＣサーバーから通話連結要請メッセージを受信した場合、ＰＦが追加データを含む情報を受信側ＰｏＣクライアントに伝達する過程を提供する。したがって、自動応答モードでも、受信側ＰｏＣクライアントは、メディアストリームがまもなく受信されることが分かる。

本発明は、受信側ＰｏＣクライアントと受信側ＰｏＣサーバーが自動応答モードで作動し、事前設定セッションが設定された受信側ＰｏＣシステムが送信側ＰｏＣサーバーから通話連結要請メッセージを受信した場合、ＰＦが追加データを含む情報を受信側ＰｏＣクライアントに伝達する過程を開示する。したがって、自動応答モードでも、受信側ＰｏＣクライアントは、メディアストリームがまもなく受信されることが分かり、受信側ＰｏＣサーバーと受信側ＰｏＣクライアントとの応答モードが一致しなくても、前記ＰｏＣクライアントでＰｏＣ通話要請に対する呼処理を効果的に行うことができる。結果として、ネットワーク内の随伴されるシグナリングを低減し、速いＰｏＣ通話連結が維持される。ＰｏＣユーザは、向上したサービスを提供されることができ、サービス提供子も不要なメディアの転送を防止し、通信リソースを効率的に管理することができる。

特に、本発明はＰｏＣユーザの端末機とＰｏＣサーバーとの間の応答モードが同期化されない競争条件に影響を受けることなく具現されることができるシグナリング方法を提示し、端末機の作動に当該効果をもたらすことができる。

以下、添付の図面を参照して、本発明の属する分野における通常の知識を有する者が本発明を容易に実施できるように本発明の好ましい実施例を詳細に説明する。

図５を参照として、本発明によって提案される通話連結手続を説明する。図５は、事前設定セッションを有するクライアントに対して受信側ＰＦが自動応答モードで設定された場合、ＲＴＣＰメッセージを含むＰｏＣ通話連結処理手続を示す流れ図である。まず、制御ＰｏＣサーバーは、ＰｏＣ通話要請者のネットワークからＰｏＣ通話情報を含む通話要請メッセージを受信した後、制御ネットワークと受信側ホームネットワークのＳＩＰ／ＩＰコア網を経由して受信側ＰｏＣユーザのホームネットワークに属するＰｏＣサーバーに前記通話要請メッセージを伝達する（ステップ１〜３）。この時、前記参加ＰｏＣサーバーは、通話要請メッセージに含まれているＰｏＣ通話受信者に対するＰｏＣアドレス情報及びＰｏＣ通話要請者のＰｏＣアドレス情報を処理し、呼連結に利用する。一方、前記参加ＰｏＣサーバーは、受信側ＰｏＣクライアントのアドレス情報から該当ＰｏＣユーザとＰＦとの間に事前設定セッションが存在することが分かり、該当ＰｏＣユーザのモード設定によるＰｏＣクライアント応答モードを格納する。ここで、ＰＦ Ｂは、適切な内部処理手続を行い、前記通話要請メッセージに対するＯＫ応答を回答する（ステップ４〜６）。この時、前記ＯＫ応答は、ＩＭＳネットワークのルーティング規則によって通話要請メッセージを送った経路にルーティングされる。

ステップ４〜６の自動応答手続で、前記参加ＰｏＣサーバーは、自身と受信側ＰｏＣユーザ間のメディアパラメータのためにあらかじめ交渉しておいた事前設定セッションを利用し、ＰＦは、受信側ＰｏＣクライアントが許可されたＰｏＣ通話要請者からのセッション要請を自動で受諾することを予測し、ＯＫ応答を伝達する。

前述したＯＫ応答信号は、制御ネットワーク上のＰｏＣサーバー（制御ＰｏＣサーバー）に回答された後（ステップ６）、ＰｏＣ通話要請者のホームネットワークに伝達される（ステップ７）。前記ＯＫ応答信号は、ＰｏＣ通話送信側では受信側ＰｏＣユーザが直接通話を許諾したものと同様に認識され、通話要請者のＰｏＣクライアントまで回答されることによって、ダイアログが成立し、ＳＩＰ通話手続が完了する。一方、図２で説明したように、前記ＯＫ応答と発言権付与信号が制御ＰｏＣサーバーから送信側ＰｏＣクライアントに全て伝達された後（ステップ８）、制御ＰｏＣサーバーは、受信側ＰｏＣサーバーＰＦ Ｂを介してトークバースト転送信号を受信側ＰｏＣクライアントに伝達する（ステップ９、１０）。この場合、自動応答指示子を含むＲＴＣＰトークバーストメッセージは、ＰＦ Ｂで転送する。このように、前記トークバースト信号を用いて自動応答信号を転送することによって、転送負荷をもたらすことができる付加的なＳＩＰ信号（signaling）を除去する。次に、前記受信側ＰｏＣクライアントは、ＰｏＣサーバーで自動応答でＯＫ信号を受信し、メディアストリームがまもなく受信されることを知るようになる。最終的に、前記ＲＴＣＰトークバーストメッセージを通じて自動応答メッセージを受信した後、ＰｏＣクライアントは、続くメディア（例えば、音声信号）を受信する。前記トークバーストメッセージは、ＲＴＣＰメッセージにより具現されることができる。

一方、前記ＲＴＣＰトークバーストメッセージは、ＰＦがメディア経路に存在するかによってＰＦを経由することもでき、メディア経路に存在しない場合には、ＰｏＣクライアントに直接伝達されることもできる。前記メディア経路にＰＦ Ｂが含まれる場合、自動応答信号は、ＰＦ Ｂに含まれることができ（ステップ１０では不要である）、ＰＦ Ｂが含まれない場合、自動応答信号は、ＣＦに含まれなければならない（ステップ９、１０で必要である）。

本発明の他の実施例によれば、自動応答モードを示す前記ＲＴＣＰメッセージは、ＰｏＣ通話要請メッセージが送信側から受信側ＰＦに到達する時（図５でステップ３の直後）受信側ＰｏＣクライアントに伝達されることができる。このようなＰｏＣセッション連結手続が図６に示されている（図６でステップ１〜３、５〜７及び９、１０は、図５に示された通りであり、図６のステップ１１、１２でＲＴＣＰトークバースト転送メッセージは、応答モード指示子を含まない）。

前記送信側のＰｏＣセッション要請に応答して受信側ＰＦが自動応答を示す指示子をＲＴＣＰプロトコルを用いてＰｏＣクライアントＢに伝達した後、受信側ＰｏＣクライアントは、該当メディアストリームがまもなく受信されることを知るようになる（ステップ４）。応答受信に関係なく、前記受信側ＰｏＣサーバーは、ＯＫ応答信号を送信側ネットワークに伝達する（ステップ５）。一方、自動応答指示子を受信したクライアントは、自身の応答モードが受動モードであって、ＰＦの応答モードと一致しない場合、ＲＴＣＰメッセージを用いてエラー発生信号をＰＦに伝達する。前記ＰｏＣサーバーは、このようなエラー信号を受信することによって、転送されるメディアストリームを遮断し、メディアストリームが端末機まで転送されることを防止する。

図５で受信側ＰｏＣクライアントに伝達される応答モードを示すＲＴＣＰメッセージの構造は、例えば、図７のようなＲＴＣＰメッセージペイロード形態で具現されることができる。前記応答モード指示子を含むメッセージ情報からメディアストリームがまもなく受信されることが分かる。図７から明らかなように、前記ＲＴＣＰメッセージの構造は、バージョン情報、サブタイプ情報、長さ情報のような一般的な転送関連情報と、ＰｏＣユーザのアドレス情報、名前情報、トークバースト連結情報を必要とし、本発明で明記する自動応答指示子情報を含む。

図６で受信側ＰｏＣクライアントからＰＦに転送されるエラー応答ＲＴＣＰメッセージの構造は、例えば、図８のような形態で具現されることができる。図８から明らかなように、ＲＴＣＰパケットの構造は、バージョン情報、サブタイプ情報、長さ情報のような一般的なＲＴＣＰ転送関連情報、ＰｏＣユーザのアドレスと名前情報及び本発明で明記するセッション終了要請情報とエラーコード情報を含む。

一方、ＰＦで応答モードを示す方法として、前記自動応答を示すフィールド値がなければ、フィールド値を二進法で表記することができる（例えば、自動応答でauto-answer indication=1、受動応答でmanual-answer indication＝０）。

本発明の他の実施例によれば、自動応答指示子を含む手続は、前述したように、ＲＴＣＰ／ＲＴＰベアラーの経路に沿って前記制御ネットワークのＰｏＣサーバーまたは受信側ホームネットワークのＰｏＣサーバーが行うことができる。また、前記受信側ＰｏＣクライアントは、自動応答指示子を含む情報を受信側ＰｏＣサーバーから受信することによって、メディアストリームがまもなく受信されることが分かる。

事前設定セッションの用途によって前記ＰｏＣサーバーとクライアント間の経路及び追加資源予約が含まれることができるが、これは、本発明の主題から逸脱するので、具体的な説明は省略する。本発明で必要とする事前設定セッションに対する要求事項は、前記事前設定セッションの定義に影響を受けず、事前設定セッションの拡張された定義によって一層容易に実現されることができる。

本発明は、前記ＰｏＣシステムの様々な機能と特徴を考慮する時、発生する多様なＰｏＣ呼処理手続のうちＰｏＣ通話受信側に事前設定セッションが設定され、事前設定セッションに含まれるＰｏＣサーバーに自動応答モードが設定された場合、ＰｏＣ通話要請に対する呼処理を容易にするための方法を提案する。

一般的に自動応答モードは、受信側ＰｏＣクライアントがかかってくる通話を受動的な操作無しに直ちに応答し、メディアを伝達されるための速い呼処理を行うサービスである。

以上において説明した本発明は、本発明が属する技術の分野における通常の知識を有する者であれば、本発明の技術的思想を逸脱しない範囲内で、様々な置換、変形及び変更が可能であるので、上述した実施例及び添付された図面に限定されるものではない。

従来のＰｏＣサービスシステムのブロック図である。 自動応答モードで従来の送信側ＰｏＣ通話連結手続を示す流れ図である。 自動応答モードで従来の受信側ＰｏＣ通話連結手続を示す流れ図である。 ＰｏＣ通話要請のために送信者により転送されるＩＮＶＩＴＥ要請に含まれる情報を示す表である。 本発明の第１実施例に係るＲＴＣＰメッセージを含むＰｏＣ通話連結処理手続を示す流れ図である。 本発明の第２実施例に係るＲＴＣＰメッセージを含むＰｏＣ通話連結手続に関する流れ図である。 自動応答指示子を含むＲＴＣＰメッセージがペイロード形式を示す図である。 受信クライアントで自動応答モード拒否時に転送されるＲＴＣＰペイロード形式を示す図である。

符号の説明

１０ ＰｏＣクライアント
２０ アクセス網
３０ ＳＩＰ／ＩＰコア網
４０ ＧＬＭＳマネジャー
５０ ＧＬＭＳ
６０ ＰｏＣサーバ
７０ プレゼンスサーバ
８０ 遠隔ＰｏＣネットワーク

Claims (36)

1. 受信側ＰｏＣクライアントと受信側ＰｏＣサーバーとの間にセッションがあらかじめ設定され、前記受信側ＰｏＣサーバーに自動応答モードが設定されているＰｏＣネットワークにおいての呼処理方法であって、
   前記受信側ＰｏＣサーバーが、発信側ＰｏＣサーバーから転送される通話要請メッセージを受信する段階と、
   前記受信側ＰｏＣサーバーが、通話要請メッセージに対応する応答信号を伝達する段階と、
   前記受信側ＰｏＣクライアントにメディアストリームが転送されることを通知する情報を受信する段階と、を含むことを特徴とする呼処理方法。
2. 前記メディアストリームが転送されることを通知する情報は、ＲＴＣＰ（Real-time Transport Control Protocol）ペイロードで具現されることを特徴とする請求項１に記載の呼処理方法。
3. 前記メディアストリームが転送されることを通知する情報は、送信側ＰｏＣクライアントのアドレス及び名前を含むことを特徴とする請求項１に記載の呼処理方法。
4. 前記メディアストリームが転送されることを通知する情報は、受動応答無視（ＭＡＯ：Manual Answer Override）指示子に関する情報をさらに含むことを特徴とする請求項３に記載の呼処理方法。
5. 前記メディアストリームが転送されることを通知する情報は、バージョン情報、サブタイプ情報、長さ情報及び自動応答指示子情報の中から少なくとも１つをさらに含むことを特徴とする請求項３に記載の呼処理方法。
6. 前記受信側ＰｏＣクライアントの応答モードが受信側ＰｏＣサーバーの応答モードと一致しない場合、受信側ＰｏＣサーバーにエラー信号を転送する段階をさらに含むことを特徴とする請求項１に記載の呼処理方法。
7. 前記エラー信号は、ＲＴＣＰ（Real-time Transport Control Protocol）ペイロードで具現されることを特徴とする請求項６に記載の呼処理方法。
8. 前記エラー信号は、セッション終了要請及びエラーコードを含むことを特徴とする請求項６に記載の呼処理方法。
9. 前記エラー信号は、バージョン情報、サブタイプ情報、長さ情報及びＰｏＣクライアントのアドレスと名前の中から少なくとも１つをさらに含むことを特徴とする請求項６に記載の呼処理方法。
10. 受信側ＰｏＣクライアントと受信側ＰｏＣサーバーとの間にセッションがあらかじめ設定され、前記受信側ＰｏＣサーバーに自動応答モードが設定されているＰｏＣネットワークにおいての呼処理システムであって、
    発信側ＰｏＣサーバーから転送される通話要請メッセージを受信し、前記通話要請メッセージに対応する応答メッセージを伝達する前記受信側ＰｏＣサーバーと、
    前記受信側ＰｏＣサーバーからメディアストリームが受信されることを通知する情報を受信する前記受信側ＰｏＣクライアントと、を含むことを特徴とする呼処理システム。
11. 前記メディアストリームが受信されることを通知する情報は、ＲＴＣＰ（Real-time Transport Control Protocol）ペイロードで具現されることを特徴とする請求項１０に記載の呼処理システム。
12. 前記メディアストリームが受信されることを通知する情報は、発信側ＰｏＣクライアントのアドレスと名前を含むことを特徴とする請求項１０に記載の呼処理システム。
13. 前記メディアストリームが受信されることを通知する情報は、受動応答無視（ＭＡＯ：Manual Answer Override）指示子に関する情報をさらに含むことを特徴とする請求項１２に記載の呼処理システム。
14. 前記メディアストリームが受信されることを通知する情報は、バージョン情報、サブタイプ情報、長さ情報及び自動応答指示子情報の中から少なくとも１つをさらに含むことを特徴とする請求項１２に記載の呼処理システム。
15. 前記受信側ＰｏＣクライアントの応答モードが受信側ＰｏＣサーバーの応答モードと一致しない場合、エラー信号が受信側ＰｏＣサーバーに転送されることを特徴とする請求項１０に記載の呼処理システム。
16. 前記エラー信号は、ＲＴＣＰ（Real-time Transport Control Protocol）ペイロードで具現されることを特徴とする請求項１５に記載の呼処理システム。
17. 前記エラー信号は、セッション終了要請及びエラーコードを含むことを特徴とする請求項１５に記載の呼処理システム。
18. 前記エラー信号は、バージョン情報、サブタイプ情報、長さ情報及びＰｏＣクライアントのアドレスと名前の中から少なくとも１つをさらに含むことを特徴とする請求項１５に記載の呼処理システム。
19. ＰｏＣネットワークでＰｏＣクライアントにより行われる呼処理方法であって、
    ＰｏＣクライアントがＰｏＣサーバーと事前設定セッションを設定する段階と、
    前記ＰｏＣサーバーに自動応答モードを設定する段階と、
    通話要請メッセージを受信した前記ＰｏＣサーバーからメディアストリームが受信されることを通知する情報を受信する段階と、を含むことを特徴とする呼処理方法。
20. 前記メディアストリームが受信されることを通知する情報は、ＲＴＣＰ（Real-time Transport Control Protocol）ペイロードで受信されることを特徴とする請求項１９に記載の呼処理方法。
21. 前記メディアストリームが受信されることを通知する情報は、発信側ＰｏＣユーザのアドレス及び名前を含むことを特徴とする請求項１９に記載の呼処理方法。
22. 前記メディアストリームが受信されることを通知する情報は、受動応答無視（ＭＡＯ：Manual Answer Override）指示子に関する情報をさらに含むことを特徴とする請求項２１に記載の呼処理方法。
23. 前記メディアストリームが受信されることを通知する情報は、バージョン情報、サブタイプ情報、長さ情報及び自動応答指示子情報の中から少なくとも１つをさらに含むことを特徴とする請求項２１に記載の呼処理方法。
24. 前記受信側ＰｏＣクライアントの応答モードが受信側ＰｏＣサーバーの応答モードと一致しない場合、受信側ＰｏＣサーバーにエラー信号を転送する段階をさらに含むことを特徴とする請求項１９に記載の呼処理方法。
25. 前記エラー信号は、ＲＴＣＰ（Real-time Transport Control Protocol）ペイロードで転送されることを特徴とする請求項１９に記載の呼処理方法。
26. 前記エラー信号は、セッション終了要請及びエラーコードを含むことを特徴とする請求項２４に記載の呼処理方法。
27. 前記エラー信号は、バージョン情報、サブタイプ情報、長さ情報及びＰｏＣクライアントのアドレスと名前の中から少なくとも１つをさらに含むことを特徴とする請求項２４に記載の呼処理方法。
28. ＰｏＣネットワークで呼処理を行うＰｏＣクライアントであって、
    受信側ＰｏＣサーバーと事前設定セッションを設定し、前記受信側ＰｏＣサーバーと自動応答モードを設定し、通話要請メッセージを受信した前記ＰｏＣサーバーからメディアストリームが受信されることを通知する情報を受信することを特徴とするＰｏＣクライアント。
29. 前記メディアストリームが受信されることを通知する情報は、ＲＴＣＰ（Real-time Transport Control Protocol）ペイロードで具現されることを特徴とする請求項２８に記載のＰｏＣクライアント。
30. 前記メディアストリームが受信されることを通知する情報は、送信側ＰｏＣユーザのアドレス及び名前を含むことを特徴とする請求項２８に記載のＰｏＣクライアント。
31. 前記メディアストリームが受信されることを通知する情報は、受動応答無視（ＭＡＯ：Manual Answer Override）指示子に関する情報をさらに含むことを特徴とする請求項２８に記載のＰｏＣクライアント。
32. 前記メディアストリームが受信されることを通知する情報は、バージョン情報、サブタイプ情報、長さ情報及び自動応答指示子情報の中から少なくとも１つをさらに含むことを特徴とする請求項２８に記載のＰｏＣクライアント。
33. 前記受信側ＰｏＣクライアントの応答モードが受信側ＰｏＣサーバーの応答モードと一致しない場合、受信側ＰｏＣサーバーにエラー信号が転送されることを特徴とする請求項２８に記載のＰｏＣクライアント。
34. 前記エラー信号は、ＲＴＣＰ（Real-time Transport Control Protocol）ペイロードで具現されることを特徴とする請求項３３に記載のＰｏＣクライアント。
35. 前記エラー信号は、セッション終了要請及びエラーコードを含むことを特徴とする請求項３３に記載のＰｏＣクライアント。
36. 前記エラー信号は、バージョン情報、サブタイプ情報、長さ情報及びＰｏＣユーザのアドレスと名前の中から少なくとも１つをさらに含むことを特徴とする請求項３４に記載のＰｏＣクライアント。

Images