JP2010503309A - Ｐｔサービスにおける発言権制御方法及び装置 - Google Patents

Abstract

本発明は、ＰＴ（例えば、Ｐｕｓｈ−Ｔｏ−Ｔａｌｋ、Ｐｕｓｈ−Ｔｏ−Ｖｉｅｗ、又はＰｕｓｈ−Ｔｏ−Ｄａｔａ）サービスに関し、特に、ＰＴサービスにおける発言権（ｆｌｏｏｒ、ｔａｌｋ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ、ｐｅｒｍｉｓｓｉｏｎ ｔｏ ｓｅｎｄ ｍｅｄｉａ ｂｕｒｓｔなど）制御方法及び装置に関する。一実施形態によれば、ＰＴサーバの状態制御方法は、第２状態のＰＴサーバが、メディアバースト解除メッセージを受信すると第１状態に遷移する段階と、前記第１状態のＰＴサーバがＰＴクライアントからメディアパケットを受信した場合、及び以前の前記第２状態のＰＴサーバが前記メディアバースト解除メッセージを受信した場合、前記ＰＴサーバが前記第１状態を維持する段階とを含む。

Description

本願は、２００６年１０月１８日に出願された米国仮出願第６０／８５２，４１２号、及び２００７年６月２５日に大韓民国に出願された韓国出願第１０−２００７−００６２４２９号の優先権を主張するものであり、これらの全ての内容は参照によりここに援用される。

本発明は、ＰＴ（Ｐｕｓｈ−Ｔｏ）（例えば、ＰＴＴ（Ｐｕｓｈ−Ｔｏ−Ｔａｌｋ）、ＰＴＶ（Ｐｕｓｈ−Ｔｏ−Ｖｉｅｗ）、ＰＴＤ（Ｐｕｓｈ−Ｔｏ−Ｄａｔａ））サービスに関し、特に、ＰＴサービスにおける発言権（ｆｌｏｏｒ、ｔａｌｋ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ、ｍｅｄｉａ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ、又はメディアバースト送信権限（ｐｅｒｍｉｓｓｉｏｎ ｔｏ ｓｅｎｄ ｍｅｄｉａ ｂｕｒｓｔ）など）制御方法及び装置に関する。

ＰＴサービスは、音声（オーディオ）データを送信して通話サービスを提供するためのＰＴＴ、画像（ビデオ）データを送信するためのＰＴＶ、各種データ送信のためのＰＴＤなどのように、一種の半二重通信（ｈａｌｆ ｄｕｐｌｅｘ ｃｏｍｍｕｎｉｃａｔｉｏｎ）サービスである。ＰＴサービスにおいてサーバを介して設定されたセッションに参加したクライアントのうち、発言権（ｔａｌｋ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ、ｍｅｄｉａ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ、ｆｌｏｏｒ）又はメディアバースト送信権限を有する１つのクライアントは、オーディオ又はビデオを含むメディアデータ（例えば、トークバースト（ｔａｌｋ ｂｕｒｓｔ）又はメディアバースト（ｍｅｄｉａ ｂｕｒｓｔ））を送信し、前記セッションに参加した残りのクライアントは、前記送信されたメディアデータを受信する。

ＰＴサービスにおけるＰＴクライアントは、ダイヤル作業、電話接続のための待機、電話呼出音の提供などの手順を行うことなく、複数の異なるＰＴクライアントと通信を行うので、一般的な移動通信端末に比べて速い通信を提供することができる。また、ＰＴサービスは、ユーザの音声とデータを、１人の受信者（１対１）、又はグループチャットセッションのように複数の受信者（１対多）に送信することができる。

従来のＰＴサービスは、特定のクライアントが少なくとも１つの他のクライアントを選択してこれらをＰＴセッションに招待する過程と、前記招待するクライアント（発信クライアント）と前記招待されるクライアント（着信クライアント）間にセッションを設定する過程と、前記セッションが設定されたクライアントの間で音声（オーディオ）及び／又はその他のデータを送受信する過程とを含む。

ＰＴサービスにおいて、ユーザがユーザのＰＴ端末によりオーディオ、ビデオ、又はその他のデータなどのメディアデータを送信する前に、前記ユーザは、メディアデータ送信権限（又は、発言権（ｔａｌｋ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ、ｍｅｄｉａ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ、ｆｌｏｏｒ）、以下「発言権（ｍｅｄｉａ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ）」という）をＰＴサーバ（例えば、ＰｏＣ（Ｐｕｓｈ ｔｏ Ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ）サーバ）に要求しなければならない。前記ユーザは、前記ＰＴサーバから発言権が付与（ｇｒａｎｔ）されると、メディアデータを送信することができる。このように、ユーザ端末の発言権を制御することを、発言権制御（Ｔａｌｋ Ｂｕｒｓｔ ＣｏｎｔｒｏｌもしくはＭｅｄｉａ Ｂｕｒｓｔ Ｃｏｎｔｒｏｌ）という。また、このような発言権制御において、発言権を取得した特定のユーザが通信チャネルでメディアデータを送信することを制限することができるが、このような機能を「発言権取消（Ｔａｌｋ Ｂｕｒｓｔ Ｒｅｖｏｋｅ）」という。

図１は、従来のＰＴクライアントへのメディアバースト動作についての（ＰＴサーバ面での）ＰＴサーバの状態遷移図（状態マシン図）である。図１は、ＰＴクライアント（すなわち、端末）へのメディアバースト（もしくは、トークバースト）動作についてのＰＴサーバの各状態を示す図である。図１で楕円内に示す状態は、各状態の性質によって安定状態（ｓｔａｂｌｅ ｓｔａｔｅ）と遷移状態（ｔｒａｎｓｉｔｉｏｎ ｓｔａｔｅ）とに分類される。イベントは図１でボックスで示している。

図１に示す関連状態を説明すると次の通りである。

（ａ）「Ｓｔａｒｔ−ｓｔｏｐ」状態は、ＰＴサーバと関連ＰＴクライアント間にＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）セッションが存在しない状態である。以下、「Ｓｔａｒｔ−ｓｔｏｐ」状態を「第０（ゼロ）状態」という。

（ｂ）「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ａｎｄ ＭＢ−Ｉｄｌｅ」状態は、安定状態であって、ＰＴサーバがＰＴクライアントから発言権要求を受けることのできる状態である。すなわち、ＰＴクライアントがメディアバーストをＰＴサーバに送信するために発言権要求（これをＭＢ＿Ｒｅｑｕｅｓｔという）を送信することのできる状態である。以下、「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ａｎｄ ＭＢ−Ｉｄｌｅ」状態を「第１状態」という。

（ｃ）「Ｕ：ｐｅｒｍｉｔｔｅｄ」状態は、安定状態であって、ＰＴサーバが関連ＰＴクライアントにメディアバースト送信権限を付与し、前記関連ＰＴクライアントがメディアバーストを前記ＰＴサーバに送信することのできる状態である。以下、「Ｕ：ｐｅｒｍｉｔｔｅｄ」状態を「第２状態」という。この状態で、前記ＰＴサーバは、Ｔ１タイマ（すなわち、Ｅｎｄ ｏｆ ＲＴＰ Ｍｅｄｉａ ｔｉｍｅｒ）及びＴ２タイマ（すなわち、Ｓｔｏｐ ｔａｌｋｉｎｇ ｔｉｍｅｒ）を作動（スタート）させる。これらのタイマについては後述する。

（ｄ）「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ｂｕｔ ｓｅｎｄｓ ｍｅｄｉａ」状態は、遷移状態であって、ＰＴサーバが発言権を有しないＰＴクライアントからメディアデータ（又は、ＲＴＰメディアパケット）を受信する状態である。以下、「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ｂｕｔ ｓｅｎｄｓ ｍｅｄｉａ」状態を「第３状態」という。この状態で、前記ＰＴサーバは、Ｔ８タイマ（すなわち、Ｍｅｄｉａ Ｂｕｒｓｔ Ｒｅｖｏｋｅ ｔｉｍｅｒ）を作動（スタート）させる。

（ｅ）「Ｕ：ｐｅｎｄｉｎｇ ＭＢ＿Ｒｅｖｏｋｅ」状態は、遷移状態であって、ＰＴサーバがＭＢＣＰ（Ｍｅｄｉａ Ｂｕｒｓｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）メディアバースト取消（Ｍｅｄｉａ Ｂｕｒｓｔ Ｒｅｖｏｋｅ）メッセージを送信した後、猶予期間（ｇｒａｃｅ ｐｅｒｉｏｄ）中にこの状態を利用する。以下、「Ｕ：ｐｅｎｄｉｎｇ ＭＢ＿Ｒｅｖｏｋｅ」状態を「第４状態」という。この状態で、前記ＰＴサーバは、Ｔ３タイマ（すなわち、Ｓｔａｒｔ ｔａｌｋｉｎｇ ｇｒａｃｅ ｔｉｍｅｒ）を作動（スタート）させ、そのＴ３タイマが作動する期間が前記猶予期間に該当する。

