JP2010523019A - Ｓｉｐベースのメディアサービスにおけるセッション制御 - Google Patents

Abstract

ＳＩＰアプリケーション・サーバに対して、ＳＩＰクライアントの状態が通知されることを維持するための方法であって、ＳＩＰアプリケーション・サーバは、ＳＩＰクライアントにおけるシグナリング・プレーン内とメディア・プレーン内との両方に配置され、ＳＩＰクライアントをＳＩＰセッションに受け入れるとともに、ＳＩＰクライアントをＳＩＰセッションから取り除く。本方法は、メディア・プレーンを介して、ＳＩＰクライアントからＳＩＰアプリケーション・サーバにキープ・アライブ・メッセージを送信するステップを含む。

Description

本発明は、ＳＩＰベースのメディアサービスにおけるセッション制御に関連し、特に、限定するわけではないが、プッシュ・ツー・トーク・サービスに関するものである。より詳細には、本発明は、そのようなサービスにおけるキープ・アライブ機構の提供に関するものである。

無線機タイプのサービスは、他のユーザと素早く簡易なメッセージを通信することを望むユーザの中で、長期にわたって人気となっている。無線機タイプのサービスは、プッシュ・ツー・トーク（ＰＴＴ）サービスとしても知られている。従来、そのようなＰＴＴサービスは、無線スペクトルの専用部分を利用する双方向の携帯無線によって提供されている。しかし、この双方向の携帯無線は、同様の端末を用い、かつ、無線通信の比較的短距離の動作範囲内に位置する予め選択された複数のユーザの小グループと通信を行なうことのみをユーザに許容する。最近では、当該サービスは、現行のセルラ電話のインフラに乗せた形で米国に導入されている。しかし、それらのサービスは、実際には独自のサービスであり、ユーザが異なる動作ネットワークとの間と通信することを許容していない。

ＰＴＴサービスの使用を広げる試みにおいて、オープン・モバイル・アライアンス（www.openmobilealliance.org）として知られている産業団体が、セルラネットワーク上で提供される無線機サービスにおけるネットワーク間の動作を許容する適切なプロトコルを標準化する目的で設立されている。種々の標準規格によって制定されたサービスとして、プッシュ・ツー・トーク・オーバ・セルラ（ＰｏＣ）が知られている。ＰｏＣは、ＩＰマルチメディア・システム（ＩＭＳ）のユーザに対して、ＰｏＣアプリケーション・サーバ（複数のＳＩＰ ＡＳとして動作する。）を介して、ＰｏＣセッションのセットアップと制御とを扱わせる。ＰｏＣは、関連する音声データがパケット交換アクセス技術により伝送されることを提案している。ＧＳＭ及びＵＭＴＳの場合において、これは汎用パケット無線サービス（ＧＰＲＳ）アクセス技術になるであろう。他のネットワーク・アーキテクチャにおいては、アナログパケット交換アクセス技術が音声データの伝送に用いられるであろう。プッシュ・ツー・トーク・サービスはまた、あまり望ましいオプションではないが、回路交換アクセス技術によって提供されてもよい。ＰｏＣの現状はRelease 1.0で設定されている。ＰｏＣのRelease 2における要求仕様は、現在設計されている。ＰｏＣのRelease 2は、音声だけでなくマルチメディアも含むようにＰｏＣを拡張しようとしている。

ＰｏＣ ＡＳ（アプリケーション・サーバ）は、シグナリング・プレーン内及びメディア・プレーン内の両方に存在する。ＰｏＣ ＡＳは、ａ）全てのメディアに関連する機能を含むメディア・プレーンのメディア資源機能プロセッサ（ＭＲＦＰ）と、ｂ）Ｓ−ＣＳＣＦに対してＳＩＰユーザ・エージェントとして動作するシグナリング・プレーンのメディア資源機能制御装置（ＭＲＦＣ）とを含むメディア資源機能（ＭＲＦ）を実装する。ＭＲＦＣとＭＲＦＰとの間のインタフェースはまだ標準化されていないが、標準化された場合はおそらくＨ．２４８に基づくであろう。また、ＰｏＣの場合においてＭＲＦＰを通過する実際の（オーディオ）メディアは、データをパケット化するリアルタイム伝送プロトコル（ＲＴＰ）又はファイルを伝送するメッセージ・セッション・リレー・プロトコル（ＭＳＲＰ）を使用するであろう。