（ｆ）「Ｕ：ｗａｉｔｉｎｇ ＭＢ＿Ｒｅｖｏｋｅ」状態は、安定状態であって、Ｔ９タイマが作動する所定期間、ＰＴサーバが関連ＰＴクライアントにより要求されたメディアバースト送信権限を付与しない状態である。前記関連ＰＴクライアントがメディアバースト送信権限期間（すなわち、Ｔ２タイマが満了するまで作動する期間）を超えてメディアデータを送信し続ける場合に、前記ＰＴサーバは前記関連ＰＴクライアントにペナルティを課す。この状態で、前記ＰＴサーバは、Ｔ９タイマ（すなわち、Ｒｅｔｒｙ−ａｆｔｅｒ ｔｉｍｅｒ）を作動（スタート）させる。以下、このような「Ｕ：ｗａｉｔｉｎｇ ＭＢ＿Ｒｅｖｏｋｅ」状態を「第５状態」という。

（ｇ）「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ＭＢ＿Ｔａｋｅｎ」状態は、安定状態であって、メディアバースト送信権限を取得した関連ＰＴクライアント以外の他のＰＴクライアント（すなわち、関連のないＰＴクライアント）がメディアバースト送信権限を要求する場合に、ＰＴサーバが前記他のＰＴクライアントにメディアバースト送信権限が既に取得されていることを通知する状態である。以下、このような「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ＭＢ＿Ｔａｋｅｎ」状態を「第６状態」という。

図１の説明で紹介されたＴ１タイマ、Ｔ２、Ｔ３、Ｔ８、及びＴ９は、ＰＴサーバと関連ＰＴクライアント間のメディアバースト（Ｍｅｄｉａ Ｂｕｒｓｔ；ＭＢ）の送信を制限又は制御するために使用される。以下、このようなタイマの動作を説明する。一般に、ＰＴクライアントからＰＴサーバに送信されるメディアデータは、ＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）パケットフォーマットで送信される。

Ｔ１タイマ（Ｅｎｄ ｏｆ ＲＴＰ Ｍｅｄｉａ ｔｉｍｅｒ）
Ｔ１タイマは、ＰＴサーバが以前のＲＴＰパケットを受信した後、有効期間内に次のＲＴＰパケットを受信したか否かをカウントするタイマである。通常、Ｔ１タイマはデフォルトで４秒に設定される。端末がメディアデータ、すなわちＲＴＰメディアパケットをＰＴサーバに送信した後、前記ＰＴサーバが最初のＲＴＰパケットを受信すると、Ｔ１タイマが作動し、次のＲＴＰパケットを受信する毎に再作動する。前記ＰＴサーバが最後のＲＴＰパケットを受信すると、Ｔ１タイマは停止又は満了する。

Ｔ２タイマ（Ｓｔｏｐ ｔａｌｋｉｎｇ ｔｉｍｅｒ）
Ｔ２タイマは、メディアバースト送信権限（発言権）を有する端末がメディアデータを送信することのできる許容（有効）期間をカウントするタイマである。端末が最初のＲＴＰパケットを送信するときに、ＰＴサーバがＴ２タイマを作動させる。通常、Ｔ２タイマはデフォルトで３０秒に設定される。

Ｔ３タイマ（Ｓｔｏｐ ｔａｌｋｉｎｇ ｇｒａｃｅ ｔｉｍｅｒ）
Ｔ３タイマは、Ｔ２タイマが満了した後も、ＰＴサーバがメディアデータをさらに受信することのできる猶予期間をカウントするタイマである。ここで、前記猶予期間とは、Ｔ２タイマが満了した後もＰＴサーバがメディアデータを受信することができるようにする一種の限界超過時間（ｍａｒｇｉｎａｌ ｅｘｃｅｓｓ ｔｉｍｅ）をいう。すなわち、メディアデータ送信権限を有する端末が、メディアデータの送信のために前記端末に許容される期間が経過した後にメディアデータを送信したとしても、前記ＰＴサーバは、Ｔ３タイマの設定期間の間、すなわちＴ３タイマが満了するまで、前記端末から受信したメディアデータを許容する。

Ｔ９タイマ（Ｒｅｔｒｙ−ａｆｔｅｒ ｔｉｍｅｒ）
Ｔ９タイマは、端末が許可された期間を超えてメディアデータを送信するとき、前記端末がＰＴサーバに発言権（ｍｅｄｉａ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ）を要求できないように前記端末に課されたペナルティ時間をカウントするタイマである。前記端末がＴ２タイマに設定された値（期間）を超えて（すなわち、メディアデータの送信のために許容される期間後に）メディアデータを送信する場合、前記ＰＴサーバは、前記端末にＭＢＣＰ取消メッセージ（ＭＢＣＰ Ｒｅｖｏｋｅ ｍｅｓｓａｇｅ）又はＴＢＣＰ取消メッセージ（ＴＢＣＰ Ｒｅｖｏｋｅ ｍｅｓｓａｇｅ）を送信した後、Ｔ３タイマを作動させる。前記ＰＴサーバは、Ｔ３タイマに設定された時間の間に、前記端末からＭＢＣＰ解除メッセージ又はＴＢＣＰ解除メッセージを受信していない場合、Ｔ９タイマを作動させ、Ｔ９タイマに設定された時間値に該当する所定期間（すなわち、Ｔ９タイマの作動期間）、前記端末が発言権を要求してメディアデータを送信することができないようにする。

Ｔ８タイマ（Ｔａｌｋ Ｂｕｒｓｔ Ｒｅｖｏｋｅ ｔｉｍｅｒ）
Ｔ８タイマは、ＰＴサーバがＭＢ＿Ｒｅｖｏｋｅメッセージを送信する時点で作動させるタイマである。前記ＰＴサーバは、端末がＴ８タイマに設定された値（すなわち、期間）内にＭＢ＿Ｒｅｌｅａｓｅメッセージを送信しないと、再びＴ８タイマを作動させ、前記端末が送信するＭＢ＿Ｒｅｌｅａｓｅメッセージの受信を待つ。

図２は、従来のＰＴサーバと端末間のメディアバースト送信権限の取得及びメディアデータの送信を示す信号フロー図である。

以下、図１及び図２を参照して説明する。ここで、図１におけるＰＴサーバの第０状態でＳＩＰセッションが開始され、前記ＰＴサーバは各端末（ＰＴクライアント装置）にＭＢ＿Ｉｄｌｅメッセージを送信して第１状態に遷移（変化）したと前提する。すなわち、前記ＰＴサーバは、前記各端末が前記ＰＴサーバにメディアバースト送信権限（すなわち、発言権（ｍｅｄｉａ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ））を要求できる状態にある。

端末Ａ、Ｂ、及びＣのそれぞれは、発言権（ｆｌｏｏｒ、ｍｅｄｉａ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ、ｔａｌｋ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ）又はメディアバースト送信権限を要求するメッセージ（すなわち、ＭＢ＿Ｒｅｑｕｅｓｔ）をＰＴサーバに送信する（Ｓ１）。ＰＴサーバが端末Ａにメディアバースト送信権限を付与すると決定した場合、ＰＴサーバは、端末ＡのＭＢ＿Ｒｅｑｕｅｓｔメッセージに対する応答として、ＭＢ＿Ｇｒａｎｔｅｄメッセージを端末Ａに送信する。一方、ＰＴサーバは、端末Ｂ及びＣには、メディアバースト送信権限が端末Ａに付与されたことを示すメッセージ（すなわち、ＭＢ＿Ｔａｋｅｎ）を送信する（Ｓ２）。前記ステップＳ１及びＳ２により、端末Ａに対するＰＴサーバの動作状態は、図１に示すように、第１状態から第２状態（すなわち「Ｕ：ｐｅｒｍｉｔｔｅｄ」）に遷移する。従って、端末Ａは、Ｔ２タイマに設定された期間の間（すなわち、Ｔ２タイマの動作期間の間）、メディアデータ（又は、ＲＴＰメディアパケット）をＰＴサーバに送信することができる。また、前記ステップＳ１及びＳ２により、端末Ｂ及びＣはＭＢ＿Ｔａｋｅｎメッセージを受信した状態になるので、端末Ｂ及びＣに対するＰＴサーバの動作状態は、図１に示すように、第６状態（すなわち、「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ａｎｄ ＭＢ＿Ｔａｋｅｎ」）に該当する。

図１における端末Ａに対するＰＴサーバの状態は第２状態（すなわち、「Ｕ：ｐｅｒｍｉｔｔｅｄ」状態）に該当するので、端末Ａは、メディアデータ（ＲＴＰメディアパケット）をＰＴサーバに送信することができる（Ｓ３）。ここで、ＰＴサーバは、端末Ａから送信された最初のＲＴＰメディアパケットを受信すると、Ｔ１タイマとＴ２タイマを同時に作動させることができる。

端末Ａにメディアデータ送信が許容される期間（すなわち、Ｔ２タイマに設定された値（期間））内に、端末Ａがメディアバースト送信権限の解除のためのメッセージ（すなわち、ＭＢ＿Ｒｅｌｅａｓｅメッセージ）を送信すると、端末Ａに対するＰＴサーバの状態は、図１に示すように、第２状態から第１状態に遷移する。また、ＰＴサーバは、作動中のＴ２タイマを停止する（すなわち、Ｔ２タイマは満了前に停止する）。しかし、前記端末Ａにメディアデータ送信が許容される期間（すなわち、Ｔ２タイマに設定された値（期間））が満了すると、ＰＴサーバは、メディアバースト送信権限を取り消すためのメッセージ（すなわち、ＭＢ＿Ｒｅｖｏｋｅメッセージ）を端末Ａに送信する。