ＰｏＣは、ＰｏＣセッションに関与するＰｏＣクライアントが任意の所定の時間にメディアを送信することを決定するために、「発言権制御（floor control）」の概念を使用する。ＭＲＦＣは、ＰｏＣセッションにおけるメディア・フロア・コントロール・エンティティとして動作する。権限無しでは、ＰｏＣクライアントは、任意の種別のメディアを送信せず、沈黙を示すメディア・パケットであっても送信しない。発言権制御は、メディア・バースト制御プロトコル（ＭＢＣＰ）を使用する、配置されるＰｏＣアプリケーション・サーバによって処理される。ＭＢＣＰメッセージは、メディア層を通過して伝送される。ＰｏＣセッションが確立されるとすぐに、ＰｏＣクライアントは、ＰｏＣ ＡＳに対してＭＢＣＰメディア・バースト要求メッセージを送信することによって、発言権を要求する。メディアを送信することを許可されている他のＰｏＣクライアントが現在存在しないと仮定すると、ＰｏＣ ＡＳは、要求を受け入れ、ＭＢＣＰメディア・バースト権限メッセージを要求したＰｏＣクライアントに返信する。

メディアを送信することを許可されているＰｏＣクライアントが存在しない場合、ＭＢＣＰは、ＰｏＣセッションにおける全ての参加者に送信される”メディア・バースト・アイドル”メッセージを定義する。当該メッセージを受信するＰｏＣクライアントは、要望するのであれば、メディア送信の権限を要求することができることを認識する。その後、ＰｏＣ ＡＳは、メディア送信の権限を無効にし、ＭＢＣＰメディア・バースト・アイドル・メッセージを参加者に送信する。メディア送信の権限を要求する参加者がいなければ、ＰｏＣ ＡＳは、さらに、所定の最大間隔まで、所定間隔ごとにメディア・バースト・アイドル・メッセージを送信する。

多くの理由によってＰｏＣセッションはハングアップする。これは、例えば、ＰｏＣクライアントが無線補償範囲を離れることにより発生する。そのような場合において、ネットワーク・エンティティ、特に、ＩＭＳ範囲内のＳＩＰプロキシは、もはや必要ない状態情報を保持する可能性もある。そんなことよりも、ユーザがサービスにアクセスできないポイントに移動しているかもしれない。したがって、ネットワーク・エンティティがセッションがハングアップしたことを認識できる、ある種のキープ・アライブ機構が提供されることが望まれている。

上記特定した問題は、ＰｏＣに限定されるわけではなく、他のＩＭＳ可能なサービスや、エンド・ポイント間でセッションを確立して制御するＳＩＰで用いられる非ＩＭＳサービスについても可能性がある。

”Session Times in the Session Initiation Protocol（ＳＩＰ）”と題するＩＴＥＦ ＲＦＣ ４０２８は、ＰｏＣセッションに適用可能な上述したような機構を提供している。当該機構は、参加ＳＩＰクライアントが定期的な間隔でＳＩＰシグナリング・パスを介してＳＩＰ＿ＩＮＶＩＴＥメッセージ又はＳＩＰ＿ＵＰＤＡＴＥメッセージを送信することを要求している。シグナリング・ネットワークを過負荷にすることを避けるために、キープ・アライブ・メッセージが送信される間隔を３０分にすることが推奨されている。しかし、一般的なＩＭＳセッション、特に、ＰｏＣセッションが比較的寿命の短いことが予想されるように、ＩＭＳに対する当該機構のアプリケーションは、要求後の長期間にわたってネットワーク内に状態情報を保有させるため、過剰請求を解決するには至っていない。

本発明の第１の態様によれば、本発明は、ＳＩＰアプリケーション・サーバに対して、ＳＩＰクライアントの状態が通知されることを維持する方法を提供する。ＳＩＰアプリケーション・サーバは、ＳＩＰクライアントにおけるシグナリング・プレーン及びメディア・プレーンの両方に配置され、ＳＩＰクライアントをＳＩＰセッションに受け入れるとともに、当該ＳＩＰクライアントを該ＳＩＰセッションから取り除く。本方法は、メディア・プレーンを介してＳＩＰクライアントからＳＩＰアプリケーション・サーバにキープ・アライブ・メッセージを送信するステップを含む。

メディア・プレーンメッセージが、同等のシグナリング・プレーン（ＳＩＰである）のメッセージよりも短く、関連する少数のノードを通過するため、キープ・アライブ・メッセージが送信される時間間隔は、過度にシグナリング・ネットワークに負荷を与えることのない、より短い間隔となる。

本発明が特に半二重セッションに適用可能であることが近いされることが理解されるであろう。そのようなセッションにおいて、ＳＩＰクライアントは、メディアを送信しない場合、又は、ＳＩＰアプリケーション・サーバによってメディアを送信することが許可されていない場合にのみキープ・アライブ・メッセージを送信する。ＳＩＰクライアントがメディアを送信する場合には、これは、黙示的なキープ・アライブ機構を示す。

ＳＩＰクライアントと、ＳＩＰアプリケーション・サーバとの間のキープ・アライブのタイマ値を調整する必要がある。当該タイマ値は、ＳＩＰクライアントから送信されるキープ・アライブ・メッセージが送信される間隔を定義する。ＳＩＰアプリケーション・サーバは、当該タイマ値で満了するように設定したタイマを実行する。タイマが満了する前に、ＳＩＰアプリケーション・サーバがキープ・アライブ・メッセージを受信していなければ、ＳＩＰクライアントは、当該ＳＩＰクライアントが関与しているＳＩＰセッションから取り除かれる。

本発明の典型的な形態によれば、ＳＩＰアプリケーション・サーバは、ＩＰマルチメディア・サブシステム・ネットワーク内に配置される。上記キープ・アライブ・メッセージは、メディア・バースト制御プロトコル・メッセージである。さらに好ましくは、ＳＩＰアプリケーション・サーバは、発言権を制御するプッシュ・ツー・トーク・オーバ・セルラのアプリケーション・サーバである。ＳＩＰクライアントは、プッシュ・ツー・トーク・オーバ・セルラのセッションに関与するプッシュ・ツー・トーク・オーバ・セルラのクライアントである。

好適には、ＳＩＰクライアントがメディアを送信する権限を有していない場合にはキープ・アライブ・メッセージが送信される。ＳＩＰクライアントがメディアを送信する権限を有している場合には、キープ・アライブ・メッセージが送信されない。

好適には、メディアを送信する権限を有する、プッシュ・ツー・トーク・オーバ・セルラに関与するＳＩＰクライアントが存在しない場合であって、かつ、ＳＩＰアプリケーション・サーバがキープ・アライブ・メッセージを受信する場合には、アプリケーション・サーバは、確認応答をＳＩＰクライアントに送信し、それ以外の場合には確認応答を送信しない。

好適には、キープ・アライブ・メッセージを送信するＳＩＰクライアント以外のＳＩＰクライアントがメディアを送信する権限を有している場合に、ＳＩＰアプリケーション・サーバは、キープ・アライブ・メッセージの受信に対する確認応答を送信せず、キープ・アライブ・メッセージを送信するＳＩＰクライアントは、メディアの受信を黙示的な確認応答として見なす。ＳＩＰクライアントがメディアを送信する権限を有している場合に、キープ・アライブ・メッセージ及び明確な確認応答は送信されない。