一般に、端末からのメッセージ及びメディアデータ（又は、ＲＴＰメディアパケット）は、物理的な通信環境下で異なるネットワークルーティング経路で送信される。ところが、このような物理的な通信環境においては、異なるネットワークルーティング経路でのメッセージ及びメディアデータの受信中に、送信遅延（遷移遅延）を伴うことがある。また、このような状況により、前記端末に対するＰＴサーバの現在の状態が、意図せずに図１の状態マシン図の第３状態（例えば、「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ｂｕｔ ｓｅｎｄｓ ｍｅｄｉａ」）になることがある。

例えば、ＰＴサーバが第２状態にあり、端末からＭＢ＿Ｒｅｌｅａｓｅメッセージを受信した場合、ＰＴサーバは、第２状態から第１状態に遷移する。その後、ＰＴサーバが、端末により前記ＭＢ＿Ｒｅｌｅａｓｅメッセージよりも先に送信されたがルーティング経路の遅延でより遅くＰＴサーバに到着したメディアデータ（ＲＴＰパケット）を受信した場合、前記ＰＴサーバは、図１に示すように、第１状態から第３状態に遷移する。しかし、第３状態では端末がＰＴサーバにメディアバースト送信権限を要求することができず、ＰＴサーバは端末がメディアバースト送信権限を要求できるようにするために第１状態に戻らなければならないため、第３状態は現在望ましい状態ではない。さらに、ＰＴサーバはその時期に第１状態に戻ることもできない。なぜならば、そうするためには、ＰＴサーバは、その時期に発生しそうにない他のＭＢ＿Ｒｅｌｅａｓｅメッセージの受信を行わなければならないからである。その結果、従来の図１の状態マシン図による端末は、ＰＴサーバにメディアバースト送信権限を要求できない望まない状態（すなわち、第３状態）に継続して留まることになるという問題がある。

例えば、端末がＲＴＰメディアパケットとＭＢ＿Ｒｅｌｅａｓｅメッセージを順次送信した場合、前記ＲＴＰメディアパケットよりも前記ＭＢ＿Ｒｅｌｅａｓｅメッセージが先にＰＴサーバに到着することもあり、その逆もあるであろう。この場合、ＰＴサーバは、前記ＭＢ＿Ｒｅｌｅａｓｅメッセージを所定のネットワークルーティング経路で受信した後、他のネットワークルーティング経路で前記ＲＴＰメディアパケットの一部（例えば、端末が送信した前記ＲＴＰメディアパケットのうち、最後又は他のＲＴＰメディアパケット）を受信することができる。ここで、ＰＴサーバが前記ＭＢ＿Ｒｅｌｅａｓｅメッセージを既に受信したので、図１の状態図における端末に対するＰＴサーバの状態は、第２状態（すなわち、「Ｕ：ｐｅｒｍｉｔｔｅｄ」）から第１状態（すなわち、「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ａｎｄ ＭＢ＿ｉｄｌｅ」）に遷移する。その後、ＰＴサーバが最後のＲＴＰメディアパケットを受信した場合も、前記受信した最後のＲＴＰメディアパケットが前記既に受信したＭＢ＿Ｒｅｌｅａｓｅメッセージよりも先に送信されたことを認識することができない。これにより、ＰＴサーバは、メディアバースト送信権限のない端末がメディアデータ（すなわち、前記受信した最後のＲＴＰメディアパケット）を送信したと判断する。従って、ＰＴサーバは、前記受信した最後のＲＴＰメディアパケットを廃棄し、（前記端末に付与されたメディアバースト送信権限が取り消されたことを示す）ＭＢ＿Ｒｅｖｏｋｅメッセージを前記端末に送信する（すなわち、これは図１の「状況１」に該当する）。すなわち、従来の図１の状態図における前記端末に対するＰＴサーバの状態は、第１状態（すなわち、「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ａｎｄ ＭＢ＿Ｉｄｌｅ」）から第３状態（すなわち、「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ｂｕｔ ｓｅｎｄｓ ｍｅｄｉａ」）に変化する。図１の第３状態で、ＰＴサーバは、ＭＢ＿Ｒｅｖｏｋｅメッセージを端末に送信すると共に、Ｔ８タイマを作動させる（すなわち、これは図１の「状況２」に該当する）。しかしながら、このような状況２はＰＴサーバが端末からＭＢ＿Ｒｅｌｅａｓｅメッセージを受信するまで繰り返され、端末に対するＰＴサーバの状態は図１の状態マシン図の第３状態を維持する。状況２が繰り返される場合、端末は、前記ＭＢ＿Ｒｅｌｅａｓｅメッセージを既に送信したにもかかわらず、ＰＴサーバに発言権を要求できない不利益を受けることがある。これは、端末が送信したメッセージのネットワークルーティング経路が異なるために発生し得る問題である。

また、端末が送信したメッセージのネットワークルーティング経路が異なるため、その結果として、端末は、意図せずに図１の状態図における第５状態（すなわち、Ｕ：ｗａｉｔｉｎｇ ＭＢ＿Ｒｅｖｏｋｅ）に至ることがある。すなわち、端末（又は、ＰＴクライアント）は、メディアバースト送信権限を取得した後、メディアデータ送信が許可される期間（すなわち、Ｔ２タイマの設定値に該当する期間）中に、メディアデータ（すなわち、一連のＲＴＰメディアパケット）をＰＴサーバに送信することができる。場合によっては、端末が送信した一連のＲＴＰメディアパケットはシーケンス番号を含む。また、最後のＲＴＰメディアパケットのシーケンス番号に関する情報は、ＭＢ＿Ｒｅｌｅａｓｅメッセージに含まれることもある。

端末がＴ２タイマの設定期間（例えば、「３０秒」）内に一連のＲＴＰメディアパケット（すなわち、メディアデータ）とＭＢ＿ＲｅｌｅａｓｅメッセージをＰＴサーバに順次送信したとしても、前記メッセージ（すなわち、ＲＴＰメディアパケット及びＭＢ＿Ｒｅｌｅａｓｅメッセージ）のネットワークルーティング経路が異なるため、順次送信される前記メッセージと比べて、ＰＴサーバの受信が非順次となることがある。例えば、ＲＴＰメディアパケットとＭＢ＿Ｒｅｌｅａｓｅメッセージが順次送信される場合、前記ＲＴＰメディアパケットよりも前記ＭＢ＿Ｒｅｌｅａｓｅメッセージが先にＰＴサーバに到着することがある。すなわち、ＰＴサーバは端末が送信した前記ＭＢ＿Ｒｅｌｅａｓｅメッセージを受信した後、前記ＲＴＰメディアパケットの一部（例えば、端末が送信したＲＴＰメディアパケットのうち、最後のＲＴＰメディアパケット）を受信することがある。ここで、ＰＴサーバは、前記ＭＢ＿Ｒｅｌｅａｓｅメッセージに含まれる最後のＲＴＰメディアパケットのシーケンス番号に関する情報を確認（すなわち、検索及び分析）した後、前記最後のＲＴＰメディアパケットを受信するまで待つ。すなわち、端末に対するＰＴサーバの状態は、図１の第２状態（すなわち、「Ｕ：ｐｅｒｍｉｔｔｅｄ」状態）を継続して維持する。しかし、ＰＴサーバが前記最後のＲＴＰメディアパケットの受信を待っているときにＴ２タイマが満了すると、ＰＴサーバは端末にＭＢ＿Ｒｅｖｏｋｅメッセージを送信する（すなわち、これは図１の状況３に該当する）。ここで、端末に対するＰＴサーバの状態は、第２状態から第４状態（すなわち、「Ｕ：ｐｅｎｄｉｎｇ ＭＢ＿Ｒｅｖｏｋｅ」状態）に遷移する。その後、前記最後のＲＴＰメディアパケットを受信すると、ＰＴサーバは、前記受信した最後のＲＴＰメディアパケットを、メディアデータの送信のために許容される期間（すなわち、Ｔ２タイマの設定期間）内に到着していない無効の（許容されていない）パケットとみなし、前記端末にペナルティを課す。従って、端末に対するＰＴサーバの状態は、第４状態から第５状態（すなわち、「Ｕ：ｗａｉｔｉｎｇ ＭＢ＿Ｒｅｖｏｋｅ」状態）、すなわち端末がペナルティを受ける状態に遷移する。すなわち、第５状態で端末は、ペナルティが課される期間（すなわち、Ｔ９タイマの設定値に該当する期間）中はＰＴサーバに発言権（ｍｅｄｉａ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ）を要求することができない。

従って、端末がメディアデータの送信のために許容される期間（すなわち、Ｔ２タイマに設定された期間）（例えば、３０秒）内にＲＴＰメディアパケット（メディアデータ）とＭＢ＿Ｒｅｌｅａｓｅメッセージを順次送信した場合、ネットワークルーティング経路の送信遅延（遷移遅延）により、ＰＴサーバが前記ＭＢ＿Ｒｅｌｅａｓｅメッセージを先に受信し、一部のＲＴＰメディアパケット（例えば、最後のＲＴＰメディアパケット）を受信していない状態で、前記メディアデータの送信のために許容される期間が経過すると、端末は、Ｔ９タイマに設定された期間（例えば、３０秒）中はＰＴサーバに発言権（ｍｅｄｉａ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ）を要求できない望ましくない状態になることがある。

本発明の目的は、従来技術に関する限界及び欠点を解決する、ＰＴサーバ状態制御方法及び装置を提供することにある。

本発明の他の目的は、効果的なメディアバースト制御技術を提供することのできるＰＴクライアント装置（端末）及びＰＴサーバを提供することにある。

また、本発明は、ＰＴサーバが端末（ＰＴクライアント装置）からメディアバースト送信権限（発言権（ｆｌｏｏｒ、ｍｅｄｉａ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ））の解除のためのメッセージを受信した後、所定のメディアデータを受信した場合も、端末がメディアバースト送信権限を要求できるようにするためのものである。

さらに、本発明は、ＰＴサーバが端末（ＰＴクライアント装置）からメディアバースト送信権限の解除のためのメッセージを受信した後、メディアバースト送信権限が許容される期間が経過した場合も、端末が所定期間、メディアバースト送信権限の要求を制限（抑止、制御）されることなく、メディアバースト送信権限を要求できるようにするためのものである。

本発明の一態様によるＰＴサーバの状態制御方法は、第２状態のＰＴサーバが、メディアバースト解除メッセージを受信すると第１状態に遷移する段階と、前記第１状態のＰＴサーバがＰＴクライアントからメディアパケットを受信した場合、及び以前の前記第２状態のＰＴサーバが前記メディアバースト解除メッセージを受信した場合、前記ＰＴサーバが前記第１状態を維持する段階とを含む。

本発明の他の態様によるＰＴサーバの状態制御方法は、第２状態のＰＴサーバが、メディアバースト解除メッセージを受信すると第１状態に遷移する段階と、前記ＰＴサーバが、前記遷移した第１状態にある間にメディアパケットを受信した場合、以前の前記第２状態で前記メディアバースト解除メッセージを受信したか否かを判断する段階と、前記ＰＴサーバが、前記判断段階で以前の前記第２状態で前記メディアバースト解除メッセージを受信したと判断した場合、前記メディアパケットを受信した時点で前記遷移した第１状態を維持する段階とを含む。前記方法は、第２状態のＰＴサーバが、Ｔ２タイマ作動中に、ＰＴクライアントから少なくとも１つのメディアパケットを受信する段階と、前記第２状態のＰＴサーバが、前記Ｔ２タイマ作動中に、前記ＰＴクライアントからメディアバースト解除メッセージを受信する段階とをさらに含む。

本発明のさらに他の態様によるＰＴサーバの状態制御方法は、第２状態のＰＴサーバが、Ｔ２タイマ満了時に、メディアバースト解除メッセージを受信したか否かを判断する段階と、前記ＰＴサーバが、前記判断段階で前記メディアバースト解除メッセージを受信したと判断した場合に前記第２状態から第１状態に遷移するか、又は前記判断の結果に基づいて前記第２状態から第４状態に遷移する段階とを含む。

本発明のさらに他の態様によるＰＴサーバの状態制御方法は、ＰＴサーバが、Ｔ２タイマ作動中に、メディアバースト解除メッセージを受信する段階と、前記ＰＴサーバが、前記Ｔ２タイマ満了時に、前記メディアバースト解除メッセージを受信したか否かを判断する段階と、前記ＰＴサーバが、前記判断段階で前記メディアバースト解除メッセージを受信したと判断した場合、メディアバーストアイドル状態に遷移する段階とを含む。

本発明のさらに他の態様によるＰＴクライアント装置は、少なくとも１つのメディアパケット及びメディアバースト解除メッセージをＰＴサーバに送信し、前記メディアバースト解除メッセージに対する応答としてメディアバーストアイドルメッセージを前記ＰＴサーバから受信し、前記メディアバーストアイドルメッセージを受信した後、メディアバースト要求を前記ＰＴサーバに送信する制御部を含み、前記メディアバーストアイドルメッセージは、前記ＰＴサーバがＴ２タイマ満了前に前記メディアバースト解除メッセージを受信した場合に前記ＰＴサーバから受信される。

本発明のさらに他の態様によるＰＴクライアント装置は、少なくとも１つのメディアパケット及びメディアバースト解除メッセージをＰＴサーバに送信し、前記メディアバースト解除メッセージに対する応答としてメディアバーストアイドルメッセージを前記ＰＴサーバから受信し、前記メディアバーストアイドルメッセージを受信した後、メディアバースト要求を前記ＰＴサーバに送信する制御部を含み、前記メディアバースト要求は、前記ＰＴサーバが前記メディアバースト解除メッセージを受信した後に第１状態で少なくとも１つのメディアパケットを受信した場合に送信され、前記メディアバースト解除メッセージは、前記ＰＴサーバにより以前の状態で受信される。

本願のこのような目的及びその他の目的は後述する詳細な説明により明らかになるであろう。しかし、本発明の思想や範囲内で詳細な説明から様々な変更及び変形が可能であることは当業者に明らかであるので、詳細な説明及び特定例は、本発明の好ましい実施形態を示しているものの、単なる例示のために与えられたものであることを理解すべきである。

本発明は、後述する詳細な説明及び単なる例示のために与えられた添付図面からより十分に理解できるであろうが、これにより限定されるものではない。

図１は、従来のＰＴクライアントとＰＴサーバ間のメディアバーストの送信／受信を示す状態マシン図である。 図２は、従来のＰＴサーバと端末（ＰＴクライアント）間のメディアバースト送信権限の取得及びメディアデータの送信を示す信号フロー図である。 図３は、本発明の第１実施形態によるメディアバースト制御を示す信号フロー図である。 図４は、本発明の第２実施形態によるメディアバースト制御を示す信号フロー図である。 図５は、本発明のＵＥ（又は、端末）を示すＰＴ構造である。

本発明の好ましい実施形態に関する説明は、ＰＴサービスを提供するＰＴ通信システム及び関連装置に適用することができる。しかし、本発明は、これに限定されるものではなく、本発明の技術的特性を適用できる全ての有無線通信システム及び関連装置に適用することができる。

本発明の一態様によれば、メディアバースト送信権限（発言権（ｆｌｏｏｒ、ｍｅｄｉａ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ）を取得した端末が、メディアデータ（例えば、シーケンス番号を有しないＲＴＰメディアパケット）と前記メディアバースト送信権限の解除のためのメッセージ（すなわち、ＭＢ＿Ｒｅｌｅａｓｅ）を、メディアバースト送信権限期間内にＰＴサーバに送信した場合、異なるネットワークルーティング経路での送信遅延（遷移遅延）により、前記ＰＴサーバが、前記ＭＢ＿Ｒｅｌｅａｓｅメッセージを受信した後、前記メディアデータの一部（例えば、最後のＲＴＰメディアパケット、又は最後のＲＴＰパケットではない少なくとも１つのＲＴＰメディアパケット）を受信しても、前記端末は、前記ＰＴサーバに何ら制限されることなく、前記メディアバースト送信権限の要求が許容される。

本発明の他の態様によれば、メディアバースト送信権限を取得した端末が、メディアデータ（例えば、シーケンス番号を有するＲＴＰメディアパケット）とＭＢ＿Ｒｅｌｅａｓｅメッセージを、メディアバースト送信権限期間内に順次送信した場合、異なるネットワークルーティング経路での送信遅延（遷移遅延）により、前記ＰＴサーバが、前記ＭＢ＿Ｒｅｌｅａｓｅメッセージを先に受信した後、メディアバースト送信権限期間が経過するまでに前記メディアデータの一部（例えば、最後のＲＴＰメディアパケット、又は最後のＲＴＰパケットではない少なくとも１つのＲＴＰメディアパケット）を受信しても、前記端末は、何ら制限されることなく、前記メディアバースト送信権限の要求が許容される。

以下、添付図面を参照して、本発明の好ましい実施形態の構成及び動作を説明する。本発明においては、単なる例示として第１及び第２実施形態を提案する。

第１実施形態は、ＲＴＰメディアパケット（メディアデータ）がシーケンス番号を有する場合にも有しない場合にも適用される。第２実施形態は、ＲＴＰメディアパケット（メディアデータ）がシーケンス番号を有しており、ＰＴサーバが受信したメディアバースト解除メッセージ（例えば、ＭＢ＿Ｒｅｌｅａｓｅメッセージ）に含まれる「最後のパケットのシーケンス番号」情報を調べることにより、少なくとも１つの追加ＲＴＰメディアパケットを受信し得ることが分かり、受信される追加ＲＴＰメディアパケットを待つことのできる場合に適用されることが好ましい。ここで、各ＲＴＰメディアパケット（メディアデータ）のシーケンス番号は、各パケットの識別子（ｉｄｅｎｔｉｔｙ）の役割を果たし、かつ各パケットのシーケンス（順序）を通知する一種のインジケータの役割を果たす。各ＭＢ＿Ｒｅｌｅａｓｅメッセージは、「最後のパケットのシーケンス番号」などの最後のＲＴＰメディアパケットを識別できる情報を含む。しかしながら、各ＲＴＰメディアパケットは、ＲＴＰメディアパケットのシーケンス番号を含んでもよく、含まなくてもよい。

図３は、本発明の第１実施形態によるメディアバースト制御を示す信号フロー図である。

以下、図１及び図３を参照して説明する。ここで、図１におけるＰＴサーバの第０状態でＳＩＰセッションが開始され、前記ＰＴサーバは各端末にＭＢ＿Ｉｄｌｅメッセージを送信して第１状態にあると前提する。すなわち、各端末は、ＰＴサーバに発言権（ｍｅｄｉａ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ、ｆｌｏｏｒ、又はメディアバースト送信権限（ｐｅｒｍｉｓｓｉｏｎ ｔｏ ｓｅｎｄ ｍｅｄｉａ ｂｕｒｓｔ））を要求できる状態にある。ただし、ここでは、一例として、端末ＡがＰＴサーバからメディアバースト送信権限を取得したことを前提に説明する。