本発明の実施形態において、キープ・アライブ・メッセージは、ダミーのＲＴＰメディア・パケットである。

本発明の第２の態様によれば、ＳＩＰセッションにＳＩＰクライアントを受け入れるとともに、ＳＩＰセッションからＳＩＰクライアントを取り除くＳＩＰアプリケーション・サーバに、キープ・アライブ・メッセージを送信するように構成され、キープ・アライブ・メッセージは、メディア・プレーンを介して送信されるＳＩＰクライアントを提供する。

本発明の第３の態様によれば、ＳＩＰセッションにＳＩＰクライアントを受け入れるとともに、ＳＩＰセッションからＳＩＰクライアントを取り除き、メディア・プレーンを介してＳＩＰクライアントからキープ・アライブ・メッセージを受信するように構成されるＳＩＰアプリケーション・サーバを提供する。

ＰｏＣアプリケーション・サーバを含むＩＭＳネットワークを概略的に示す図である。 ＰｏＣセッションにおけるキープ・アライブ・タイマ値のネゴシエーションと関連するシグナリングを示す図である。 ３つの異なるセッション・ケースのＰｏＣにおけるキープ・アライブ機構に関連するシグナリングを示す図である。

図１は、アプリケーション・サーバ及びＳＩＰプロキシを含む種々のネットワーク・ノードを備えるＩＭＳネットワークの概略図である。このアーキテクチャは、当業者にはよく知られている。ここでは、ＩＭＳクライアント１、即ち、ユーザ端末がＧＳＭ又は３Ｇネットワークなどのセルラ電話ネットワークであるようなアクセスネットワーク２に接続されることを記載することで十分である。アクセスネットワークを介して、ＩＭＳクライアントは、ＩＭＳコアネットワーク３及び伝送ネットワーク４と通信を行う。ＩＭＳサービスセッションは、ＩＭＳコアネットワーク内のエンティティ及び同様のＩＭＳクライアントと、ＳＩＰシグナリングをやりとりするＩＭＳクライアントによって確立される。ＩＭＳコアネットワークは、要求に応じてＩＭＳクライアントによる使用のための伝送ネットワーク内の利用可能な資源を確保するとともに、伝送ネットワークにリンクされている。

他のＩＭＳコアネットワークを考慮すると、ＩＭＳクライアントは、在圏呼セッション制御機能（Ｓ−ＣＳＣＦ）５に割り当てられる。クライアントがホームドメイン内から又は”訪問先”のドメインを介して、ＩＭＳにアクセスするかどうかに関わらず、Ｓ−ＣＳＣＦは、ＩＭＳクライアントを用いる加入者のホームＩＭＳドメイン内に配置される。複数のＣＳＣＦ（Ｓ−ＣＳＣＦを含む）は、加入者に関する、到達機能（reachability）、認証機能及び承認機能を取り扱う。サービスの提供は、複数のＳＩＰアプリケーション・サーバ（ＡＳ）によって取り扱われる。図１は、ＰｏＣサービスのロジックを提供するＰｏＣ ＡＳ６を示す。上述したように、ＰｏＣ ＡＳは、ＭＲＦＣ及びＭＲＦＰを備えるＭＲＦを実装する。ユーザのメディアはＭＲＦＰを介して流される。

加入者が同様のユーザとのＰｏＣセッションを確立することを望む場合、加入者のＩＭＳクライアントは、ＩＭＳへ接続するための加入者のポイントを示すＰ−ＣＳＣＦを介してＳＩＰ＿ＩＮＶＩＴＥをＳ−ＣＳＣＦに送信する。ＩＮＶＩＴＥがＰｏＣセッションに関連するということを検知すると、加入者用のＳ−ＣＳＣＦにインストールされたイニシャル・フィルタ・クリテリアがＩＮＶＩＴＥをＰｏＣサーバへルーティングする。ＰｏＣサーバは、初期処理、課金処理及び資源の割り当て処理を含む必要な動作を実行し、自身をＳＩＰパスに加え、Ｓ−ＣＳＣＦにＩＮＶＩＴＥを戻す。Ｓ−ＣＳＣＦは、当該ＩＮＶＩＴＥを同様のユーザに転送する。