端末Ａ、Ｂ、及びＣ（ＰＴクライアント装置）のそれぞれは、メディアバースト送信権限を要求するメッセージ（例えば、ＭＢ＿Ｒｅｑｕｅｓｔ）をＰＴサーバに送信する（Ｓ１０）。ＰＴサーバが端末Ａにメディアバースト送信権限を付与すると決定した場合、ＰＴサーバは、端末Ａによるメディアバースト送信権限の要求に対する応答として、承諾メッセージ（例えば、ＭＢ＿Ｇｒａｎｔｅｄ）を端末Ａに送信する反面、端末Ｂ及びＣには、メディアバースト送信権限が端末Ａに付与されたことを示すメッセージを送信する（Ｓ２０）。前記ステップＳ１０〜Ｓ２０により、端末Ａに対するＰＴサーバの状態は、図１の第１状態から第２状態マシン（すなわち、「Ｕ：ｐｅｒｍｉｔｔｅｄ」状態）に遷移（変化、移動）する。従って、端末Ａは、Ｔ２タイマに設定された許容（有効）期間の間、メディアデータ（又は、ＲＴＰメディアパケット）をＰＴサーバに送信することができる。また、前記ステップＳ１０〜Ｓ２０により、端末Ｂ及びＣはＭＢ＿Ｔａｋｅｎメッセージを受信した状態であるので、端末Ｂ及びＣに対するＰＴサーバの動作状態は、図１の第６状態（「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ａｎｄ ＭＢ＿Ｔａｋｅｎ」状態）に該当する。端末Ａは、第２状態（すなわち、「Ｕ：ｐｅｒｍｉｔｔｅｄ」状態）にあるので、メディアデータ（又は、ＲＴＰメディアパケット）をＰＴサーバに送信することができる（Ｓ３０）。ここで、ＰＴサーバは、最初のＲＴＰメディアパケットを受信すると、Ｔ１タイマとＴ２タイマを作動させる。すなわち、端末Ａは、Ｔ２タイマに設定された時間（期間）（例えば、３０秒）内は一連のＲＴＰメディアパケットをＰＴサーバに送信することができる（Ｓ３１〜Ｓ３３）。ここで、ＰＴサーバは、各ＲＴＰメディアパケットが到着する毎にＴ１タイマを再作動（再スタート）させる。Ｔ１タイマは、１つのＲＴＰメディアパケットが到着してから次のＲＴＰメディアパケットが到着するまでの期間をカウントする。

もし、Ｔ１タイマが満了するか、又は端末ＡからＭＢ＿Ｒｅｌｅａｓｅメッセージを受信すると、ＰＴサーバは、端末Ａがメディアデータの送信を完了したとみなし、図１の第２状態から図１の第１状態、すなわち端末Ａが発言権（メディアバースト送信権限）を要求できる状態に遷移する。

以下、ステップＳ３０をより詳細に説明する。図３に示すように、端末Ａは、メディアデータの送信のために許容される期間（すなわち、Ｔ２タイマに設定された値（期間））内に一連のＲＴＰメディアパケットをＰＴサーバに送信し（Ｓ３１〜Ｓ３３）、その後ＭＢ＿ＲｅｌｅａｓｅメッセージをＰＴサーバに送信した（Ｓ３４）。ここで、端末Ａが送信したメッセージ（すなわち、ＲＴＰメディアパケットとＭＢ＿Ｒｅｌｅａｓｅメッセージ）は異なるネットワークルーティング経路でＰＴサーバに送信される。これにより、異なるネットワークルーティング経路の使用による送信遅延（遷移遅延）が発生する。従って、ＰＴサーバは、端末Ａが送信したＭＢ＿Ｒｅｌｅａｓｅメッセージを受信した後、最後のＲＴＰメディアパケット又は（最後のＲＴＰメディアパケットではない）少なくとも１つのＲＴＰメディアパケットを受信することがある（Ｓ３４）。

ＰＴサーバが前記ステップＳ３４でＴ２タイマ作動中にＭＢ＿Ｒｅｌｅａｓｅメッセージを受信したので、端末Ａに対するＰＴサーバのＴＢＣＰ（又は、ＭＢＣＰ）状態は、現在の状態である第２状態（すなわち、「Ｕ：ｐｅｒｍｉｔｔｅｄ」状態）から第１状態マシン（すなわち、「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ａｎｄ ＭＢ＿Ｉｄｌｅ」状態）に遷移する。ＰＴサーバは、端末Ａがこの状態で必要に応じて再びＰＴサーバにメディアバースト要求を送信できることを意味する、メディアバースト送信権限要求メッセージ（例えば、ＭＢ＿Ｒｅｑｕｅｓｔ）を端末Ａから受信することができる。

その後、本発明によれば、前記ステップＳ３３のように、第１状態にあるＰＴサーバが最後のＲＴＰメディアパケット又は他のＲＴＰメディアパケットを受信すると、ＰＴサーバは、ＭＢ＿Ｒｅｌｅａｓｅメッセージ（すなわち、ＰＴサーバが第２状態｛すなわち、「Ｕ：ｐｅｒｍｉｔｔｅｄ」状態｝で既に受信したメッセージ）を既に受信したか否かを判断する。もし、ＭＢ＿Ｒｅｌｅａｓｅメッセージを既に受信したと判断した場合、ＰＴサーバは、第３状態（「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ｂｕｔ ｓｅｎｄｓ ｍｅｄｉａ」）に遷移せず、その受信した最後のＲＴＰメディアパケット又は他のＲＴＰメディアパケットを（他のＰＴクライアントに送信するのではなく）廃棄した後、第１状態を維持するので、端末Ａは、所望の場合、再びメディアバースト送信権限を要求することができる。それに対し、ＭＢ＿Ｒｅｌｅａｓｅメッセージを受信していないと判断した場合、ＰＴサーバは第１状態から第３状態に遷移する。

図３の実施形態において、第１状態にあるＰＴサーバは、図１の従来技術とは異なり、ＭＢ＿Ｒｅｌｅａｓｅメッセージ（すなわち、ＰＴサーバが第２状態｛すなわち、「Ｕ：ｐｅｒｍｉｔｔｅｄ」状態｝で既に受信したメッセージ）を既に（例えば、ステップＳ３４で）受信したと判断して、前記受信したＲＴＰメディアパケットを廃棄し、第１状態を維持し、第３状態に遷移しない（Ｓ３５）。すなわち、第１状態にあるＰＴサーバがステップＳ３３のＲＴＰメディアパケットを受信するとき、端末Ａに対するＰＴサーバの状態は、第１状態から第３状態（すなわち、図１の「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ｂｕｔ ｓｅｎｄｓ ｍｅｄｉａ」状態）に遷移しない。その結果、ＰＴサーバがステップＳ３４のＭＢ＿Ｒｅｌｅａｓｅメッセージを受信した後、ステップＳ３３のＲＴＰメディアパケットを受信したとしても、ＰＴサーバはメディアデータを送信した端末Ａがメディアバースト送信権限を有していないとは判断しない。

上記の場合において、ＰＴサーバは、前記ステップＳ３４でＭＢ＿Ｒｅｌｅａｓｅメッセージを受信した後、前記ステップＳ３３で受信した最後のＲＴＰメディアパケット（又は、他のＲＴＰメディアパケット）を廃棄して、端末Ａがメディアバースト送信権限を継続して要求できるようにする。すなわち、端末Ａに対するＰＴサーバのＴＢＣＰ（又は、ＭＢＣＰ）状態は、第１状態を継続して維持する。従って、端末ＡがＴ２タイマに設定された時間（期間）、すなわちメディアバースト送信権限期間内に、メディアデータ（すなわち、一連のＲＴＰメディアパケット）を送信した後、ＭＢ＿Ｒｅｌｅａｓｅメッセージを送信した場合、ネットワークルーティング経路の送信遅延（遷移遅延）により不利に処理されることを防止することができる。これにより、端末に対するＰＴサーバの状態マシンは、第１状態から第３状態に遷移しない。従って、本発明において、端末Ａは、有利かつ効果的にＰＴサーバに再びメディアバースト送信権限を要求することができ、ペナルティが課されない。

図４は、本発明の第２実施形態によるメディアバースト制御を示す信号フロー図である。ここで、図１におけるＰＴサーバの第０状態でＳＩＰセッションが開始され、前記ＰＴサーバは各端末にＭＢ＿Ｉｄｌｅメッセージを送信して第１状態にあると前提する。すなわち、各端末は、ＰＴサーバにメディアバースト送信権限を要求できる状態にある。ただし、一例として、端末ＡがＰＴサーバからメディアバースト送信権限を取得したことを前提に説明する。図４の第２実施形態におけるステップＳ１０及びＳ２０は、図３の第１実施形態におけるステップＳ１０及びＳ２０とその動作及び機能が同一である。図３の第１実施形態とは異なり、図４の第２実施形態においては、ＲＴＰメディアパケット（又は、メディアデータ）がそれぞれシーケンス番号を有し、かつＭＢ＿Ｒｅｌｅａｓｅメッセージが最後のＲＴＰメディアパケットのシーケンス番号に関する情報を含んでいる。

また、例えば図４に示すような本発明の第２実施形態においては、ＭＢ＿Ｒｅｌｅａｓｅメッセージよりも先に送信された、最後のＲＴＰメディアパケット、又は最後のＲＴＰメディアパケットではない少なくとも１つのＲＴＰメディアパケットが受信される前に、前記ＭＢ＿Ｒｅｌｅａｓｅメッセージが端末ＡからＰＴサーバに先に受信されても、ＰＴサーバの状態は第２状態から第１状態に遷移（変化）せず、ＰＴサーバの第２状態が端末Ａに対して継続して維持される。これは、ＰＴサーバがＴ２タイマ満了時まで端末Ａからの最後のＲＴＰメディアパケット（又は、その他のメディアパケット）の受信を待つことを意味する。図４において、各ＲＴＰメディアパケットはシーケンス番号を有するので、ＰＴサーバは、受信したＭＢ＿Ｒｅｌｅａｓｅメッセージに含まれる「最後のパケットのシーケンス番号」情報を確認することにより、最後のパケットが到着するのを待つことができる。

また、図４の第２実施形態は、Ｔ２タイマ満了前に、（好ましくは、シーケンス番号を有する）一連のＲＴＰメディアパケットとＭＢ＿Ｒｅｌｅａｓｅメッセージが端末ＡからＰＴサーバに送信されたが、ネットワークルーティング経路の送信遅延（遷移遅延）により、ＭＢ＿ＲｅｌｅａｓｅメッセージがＰＴサーバに先に受信されることがある。その結果、Ｔ２タイマは、ＰＴサーバがＲＴＰメディアパケットの一部（例えば、最後又は少なくとも１つのメディアパケット）を受信していない状態で満了するであろう。以下、前記ＰＴサーバのＭＢ＿Ｒｅｌｅａｓｅメッセージ及び特定のＲＴＰメディアパケットの受信に関する動作を、本発明によるステップＳ４０を参照してより詳細に説明する。

ステップＳ４０を参照すると、メディアバースト送信権限を取得した端末Ａは、メディアデータの送信のために許容される期間（すなわち、Ｔ２タイマに設定された値（期間））内に、一連のＲＴＰメディアパケットをＰＴサーバに送信する（Ｓ４１〜Ｓ４３）。ここで、前記ＲＴＰメディアパケットは、それぞれシーケンス番号を有することが好ましい。端末Ａは、メディアデータ送信期間（すなわち、Ｔ２タイマに設定された値（期間））中に、ＭＢ＿ＲｅｌｅａｓｅメッセージをＰＴサーバに送信する（Ｓ４４）。ところが、前記ＲＴＰメディアパケットと前記ＭＢ＿Ｒｅｌｅａｓｅメッセージが端末ＡからＰＴサーバに順次送信されたとしても、それぞれのＲＴＰメディアパケット及びＭＢ＿Ｒｅｌｅａｓｅメッセージは送信されるネットワークルーティング経路が異なることがある。従って、前記パケット及びメッセージが送信されるルーティング経路が異なるため、送信遅延（遷移遅延）が発生することがある。

図４の実施形態において、ＰＴサーバは、Ｔ２タイマ満了前に、ＲＴＰメディアパケット（シーケンス番号１）やＲＴＰメディアパケット（シーケンス番号２）などを受信する（Ｓ４１〜Ｓ４２）。その後、送信遅延（遷移遅延）により、ＭＢ＿Ｒｅｌｅａｓｅメッセージを、最後又はその他のＲＴＰメディアパケット（すなわち、シーケンス番号ｎを有するＲＴＰメディアパケット）よりも先に受信することがある（Ｓ４３及びＳ４４）。このとき、ＰＴサーバは、前記受信したＭＢ＿Ｒｅｌｅａｓｅメッセージに含まれる最後のＲＴＰメディアパケットのシーケンス番号（例えば、ｎ）に関する情報を分析し、その受信したＲＴＰメディアパケットが最後のＲＴＰパケットであるか否かを判断することができる。例えば、前記受信したＭＢ＿Ｒｅｌｅａｓｅメッセージに提供された「最後のパケットのシーケンス番号」情報／パラメータを調べることができる。ＰＴサーバは、前記最後のＲＴＰメディアパケットのシーケンス番号に関する情報を特定のメモリ（例えば、ＰＴサーバに内蔵（装着）されたメモリ又は外部メモリ）に保存することができる。

前記受信したＭＢ＿Ｒｅｌｅａｓｅに含まれる「最後のパケットのシーケンス番号」情報は、ＰＴサーバが依然として最後のパケットを受信する必要があることを示すので、ＰＴサーバは、ＭＢ＿Ｒｅｌｅａｓｅメッセージを受信すると、ステップＳ４３の（シーケンス番号を有する）最後のＲＴＰメディアパケットの受信を待つ。また、本発明により、端末Ａに対するＰＴサーバの状態は、第２状態から第１状態に遷移せず、現在の第２状態を維持する（Ｓ４５）。その結果、ＰＴサーバは、Ｔ２タイマ満了前に端末Ａが送信したメディアデータ（例えば、シーケンス番号ｎを有する最後のＲＴＰメディアパケット）を受信することができる。

ところが、Ｔ２タイマが満了する時点で最後のＲＴＰメディアパケットを受信することができない場合（例えば、ステップＳ４３でＴ２タイマ満了後に最後のＲＴＰメディアパケットを受信した場合）、ＰＴサーバは、ＰＴサーバがＭＢ＿Ｒｅｌｅａｓｅメッセージを既に受信したか否かを判断する（Ｓ４６）。すなわち、ＰＴサーバが第２状態（「Ｕ：ｐｅｒｍｉｔｔｅｄ」）にある間にＴ２タイマが満了した場合、ＰＴサーバは、第４状態に遷移せず、第２状態をそのまま維持する（Ｓ４５）。そして、ＰＴサーバは、ＭＢ＿Ｒｅｌｅａｓｅメッセージを既に受信したか否かを判断する（Ｓ４６）。ＭＢ＿Ｒｅｌｅａｓｅメッセージを既に受信したと判断した場合、ＰＴサーバは、第２状態から第１状態（「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ａｎｄ ＭＢ＿Ｉｄｌｅ」）に遷移し、ＭＢ＿Ｉｄｌｅメッセージを端末Ａに送信し、後で受信される全てのＲＴＰメディアパケットを廃棄する。図４の実施形態においては、ＰＴサーバが前記ステップＳ４４でＭＢ＿Ｒｅｌｅａｓｅメッセージを既に受信したので、ＰＴサーバは、ステップＳ４５でＭＢ＿Ｒｅｌｅａｓｅメッセージを既に受信したと判断する。従って、ＰＴサーバは、第２状態から第１状態に遷移した後、第１状態を維持してＭＢ＿Ｉｄｌｅメッセージを端末Ａに送信する（Ｓ４７及びＳ４８）。

それに対し、ステップＳ４５でＭＢ＿Ｒｅｌｅａｓｅメッセージを受信していないと判断した場合、ＰＴサーバは、ＭＢ＿Ｒｅｖｏｋｅメッセージを端末Ａに送信し（Ｓ４９）、第２状態から第４状態（「Ｕ：ｐｅｎｄｉｎｇ ＭＢ＿Ｒｅｖｏｋｅ」）に遷移する（Ｓ５０）。

以上のように、前記ステップＳ４５の判断により、ＰＴサーバは、Ｔ２タイマ満了前にステップＳ４４でＭＢ＿Ｒｅｌｅａｓｅメッセージを既に受信したか否かを確認することができる。従って、ＰＴサーバが第２状態から第１状態に遷移し、端末Ａはメディアバースト送信権限を要求することができるという利点がある。すなわち、本発明によれば、ＰＴサーバは、Ｔ２タイマが満了するや否や端末ＡにＭＢ＿Ｒｅｖｏｋｅメッセージを送信するわけではない。また、この場合、端末Ａに対するＰＴサーバの状態は、第２状態から第４状態（すなわち、「Ｕ：ｐｅｎｄｉｎｇ ＭＢ＿Ｒｅｖｏｋｅ」状態）に遷移（変化）しない。ところが、ステップＳ４５でＰＴサーバが、Ｔ２タイマが満了する時点でまだＭＢ＿Ｒｅｌｅａｓｅメッセージを受信していないと判断した場合、ＰＴサーバは、ＭＢ＿Ｒｅｖｏｋｅメッセージを端末Ａに送信する（Ｓ４９）。ここで、端末Ａに対するＰＴサーバの状態は、第２状態から第４状態（「Ｕ：ｐｅｎｄｉｎｇ ＭＢ＿Ｒｅｖｏｋｅ」状態）に遷移する（Ｓ５０）。