本実施形態では、ＰｏＣクライアントとＰｏＣ ＡＳとの間のメディアプレーンを介してキープ・アライブ・メッセージの送信に関与するキープ・アライブ機構の導入を提案する。種々の機構／プロトコルは、そのようなメッセージを搬送することに使用されうる。例えば、新たなＭＢＣＰメッセージを特定することに適しているであろう。或いは、伝送プロトコルがＲＴＰであれば、ダミーＲＴＰメディアパケットが使用されうる。ダミーＲＴＰパケットは、本質的には、ちょうど有料部分のないＲＴＰパケットである。本実施形態は、ＰｏＣクライアントが明確な権限を有していない場合であってもメディアの送信を許容するように修正されることが必要となる。

当該機能の前提条件は、ＰｏＣクライアントとＰｏＣ ＡＳとの間のキープ・アライブ・メッセージの間隔の調整（ネゴシエーション）である（図２参照）。このように、ＰｏＣクライアントがＰｏＣセッションを開始するか、ＰｏＣセッションと接続するか、又は、再接続する場合、ＰｏＣクライアントは、”ｆｍｔｐ”パラメータを用いて推奨の時間間隔を有する（”ｆｍｔｐ”は、ＳＩＰ ＩＮＶＩＴＥ又はＲＥＩＮＶＩＴＥのセッション・ディスクリプション・プロトコル（ＳＤＰ）部においてパラメータを加えるために使用されうる。）。上記時間間隔は、メディア発言権制御エンティティごとに調整される（複数のそのようなエンティティは、メディアタイプごとの１つのエンティティ、マルチメディアの場合に存在しうるが、１つのエンティティは複数のストリームを扱うことができる。）。

図２は、ＳＩＰを用いるシグナリング・プレーンにおける調整手順を示す（用語”ＣＳＣＦ”は、必要に応じて、Ｐ−ＣＳＣＦ、Ｉ−ＣＳＣＦ及びＳ−ＣＳＣＦ複素を示す。）。図２のフローチャートは以下のステップを含む。
１．ＰｏＣクライアントがＣＳＣＦにＳＩＰ ＩＮＶＩＴＥ要求を送信する。ＳＩＰ ＩＮＶＩＴＥ要求は、［ＯＭＡ−ＰｏＣ−ＣＰ］によって特定される情報と、推奨キープ・アライブ・メッセージ間隔とともに追加のｆｍｔｐとを含む。本実施形態では、この値は、２０秒に設定される。
２．ＣＳＣＦが［ＴＳ２４．２２９］において特定される機構を用いてＳＩＰ ＩＮＶＩＴＥ要求をＰｏＣ ＡＳに転送する。
３．ＰｏＣ ＡＳが受信した推奨キープ・アライブ・メッセージ間隔を評価し、ＳＩＰ ２００ ＯＫ応答の値をＳ−ＣＳＣＦに返答する。ＰｏＣ ＡＳは、ＰｏＣクライアントからのキープ・アライブ・メッセージの受信を監視するタイマを開始する。
４．ＣＳＣＦが上記２００ ＯＫをＰｏＣクライアントに転送する。ＰｏＣクライアントは、ＰｏＣサーバから受信した値に基づくタイマを開始する。タイマが満了すると、ＰｏＣクライアントは、キープ・アライブ・メッセージを送信する。
タイマ間隔は、ＰｏＣセッション中に再調整されることができ、メディア発言権制御エンティティごとに異なってもよい。