一方、ＰＴサーバは、Ｔ２タイマが満了すると、Ｔ３タイマを作動させることができる。ＰＴサーバがＴ３タイマ満了前に前記（シーケンス番号がｎである）最後のＲＴＰメディアパケットを受信した場合、ＰＴサーバは、前記（シーケンス番号がｎである）最後のＲＴＰメディアパケットを端末Ｂ及び／又は端末Ｃに送信する（すなわち、図１の状況４に該当する）。しかし、Ｔ３タイマが満了するか、又は第４状態にあるＰＴサーバが前記（シーケンス番号がｎである）最後のＲＴＰメディアパケットを受信した場合、ＰＴサーバは、端末Ａが発言権（ｍｅｄｉａ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ）（メディアバースト送信権限）なくメディアデータ（すなわち、前記シーケンス番号がｎである最後のＲＴＰメディアパケット）を送信したとみなすことになる。従って、端末Ａに対するＰＴサーバの状態は、第４状態（「Ｕ：ｐｅｎｄｉｎｇ ＭＢ＿Ｒｅｖｏｋｅ」状態）から第５状態（「Ｕ：ｗａｉｔｉｎｇ ＭＢ＿Ｒｅｖｏｋｅ」状態）に遷移（変化）する。このような第５状態で、ＰＴサーバは、端末Ａに所定期間（すなわち、Ｔ９タイマに設定された期間）メディアバースト送信権限を要求できないペナルティを課す。

従って、本発明の第２実施形態において、ＰＴサーバは、Ｔ２タイマの許容期間内に、端末Ａから最後のＲＴＰメディアパケットを受信する前に、ＭＢ＿Ｒｅｌｅａｓｅメッセージを先に受信した場合、前記ＭＢ＿Ｒｅｌｅａｓｅメッセージに含まれる最後のＲＴＰメディアパケットのシーケンス番号に関する情報を確認（分析）した後、第２状態から第１状態に遷移せず、その最後のＲＴＰメディアパケットの受信を待つ。しかし、Ｔ２タイマが満了する時点で前記最後のＲＴＰメディアパケットを受信していなくても、ＰＴサーバは、ＭＢ＿Ｒｅｖｏｋｅメッセージを端末Ａに自動で送信するのではなく、前記ＭＢ＿Ｒｅｌｅａｓｅメッセージを既に受信したか否かを判断した後、その判断に基づいて第２状態から第４状態に移動することができる。従来の技術においては、Ｔ２タイマ満了時に、ＰＴサーバが自動で第２状態から第４状態に遷移することによって、Ｔ３タイマとＴ９タイマが作動し、Ｔ９タイマ作動中は端末Ａはメディアバースト送信権限を要求することができない。これは、ＰＴサーバが端末にあまりにも厳格にペナルティを課すため問題となっている。本発明は、ステップＳ４６の判断結果に基づいて、ＰＴサーバが選択的に第２状態から第４状態に遷移するため、このような限界を克服する。その結果、本発明によれば、ユーザ（端末Ａ）は不要なペナルティを受けず、ＰＴサーバは端末Ａがメディアバースト送信権限を要求できるようにすることができる。従って、端末Ａは、ネットワーク送信遅延（遷移遅延）により制限されることなく、ＰＴサービスが好ましく提供される。

前述のように、本発明の明細書は単に例示的な実施形態を参照して説明された。本発明においては様々な変更及び変形が可能であることは当業者に明らかであろう。例えば、ここに論議された本発明の方法は、ソフトウェア、ハードウェア、又はこれらの組み合わせにより実現、すなわち記憶媒体（例えば、端末の内部メモリ、フラッシュメモリ、ハードディスクなど）に保存することができ、プロセッサ（例えば、端末の内部マイクロプロセッサ）によりプログラミングされたソフトウェアプログラム内にコードやコマンドで実現することができる。また、本発明の実施形態において、トークバーストはオーディオデータを示し、メディアバーストは文字、動画像、又は写真などのデータを示す。トークバーストとメディアバーストの両方ともデータフォーマットに関係なく本発明の実施形態に適用することができる。従って、本発明は、添付された請求の範囲及びその同等物の範囲内で提供される変更及び変形を含むことができる。

本発明による各端末（例えば、端末Ａ、Ｂ、Ｃなど）は、ＰＴサービスを提供できるＰＴクライアント装置（ＰＴクライアントを含む全ての装置）である。各端末は、ここに論議された本発明の方法を実現するための制御部、メモリ、及びその他の構成要素を含むことができる。例えば、各端末は、全てのタイプの移動通信端末、ＰＴサービスを利用できるノートブックコンピュータ、デスクトップコンピュータ、携帯用ゲーム機、ＭＰＳ、又はその他の家電製品の１つでもよい。また、本発明の説明において、各端末は、ＰＴクライアントを含む物理エンティティ（ｐｈｙｓｉｃａｌ ｅｎｔｉｔｙ）を示すことが好ましく、ＰＴクライアントは、端末内に含まれる論理又は物理エンティティ（ｌｏｇｉｃａｌ ｏｒ ｐｈｙｓｉｃａｌ ｅｎｔｉｔｙ）を意味することが好ましい。従って、本発明の説明の便宜上、端末はＰＴクライアント装置を示すこともあり、その逆も可能である。

図５は、本発明による端末（又は、ＵＥ）の構成を含むＰＴシステム構造である。以下、図５を参照して説明する。

図５の実施形態において、ＰＴクライアントは、移動端末に位置し、ＰＴサービス接続に利用される。前記ＰＴクライアントは、ＰＴセッション開始（例えば、コーデックネゴシエーション）、参加（例えば、トーク（ｔａｌｋ）又はリッスン（ｌｉｓｔｅｎ））及び解除のために構成することができる。前記ＰＴクライアントは、ＳＩＰ／ＩＰコアを利用した登録を行い、ＳＩＰ／ＩＰコアにＰＴユーザを認証するために構成することができる。前記ＰＴクライアントは、オーディオレコーディング又はオーディオエンコーディングにより、トークバースト（メディアバースト）を生成及び送信するように構成することができる。前記ＰＴクライアントは、トークバーストを受信し、その受信したトークバーストをデコーディングしてオーディオを生成できるように構成することができる。前記ＰＴクライアントは、トークバースト制御手順及びトークバーストプロトコルネゴシエーションをサポートするために構成することができる。前記ＰＴクライアントは、ＤＭクライアントが提供するＰＴ構成データ（ＰＴ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｄａｔａ）を統合（ｉｎｃｏｒｐｏｒａｔｅ）するために構成することができる。前記ＰＴクライアントは、応答モード指示（ａｎｓｗｅｒ ｍｏｄｅ ｉｎｄｉｃａｔｉｏｎ）（手動応答、自動応答）、インカミングＰＴセッション制限（ｉｎｃｏｍｉｎｇ ＰＴ ｓｅｓｓｉｏｎ ｂａｒｒｉｎｇ）及びインカミングインスタント個人警告禁止（ｉｎｃｏｍｉｎｇ ｉｎｓｔａｎｔ ｐｅｒｓｏｎａｌ ａｌｅｒｔ ｂａｒｒｉｎｇ）、並びに同時ＰＴセッションサポート（ｓｉｍｕｌｔａｎｅｏｕｓ ＰＴ ｓｅｓｓｉｏｎｓ ｓｕｐｐｏｒｔ）を設定することのできる能力をサポートするために構成することができる。前記ＰＴクライアントは、ＰＴサーバにより開始される場合、ユーザプレーン適用手順（ｕｓｅｒ ｐｌａｎｅ ａｄａｐｔａｔｉｏｎ ｐｒｏｃｅｄｕｒｅ）をサポートするように構成することができる。前記ＰＴクライアントは、インスタント個人警告の受信をサポートするように構成することができる。前記ＰＴクライアントは、インスタント個人警告の送信をサポートし、グループ通知（ｇｒｏｕｐ ａｄｖｅｒｔｉｓｅｍｅｎｔ）を提供するように構成することができる。前記ＰＴクライアントは、複数のトークバースト制御プロトコル、並びに優先順位（ｐｒｉｏｒｉｔｙ）及びタイムスタンプに基づいて行えるトークバースト要求待機（ｔａｌｋ ｂｕｒｓｔ ｒｅｑｕｅｓｔ ｑｕｅｕｉｎｇ）をサポートするように構成することができる。前記ＰＴクライアントは、トークバースト終了後に品質フィードバック報告（ｑｕａｌｉｔｙ ｆｅｅｄｂａｃｋ ｒｅｐｏｒｔｓ）を送信するように構成することができる。前記ＰＴクライアントは、既に設定されているセッションをサポートするように構成することができる。前記ＰＴクライアントは、ユーザＩＤ（ｕｓｅｒ ｉｄｅｎｔｉｔｙ）に対するプライバシーを要求するために、同時セッション及びセッションオン・ホールド手順（ｓｉｍｕｌｔａｎｅｏｕｓ ｓｅｓｓｉｏｎｓ ａｎｄ ｓｅｓｓｉｏｎ ｏｎ−ｈｏｌｄ ｐｒｏｃｅｄｕｒｅ）をサポートするように構成することができる。

図５の実施形態において、ＸＤＭＣ（ＸＭＬ Ｄｏｃｕｍｅｎｔ Ｍａｎａｇｅｍｅｎｔ Ｃｌｉｅｎｔ）は、ネットワークに保存されているＸＭＬ文書（例えば、ＰＴ ＸＤＭＳでのＰＴ専用文書（ＰＴ−ｓｐｅｃｉｆｉｃ ｄｏｃｕｍｅｎｔ）、例えば共有ＸＤＭＳ（ｓｈａｒｅｄ ＸＤＭＳ）でのコンタクトリストとして利用されるＵＲＩリストなど）を管理するＸＣＡＰクライアントでもよい。管理特性には生成、修正、検索、及び削除などの動作が含まれる。