ＰｏＣクライアントが全てのセッションの場合においてＰｏＣ ＡＳに対してキープ・アライブ・メッセージを送信する必要がないことは理解されるであろう。シグナリングの負荷は、キープ・アライブ・メッセージ又はキープ・アライブ応答の何れかとしてメディアを用いることによって提言されうる。ここでメディアとは、ＰｏＣクライアントとＰｏＣ ＡＳとの間で送信されるものである。図３を参照して、３つのケースについて説明する。

ケース１）メディア発言権制御エンティティに接続されたＰｏＣクライアントの中で、現在、メディアを送信する権限を有しているＰｏＣクライアントが存在しない場合。

従来技術の解決手法によれば、当該ケースにおいて、ＰｏＣ ＡＳは、ＭＢＣＰメディア・バースト・アイドル・メッセージを所定間隔ごとに送信する。一方、本実施形態では、受信したキープ・アライブ・メッセージごとに応じてのみ、メディア・バースト・アイドル・メッセージを送信することを提案する。ＰｏＣクライアントは、キープ・アライブ・メッセージの確認応答としてメディア・バースト・アイドル・メッセージを処理し、タイマをゼロにリセットする。ＰｏＣ ＡＳにおいてキープ・アライブ・メッセージを受信する前にタイマが満了すると、ＰｏＣ ＡＳは、ＰｏＣセッションから当該ＰｏＣクライアントを取り除く。

ケース２）メディア発言権制御エンティティに接続された他のＰｏＣクライアントが、現在、メディアを送信する権限を有している場合。

ＰｏＣクライアントは、同意された時間間隔に従ってキープ・アライブ・メッセージを送信する。したがって、ＰｏＣ ＡＳは、ＰｏＣクライアントがまだ”接続状態”にあるということを認識し、当該ＰｏＣクライアントへのメディアの送信を継続する。ＰｏＣクライアントはメディアを受信し、それにより、ＰｏＣ ＡＳが最新のキープ・アライブ・メッセージを受信したことを認識する。これは、キープ・アライブ・メッセージの黙示的な確認応答を示し、ＰｏＣクライアントはタイマをゼロにリセットする。再度、キープ・アライブ・メッセージを受信することなくＰｏＣサーバのタイマが満了すると、ＰｏＣ ＡＳはＰｏＣセッションから当該ＰｏＣクライアントを取り除く。

ケース３）ＰｏＣクライアントが、現在、メディアを送信する権限を有する。

この場合、ＰｏＣクライアントはキープ・アライブ・メッセージを送信する必要がない。ＰｏＣクライアントはメディアを送信し、ＰｏＣサーバは黙示的なキープ・アライブ・メッセージとしてメディアを取り扱う。ＰｏＣ Ａｓで新たなタイマを整備する必要はない。上述したように、ＰｏＣの現在の状態に従って、ＰｏＣ ＡＳは予め定められた時間間隔のタイマを整備する。当該タイマは、満了するとＰｏＣクライアントから発言権が取り除かれる。当該タイマに加えて、ＰｏＣ技術の提案による状態によれば、ＰｏＣ ＡＳは、ＰｏＣクライアント側での接続の喪失を検知するために他のタイマを整備している。この機構は、メディアを送信する権限を有するＰｏＣクライアントからメディアが受信されるごとにタイマを開始する（ＰｏＣクライアントは、発言権を有していればメディアを毎回送信しなければならない。つまり、ユーザがしゃべっていない状態であっても、無音のＲＴＰパケットが送信される。）。メディアを受信する前にタイマが満了すると、ＰｏＣクライアントは、セッションから取り除かれる。

当業者には、本発明の範囲から逸脱することなく種々の変更が上述の実施形態に対して行われることが理解されるであろう。例えば、上述した実施形態ではＰｏＣサービスに関して記載したが、本発明は音声及び動画技術を含む他のＩＭＳサービスに対しても適用することができる。実際には、本発明は、ＳＩＰベースではあるものの非ＩＭＳに適用されてもよい。特に、本発明は半二重サービスに適用可能である。

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