図５の実施形態において、プレゼンスソース（ｐｒｅｓｅｎｃｅ ｓｏｕｒｃｅ）は、プレゼンスサービスにプレゼンス情報を提供（発行）するエンティティである。ウォッチャーは、プレゼンティティ（ｐｒｅｓｅｎｔｉｔｙ）に関するプレゼンス情報、又はウォッチャーに関するウォッチャー情報を要求し、前記プレゼンスサービスを構成するエンティティである。

前述のように、本発明においては、端末がネットワーク送信遅延（遷移遅延）によるＰＴサーバの制限を受けず、メディアバースト送信権限（発言権（ｔａｌｋ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ、ｍｅｄｉａ ｂｕｒｓｔ ａｕｔｈｏｒｉｔｙ、ｆｌｏｏｒ）を要求することができる。従って、端末及びＰＴサーバは円滑で好ましくＰＴサービスを利用することができる。

本発明は単に例示的な実施形態を参照して説明された。本発明において、本発明の思想や範囲内で様々な変更及び変形が可能であることは当業者に明らかであろう。従って、本発明は、添付された請求の範囲及びその同等物の範囲内で提供される本発明の変更及び変形を含むことができる。

Claims (22)

1. 第２状態のＰＴサーバが、メディアバースト解除メッセージを受信すると第１状態に遷移する段階と、
   前記第１状態のＰＴサーバがＰＴクライアントから少なくとも１つのメディアパケットを受信した場合、及び以前の前記第２状態のＰＴサーバが前記メディアバースト解除メッセージを受信した場合、前記ＰＴサーバが前記第１状態を維持する段階と
   を含むことを特徴とするＰＴサーバの状態制御方法。
2. 前記第１状態は、前記ＰＴクライアントが前記ＰＴサーバにメディアバースト要求を送信できる状態であり、前記第２状態は、前記ＰＴサーバが前記ＰＴクライアントにメディアバースト送信権限を付与した状態であることを特徴とする請求項１に記載のＰＴサーバの状態制御方法。
3. 前記第１状態は、「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ａｎｄ ＭＢ＿Ｉｄｌｅ」状態であり、前記第２状態は、「Ｕ：ｐｅｒｍｉｔｔｅｄ」状態であることを特徴とする請求項１に記載のＰＴサーバの状態制御方法。
4. 前記遷移段階においては、
   前記第２状態のＰＴサーバが、Ｔ２タイマ作動中に、前記メディアバースト解除メッセージを受信することを特徴とする請求項１に記載のＰＴサーバの状態制御方法。
5. 第２状態のＰＴサーバが、メディアバースト解除メッセージを受信すると第１状態に遷移する段階と、
   前記ＰＴサーバが、前記遷移した第１状態にある間にメディアパケットを受信した場合、以前の前記第２状態で前記メディアバースト解除メッセージを受信したか否かを判断する段階と、
   前記ＰＴサーバが、前記判断段階で以前の前記第２状態で前記メディアバースト解除メッセージを受信したと判断した場合、前記メディアパケットを受信した時点で前記遷移した第１状態を維持する段階と
   を含むことを特徴とするＰＴサーバの状態制御方法。
6. 第２状態のＰＴサーバが、Ｔ２タイマ作動中に、ＰＴクライアントから少なくとも１つのメディアパケットを受信する段階と、
   前記第２状態のＰＴサーバが、前記Ｔ２タイマ作動中に、前記ＰＴクライアントからメディアバースト解除メッセージを受信する段階と
   をさらに含むことを特徴とする請求項５に記載のＰＴサーバの状態制御方法。
7. 前記第１状態は、前記ＰＴクライアントが前記ＰＴサーバにメディアバースト要求を送信できる状態であり、前記第２状態は、前記ＰＴサーバが前記ＰＴクライアントにメディアバースト送信権限を付与した状態であることを特徴とする請求項５に記載のＰＴサーバの状態制御方法。
8. 前記第１状態は、「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ａｎｄ ＭＢ＿Ｉｄｌｅ」状態であり、前記第２状態は、「Ｕ：ｐｅｒｍｉｔｔｅｄ」状態であることを特徴とする請求項５に記載のＰＴサーバの状態制御方法。
9. 第２状態のＰＴサーバが、Ｔ２タイマ満了時に、メディアバースト解除メッセージを受信したか否かを判断する段階と、
   前記ＰＴサーバが、前記判断段階で前記メディアバースト解除メッセージを受信したと判断した場合に前記第２状態から第１状態に遷移するか、又は前記判断の結果に基づいて前記第２状態から第４状態に遷移する段階と
   を含むことを特徴とするＰＴサーバの状態制御方法。
10. 前記第１状態は、前記ＰＴクライアントが前記ＰＴサーバにメディアバースト要求を送信できる状態であり、前記第２状態は、前記ＰＴサーバが前記ＰＴクライアントにメディアバースト送信権限を付与した状態であることを特徴とする請求項９に記載のＰＴサーバの状態制御方法。
11. 前記第１状態は、「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ａｎｄ ＭＢ＿Ｉｄｌｅ」状態であり、前記第２状態は、「Ｕ：ｐｅｒｍｉｔｔｅｄ」状態であることを特徴とする請求項９に記載のＰＴサーバの状態制御方法。
12. 前記遷移段階においては、
    前記ＰＴサーバが、前記判断段階で前記メディアバースト解除メッセージを受信していないと判断した場合、前記Ｔ２タイマ満了時に、前記第２状態から前記第４状態に遷移することを特徴とする請求項９に記載のＰＴサーバの状態制御方法。
13. 前記第２状態は、前記ＰＴサーバが前記ＰＴクライアントにメディアバースト送信権限を付与した状態であり、前記第４状態は、前記ＰＴクライアントが前記ＰＴサーバへのメディアバースト要求を禁止されるか、又は前記ＰＴサーバが前記ＰＴクライアントから受信した追加メディアパケットを他のＰＴクライアントに送信できる猶予期間を有する状態であることを特徴とする請求項１２に記載のＰＴサーバの状態制御方法。
14. 前記第２状態は、「Ｕ：ｐｅｒｍｉｔｔｅｄ」状態であり、前記第４状態は、「Ｕ：ｐｅｎｄｉｎｇ ＭＢ＿Ｒｅｖｏｋｅ」状態であることを特徴とする請求項１２に記載のＰＴサーバの状態制御方法。
15. ＰＴサーバが、Ｔ２タイマ作動中に、メディアバースト解除メッセージを受信する段階と、
    前記ＰＴサーバが、前記Ｔ２タイマ満了時に、前記メディアバースト解除メッセージを受信したか否かを判断する段階と、
    前記ＰＴサーバが、前記判断段階で前記メディアバースト解除メッセージを受信したと判断した場合、メディアバーストアイドル状態に遷移する段階と
    を含むことを特徴とするＰＴサーバの状態制御方法。
16. 前記メディアバーストアイドル状態は、「Ｕ：ｎｏｔ ｐｅｒｍｉｔｔｅｄ ａｎｄ ＭＢ＿Ｉｄｌｅ」状態であることを特徴とする請求項１５に記載のＰＴサーバの状態制御方法。
17. 少なくとも１つのメディアパケット及びメディアバースト解除メッセージをＰＴサーバに送信し、前記メディアバースト解除メッセージに対する応答としてメディアバーストアイドルメッセージを前記ＰＴサーバから受信し、前記メディアバーストアイドルメッセージを受信した後、メディアバースト要求を前記ＰＴサーバに送信する制御部を含み、
    前記メディアバーストアイドルメッセージは、前記ＰＴサーバがＴ２タイマ満了前に前記メディアバースト解除メッセージを受信した場合に前記ＰＴサーバから受信されることを特徴とするＰＴクライアント装置。
18. 前記制御部は、前記Ｔ２タイマ満了前に前記ＰＴサーバが前記メディアバースト解除メッセージを受信することによって、前記ＰＴサーバからメディアバースト取消メッセージを受信しないことを特徴とする請求項１７に記載のＰＴクライアント装置。
19. 少なくとも１つのメディアパケット及びメディアバースト解除メッセージをＰＴサーバに送信し、前記メディアバースト解除メッセージに対する応答としてメディアバーストアイドルメッセージを前記ＰＴサーバから受信し、前記メディアバーストアイドルメッセージを受信した後、メディアバースト要求を前記ＰＴサーバに送信する制御部を含み、
    前記メディアバースト要求は、前記ＰＴサーバが前記メディアバースト解除メッセージを受信した後に第１状態で少なくとも１つのメディアパケットを受信した場合に送信され、前記メディアバースト解除メッセージは、前記ＰＴサーバにより以前の状態で受信されることを特徴とするＰＴクライアント装置。
20. 前記ＰＴクライアントは、前記ＰＴサーバが前記メディアバースト解除メッセージを受信した後、前記ＰＴサーバにより第２状態から前記第１状態に遷移することを特徴とする請求項１９に記載のＰＴクライアント装置。
21. 前記以前の状態は、「Ｕ：ｐｅｒｍｉｔｔｅｄ」状態であることを特徴とする請求項１９に記載のＰＴクライアント装置。
22. 前記第１状態は、前記ＰＴクライアントが前記ＰＴサーバにメディアバースト要求を送信できる状態であり、前記第２状態は、前記ＰＴサーバが前記ＰＴクライアントにメディアバースト送信権限を付与した状態であることを特徴とする請求項２０に記載のＰＴクライアント装置。

Images