JP2007529936A - 「プッシュトゥトーク」セッションを管理するための方法、サーバおよびシステム - Google Patents

Abstract

それぞれが対応する音声／画像信号の符号化および復号能力を備えた複数の端末間のウォーキートーキー（「プッシュトゥトーク」）モードのセッションを管理するための本発明の方法、サーバおよびシステム。セッションは、サーバを介して、端末が接続された第１の無線通信ネットワークおよびサーバが接続された第２のネットワークを通って複数の端末に接続される。前記サーバは、データエンコーダ／デコーダを備える。端末の要求に応じてセッションが確立されるときに、送信側端末は、初期の符号化タイプに従って符号化されたデータを、サーバを介して接続された１つまたは複数の受信側端末に送信する。その後、初期符号化タイプに従って符号化されたデータを受信するサーバは、初期符号化タイプに従って符号化されたデータと前記受信側端末によって受信されるデータとの間の互換性を保証するために、初期符号化タイプに類似の少なくとも１つのタイプの符号化に従って適用可能である場合には、受信側端末の各能力に従って前記データを処理する。その後、サーバは、処理されたデータを受信側端末に送信する。

Description

本発明の分野は、通信の分野、より厳密には、無線通信ネットワークを使用したウォーキートーキー（ｗａｌｋｉｅ−ｔａｌｋｉｅ）通信サービスの分野に関する。これらのサービスは一般に、「プッシュトゥトーク」（ｐｕｓｈ−ｔｏ−ｔａｌｋ）サービスと称される。

無線通信ネットワークでは、「プッシュトゥトーク」サービスによって、ユーザがよく知られているウォーキートーキーの原理を使用して通信することが可能となる。したがって、第１の加入者は、事前にリストされた１人または複数のユーザと単に端末上のボタンを押すことによってウォーキートーキーモードで即座に通信することができる。他のユーザには、キーを操作する必要なしに、その端末上で第１ユーザの音声が聞こえる。

したがって、「プッシュトゥトーク」サービスを使用してモバイルネットワークのユーザは、電話番号をダイヤルさえすることなく瞬時に一群の人々と接触することができる。ユーザは、セッションに参加する１つまたは複数の受信側端末に同時にメッセージを送信することができる。従来、それらに情報を送信するには、端末画面上に表示されたリストから１つまたは複数の相手を選択し、キーを押すことで十分である。端末は、このようにウォーキートーキーへと姿を変えた電話になる。

したがって、開始側端末が、１つまたは複数の端末が参加する「プッシュトゥトーク」セッションを開始することは非常に単純であり、これらの端末は以下「参加側端末」と称される。以下で述べる数個のステップにより、開始側端末と参加側端末の間のセッションが確立される。セッションに参加する端末のうちの１つだけが、所与の任意のときに送信することを許可される。送信許可は、要求に応じて端末に割り当てられ、送信の許可を受けた端末は以下「送信側端末」と称される。セッションに参加する他の端末は、送信側端末からデータを受信し、以下「受信側端末」と称される。

一般的な規則として、接続された受信側端末は従来、発信音によって警告を受け、発信音の直後に、送信側端末によって送信された情報を受信する。

「プッシュトゥトーク」セッションで送信されるデータは、たとえば音声データであり、または画像データ、具体的にはビデオデータであり得る。

「プッシュトゥトーク」通信が単純であり、低コストであることにより、オペレータは、たとえばタクシー運転手などの専門家ユーザ向けに非常に魅力的かつ非常に実用的なサービスを提供することができる。他の応用領域は、スキー場やテーマパークなどの広大なエリアでゲームおよび娯楽活動に参加している家族または友人の間の通信である。

「プッシュトゥトーク」サービスは、通常「プッシュトゥトーク」サーバと呼ばれるサーバによって制御され、このサーバは、「プッシュトゥトーク」セッションの設定、送信の許可、および送信側端末から受信側端末へのデータ転送に関与する。

しかし、端末が各々の音声および／または画像信号の符号化および復号能力を有する場合に、サーバおよび少なくとも１つの通信ネットワークを介して端末を接続するウォーキートーキーモードセッションを管理することにおいて現在問題が生じている。

この状況では、設定されるセッションの特定の側面、具体的にはデータ送信に使用される符号化のタイプを定めるパラメータが、呼び出された第１の端末と折衝される。したがって、開始側端末は、送信されるデータを符号化するため、セッション設定時に応答した第１端末と共通して有する符号化および復号能力に応じて決定される符号化のタイプを使用する。複数の端末がセッションに参加するよう呼び出される場合は、第２の端末は、それが開始側端末によって送信されるデータを復号することを可能にする符号化および復号能力を有していないことがある。この場合、第２端末は、受信された情報を復号することができない。

さらに、参加側端末は、送信許可を受ける場合に、接続された他の端末とは互換性のない符号を使用することがある。

新しい参加者が確立されたセッションにログオンするときにも問題が生じる。この状況では、セッションに既にログオンしている端末は、新しい参加側端末の符号化および復号能力を知らない。したがって、既に接続されている端末は、新しい参加側端末の符号化および復号能力と互換性のない符号タイプを使用することがある。

本発明は、この状況を改善する。

本発明の第１の態様は、それぞれのデータ符号化および復号能力を有する複数の端末間のウォーキートーキー（「プッシュトゥトーク」）モードセッションを管理する方法であって、前記セッションがウォーキートーキーモードセッション管理サーバおよび少なくとも１つの通信ネットワークを介して複数の端末を接続し、セッションが確立された後に、
送信側端末が初期の符号化タイプを使用して符号化されたデータをサーバを介して接続された複数の受信側端末に送信し、
サーバが、初期符号化タイプを使用して符号化されたデータを受信し、受信側端末のそれぞれの能力と初期符号化タイプとの互換性をチェックし、
サーバが初期符号化タイプと受信側端末のうちの少なくとも１つの端末の能力との間の非互換性を検出した場合、前記受信側端末がデータを復号することができるように、サーバが前記受信側端末へのデータ転送の前にデータの符号化を前記受信側端末の能力と互換性のある符号化タイプに適応させる方法を提供する。

本発明の第２の態様は、動作において上記で定義された方法のステップを実行することにあるサービスであって、少なくとも１つの通信ネットワークによってサポートされており、同じセッションにログオンした複数の端末によって実施されるためのウォーキートーキー（「プッシュトゥトーク」）モードセッションを管理するためのサービスを提供する。

本発明の第３の態様は、上記で定義された方法を実施する手段を備える、ウォーキートーキー（「プッシュトゥトーク」）モードセッションを管理するためのサーバを提供する。

本発明の第４の態様は、上記で定義された方法を実施する手段を備える、ウォーキートーキー（「プッシュトゥトーク」）モードセッションを管理するためのシステムを提供する。

本発明の第５の態様は、特定のシグナリングプロトコルによって定義されたメッセージをサポートしており、ウォーキートーキーモードのセッションに端末をログオンさせる機能を有する、端末からウォーキートーキーモードのセッションを管理するためのサーバに送信されるデータストリームであって、前記メッセージが前記端末の符号化および復号能力を含むことを特徴とするデータストリームを提供する。

上記装備（ｐｒｏｖｉｓｉｏｎ）を用いて、ＵＭＴＳネットワークは、端末の能力に適するように適応する「プッシュトゥトーク」サービスを提供することができる。

米国特許出願第２００４／００３２８４３号明細書は、所与のタイプの符号化を使用して符号化された音声データを送受信することができるＣＤＭＡデジタルモバイル端末と、アナログ無線信号を送受信するように構成されており、データ符号化および復号能力をもたない１つまたは複数のアナログ無線端末との間の「プッシュトゥトーク」セッションを管理する方法について記載している。ＣＤＭＡ端末と無線端末の間で「プッシュトゥトーク」セッションを設定した後に、ゲートウェイサーバは、ＣＤＭＡ端末から来る符号化されたデータを無線端末に送信されるアナログ無線信号に、また１つまたは複数の無線端末から来るアナログ無線信号をＣＤＭＡモバイル端末に送信される音声符号化されたデータに変換する。音声符号化されたデータからアナログ無線信号へのデジタルアナログ変換は、ゲートウェイサーバによって系統立てて行われる。すべての無線受信側端末は、ゲートウェイサーバによってブロードキャストされた同じアナログ無線信号を捕らえ、したがって、このゲートウェイサーバは、データが向けられている受信側端末の特定の能力に応じたデータ符号化の適応を行わない。ゲートウェイサーバは、すべての無線受信側端末について同じである、音声符号化されたデータから無線信号へのデジタルアナログ変換を単純に行う。米国特許出願第２００４／００３２８４３号明細書に記載された「プッシュトゥトーク」サービスは、受信側端末の能力に適するようには全く適応しない。

本発明の他の態様、目的および利点は、本発明の一実施形態についての説明を読むと明らかになる。

本発明は、図面を考慮してよりよく理解されることもできる。

ＩＭＳ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ：インターネットプロトコルマルチメディアサブシステム）を取り入れたＵＭＴＳ第５版について以下で述べる。そのアーキテクチュアの主な進化は、ＵＭＴＳネットワーク７（図１）のデータトランスポートパケット交換ドメインとトランスポート制御機構を組み込んだＩＰ（インターネットプロトコル）ネットワーク８との相関関係からもたらされる。

ＵＭＴＳの第５版向けに標準化されたＩＭＳネットワークのアーキテクチュアについて、図１を参照して次に述べる。ＩＭＳ（インターネットプロトコルマルチメディアサブシステム）と呼ばれるＵＭＴＳ第５版用のＩＰアーキテクチュアの中核は、ＩＭＳネットワーク内のマルチメディアセッションを制御し、アプリケーションサーバなどのＩＭＳネットワークの他のエンティティと対話するＣＳＣＦ（Ｃａｌｌ Ｓｔａｔｅ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ：呼状態制御機能）機器４、５および６からなる。ＩＭＳネットワークアーキテクチュアには、複数のタイプのＣＳＣＦ機器がある。

Ｐ−ＣＳＣＦ（プロキシ−ＣＳＣＦ）モジュール４。ＩＭＳ内の端末にとっての第１の接触点であり、これらのエンティティはＰＤＦタイプのリソース制御機能を有する。

Ｓ−ＣＳＣＦ（サービス−ＣＳＣＦ）モジュール５。端末がＩＭＳに登録している期間を通して端末のセッションを制御する。

Ｉ−ＣＳＣＦ（問合せ−ＣＳＣＦ）モジュール６。ネットワークのユーザと、同じタイプの別のネットワークのユーザとの間のマルチメディアセッションのためのこの類のネットワーク８への入口点。

ネットワーク要素９、すなわちＨＳＳ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ：ホーム加入者サーバ）は、ＨＬＲ（Ｈｏｍｅ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ：ホームロケーションレジスタ）の形でＵＭＴＳ第５版に取り入れられており、マルチメディアＩＰドメインに関する機能をも有する。換言すると、ネットワーク要素ＨＳＳは、マルチメディアＩＰドメインユーザのデータベースをも含む。Ｓ−ＣＳＣＦモジュール５は、ＨＳＳネットワーク要素９とインターフェースする。

端末１、ＣＳＣＦ機器４、５および６、ならびにアプリケーションサーバは、セッション開始プロトコル（ＳＩＰ：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を使用する。この類のアーキテクチュアでは、ＳＩＰセッションが、マルチメディアサービス向けのパケットトランスポートセッションを設定するのに使用される。ＩＰドメイン８とＵＭＴＳパケット交換ドメイン７のノードは、リソースを供給するトランスポート層とトランスポート層によってユーザに提供されるリソースを制御するアプリケーション層との間に相関関係があるようにリンクされる。したがって、ＩＭＳネットワークのアーキテクチュアは、リソース制御を提供する。ＵＭＴＳ第５版のための規格は、この類のアーキテクチュア内、具体的にはＩＭＳ８に登録したＵＭＴＳネットワーク７の端末１と、別の端末またはＩＰネットワーク内に登録したアプリケーションサーバとの間の通信セッションの設定を標準化するものである。

したがって、端末は、ＩＭＳドメイン内のセッションを設定するためにＳＩＰを使用する。まずそれは、とりわけセッションを管理するＰ−ＣＳＣＦモジュールおよびＳ−ＣＳＣＦモジュールの決定のために、ＩＭＳドメインに登録する。端末は、ＩＭＳドメインに登録すると、図２に示すように「ＩＮＶＩＴＥ」手順を使用して１つまたは複数の他の端末とセッションを開始することができる。

図２は、ＵＭＴＳネットワークとインターネットプロトコルネットワークの様々なエンティティ間のメッセージ交換を示している。パケット交換ネットワーク７およびＩＭＳネットワークのユーザである端末１は、ネットワーク８に登録する。当業者によく知られているこの手順については、本明細書で述べない。ここでの説明では、端末１が既にネットワーク８に登録していると想定する。したがって、端末は、データ送信セッションを設定する許可を受けており、ＳＩＰ「ＩＮＶＩＴＥ」メッセージ２１をＳＧＳＮネットワーク要素２に送信することによってセッションの設定を開始し、このＳＧＳＮネットワーク要素はメッセージをＧＧＳＮネットワーク要素３に転送し、このＧＧＳＮネットワーク要素はそれをＰ−ＣＳＣＦネットワーク要素４に転送し、このＰ−ＣＳＣＦネットワーク要素はメッセージをＳ−ＣＳＣＦネットワーク要素５に転送し、このＳ−ＣＳＣＦネットワーク要素は最終的に、アプリケーションサーバまたは端末であり得る受信側にそれを転送する。メッセージ２１は、設定されているセッションの特定の側面を定める端末１によって要求されたパラメータを含む。パラメータは、セッションの間に送信されるメディアのタイプ（たとえばビデオ、オーディオなど）を示すことがあり、またポートを示すこともでき、このポートは、端末がデータおよび使用されるコーデックを受信したいと望む所であり、またメディアタイプ、またはセッションを特徴付ける他のパラメータに従って選択され得る。これらのパラメータは従来、ＳＤＰを使用してＳＩＰ「ＩＮＶＩＴＥ」メッセージ２１で送信される。

受信側が「ＩＮＶＩＴＥ」メッセージを受信するときに、端末１によって要求されたパラメータと受信側の能力とが比較される。この比較から、受信側は交渉されたパラメータを推論し、次いでそれはこのパラメータを、メッセージ２１に応答して送信されるＳＩＰ「１８３セッション進行」メッセージ２２として端末１に送信する。メッセージ２２は、連続したネットワーク要素Ｓ−ＣＳＣＦ、Ｐ−ＣＳＣＦ、ＧＧＳＮおよび最後にＳＧＳＮを介して端末１に送信される。

ＳＩＰ「１８３セッション進行」メッセージ２２に応答して端末１は、受信側と開始側端末１とに共通のパラメータを含む「ＰＲＡＣＫ」メッセージ２３を送信する。

次いで、端末１は、ＧＧＳＮネットワーク要素３に、設定されているセッションのためにパケット交換ＵＭＴＳネットワーク内のデータ移送に必要な送信リソース２４を予約するよう要求する。

最後に、ＳＩＰ「ＰＲＡＣＫ」メッセージ２３を受信すると、データ送信セッションが設定される。ＳＩＰ「２００ ＯＫ」メッセージ２５は、端末１にこれについて知らせる。

本発明の好ましい一実施形態では、ＵＭＴＳネットワーク内の「プッシュトゥトーク」サービスのアーキテクチュアは、その原理が上記で述べられているＩＭＳアーキテクチュアに基づく。そのアーキテクチュアについて、図３を参照して以下に述べる。

図３では、第１、第２および第３端末３１、３２、３３が、パケット交換ＵＭＴＳネットワーク７に接続されている。「プッシュトゥトーク」サーバ３０が、ＩＭＳドメイン内に取り入れられている。

したがって、本発明の一実施形態は、「プッシュトゥトーク」セッションを設定することができ、また各受信側端末への送信が許可された端末から受信される符号化されたデータの送信を、送信側端末から受信されたデータに使用された符号化のタイプ、および受信側端末のそれぞれの符号化および復号能力に応じて管理し適応することができる「プッシュトゥトーク」サーバを上述のアーキテクチュアに取り入れる。

この類のデータ送信適応を実現するには、サーバは、セッションにログオンした各端末の符号化および復号能力を知ることが好ましい。このため、以下でより詳細に述べるようにサーバは、セッション設定時、端末間のメッセージ交換中に、セッションにログオンした端末の各符号化および復号能力を格納する。しかし、本発明は、セッションにログオンした端末の各符号化および復号能力をサーバが格納するための他の任意のやり方を包含するものである。

本発明のある実施形態では、「プッシュトゥトーク」サーバは有利には、受信されたデータが各受信側端末が復号できるやり方で符号化されているかどうか決定するために、「プッシュトゥトーク」サーバが受信側端末のそれぞれについて受信されたパケットからペイロードデータを抽出する（トランスポートヘッダを削除する）ため受信されたパケットを処理することを可能にする機能を組み込む。「プッシュトゥトーク」サーバは、受信側端末が送信側によって符号化されたデータを復号できない場合には、受信側端末が送信されたデータを復号できるようにそれを再符号化することによって、送信されたデータの符号化を適応させる。

本発明の好ましい一実施形態では、「プッシュトゥトーク」サーバは有利には、「プッシュトゥトーク」セッションに関与する端末の能力に従って受信データの適応符号化を行うように構成されたコーダ／デコーダを含む。

この適応符号化の後に「プッシュトゥトーク」サーバは、適応符号化がそのために行われた端末に再符号化されたデータを転送する前に、それぞれの再符号化されたデータパケットについてトランスポートヘッダを追加する。

本発明の一実施形態では、コーデックは、ＡＭＲ（ａｄａｐｔｉｖｅ ｍｕｌｔｉｒａｔｅ：適応マルチレート）コーデックである。ＡＭＲコーデックは従来は、それぞれ異なるビットレートを定めた８つの異なるモードで動作する。したがって、開始側端末は、それがサポートするＡＭＲコーデックモードを要求されたパラメータで示す。ＡＭＲコーデックはここでは例示するために参照されており、本発明は当然、他のタイプのコーデックを包含するものである。

本発明の一実施形態では、ＳＩＰ「プッシュトゥトーク」セッションが設定され、送信がリアルタイム制御プロトコル（ＲＴＣＰ：Ｒｅａｌ Ｔｉｍｅ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）に従って許可される。

図４は、この類の本発明の一実施形態を示している。

図４で、端末３１は、「プッシュトゥトーク」サービスのパラメータ、たとえば開始側端末の符号化および復号能力（すなわち開始端末が使用することができるコーデック）を好ましくは含むＳＩＰ「ＩＮＶＩＴＥ」メッセージ４０１を「プッシュトゥトーク」サーバ３０に送信することによって「プッシュトゥトーク」セッションを開始している。これらのパラメータは好ましくは、ＳＤＰを使用して送信される。

「プッシュトゥトーク」サーバ３０は、メッセージ４０２および４０３で、このＳＩＰ「ＩＮＶＩＴＥ」メッセージを「プッシュトゥトーク」セッションに参加する端末３２、３３に送信する。

サーバは好ましくは、「ＩＮＶＩＴＥ」メッセージ４０１内に含まれる開始側端末の符号化および復号能力を格納する。

参加側の端末３２、３３は、それぞれのＳＩＰ「２００ ＯＫ」メッセージ４０４および４０９で「プッシュトゥトークサーバ」３０に応答し、これらのメッセージは好ましくは、それぞれの参加側端末３２および３３によってサポートされるメディアタイプ、ならびに符号化および復号タイプについての記述をも含む。この類の記述は、ＳＤＰを使用して送信され得る。

ＳＩＰ「２００ ＯＫ」メッセージを受信すると、サーバは好ましくは、端末の符号化および復号能力を格納する。

さらに、ここでは参加側端末３２によって送信された「２００ ＯＫ」メッセージ４０４である第１のＳＩＰ「２００ ＯＫ」メッセージが受信されるとすぐに、サーバ３０は、開始側端末が送信することを許可するために、それにＲＴＣＰメッセージ４０５を送信する。次いで、サーバは、応答した第１参加側端末の符号化および復号能力を開始側端末３１に伝えるＳＩＰ「２００ ＯＫ」メッセージ４０６を開始側端末３１に送信する。

次いで、サーバは、応答した参加側端末３２に、それが送信許可を受けたことを伝えるＲＴＣＰメッセージ４１１を送信する。

他の参加側端末３３は、それ自体の符号化および復号能力を含むＳＩＰ「２００ ＯＫ」メッセージ４０９を「プッシュトゥトーク」サーバ３０に送信することによってＳＩＰ「ＩＮＶＩＴＥ」メッセージに応答する。「プッシュトゥトーク」サーバ３０は、参加側端末３３の符号化および復号能力を格納し、それにＲＴＣＰメッセージ４１２を送信する。

次いで、「プッシュトゥトーク」セッションを開始する端末は、「プッシュトゥトーク」サーバ３０から、それに参加側端末３２、３３の接続について知らせる通知メッセージ４０８および４１０を受信する。

送信の許可を受けた開始側端末は、送信されるデータを符号化するときに、ＳＩＰ「ＩＮＶＩＴＥ」メッセージに最初に応答した参加側端末３２と共有している符号化タイプであって、またプッシュトゥトークサーバ３０から受信されたＳＩＰ「２００ ＯＫ」応答メッセージ４０６内に示されていた符号化タイプから、初期符号化タイプを選択する。次いで、開始側端末は、符号化されたデータ４１５を送信する。

データは好ましくは、リアルタイムプロトコル（ＲＴＰ）を使用して送信される。

サーバは、符号化されたデータ４１５を受信し処理する。それは、受信側端末の各能力の、送信側端末によって使用された初期符号化タイプに対する互換性をチェックする。このチェックは、接続された端末の符号化および復号能力に関する格納された情報に基づく。

このチェックによって、サーバは、受信側端末３２の能力が、送信側端末３１によって使用された初期符号化タイプと互換性があることを検出する。したがって、サーバは、受信されたとおりの、すなわち初期符号化タイプを使用して符号化されたデータ４１５を転送する。

それとは異なり、サーバは、受信側端末３３の符号化および復号能力と、送信側端末３１によって使用された初期符号化タイプとの間に非互換性を検出した場合は、受信された各データパケットについて以下のように進む。
それは、パケット内に含まれるペイロードデータを抽出する（すなわちそれは、以下のプロトコル層：ＲＴＰ、次いでＵＤＰ（ユーザデータグラムプロトコル）、次いでＩＰ（インターネットプロトコル）に一般に対応するトランスポートヘッダを削除する）。
それは、端末３３の格納能力と互換性のある符号化タイプを選択する、
それは、選択された符号化タイプを使用してパケットからのペイロードデータを符号化する、
それは、トランスポートヘッダを追加する、
それは、受信側端末３３にパケットを転送する。

線４１６は、サーバによって選択された符号化タイプを使用して、符号化されたデータを参加側端末３３に送信することを表している。

従来技術の「プッシュトゥトーク」サービスでは、サーバは、符号化タイプ、ならびに端末３１から受信された初期符号化タイプを使用して符号化され、したがって初期符号化タイプを使用して符号化されて参加側端末３２および３３に転送されるデータのどんな適応をも行わないことに留意されたい。したがって、参加側端末３３は、それを復号することができない。

送信する開始側端末は、送信を終了するときに、それが送信を終了したことを示すためにＲＴＣＰ「解放」メッセージ４１７を送信する。このメッセージを受信すると「プッシュトゥトーク」サーバは、各参加側端末４１８、４１９に、それらが送信許可を要求し得ることを知らせるためにＲＴＣＰ「アイドル」メッセージを送信する。

したがって、送信を許可される参加側端末が、サーバを介してセッションにログオンしている他の端末にデータを送信するときに、サーバは続いて、送信データの符号化タイプを上述したように適応させる。

本発明の一実施形態では、新しい端末は、確立された「プッシュトゥトーク」セッションに参加したいと望む場合、それがサポートする符号化タイプを含むＳＩＰ「ＩＮＶＩＴＥ」メッセージを「プッシュトゥトーク」サーバに送信する。したがって、サーバは、新しい端末に符号化されたデータを送信するために、接続された新しい端末の符号化および復号能力を上述したように格納する。

したがって、本発明の一実施形態は、単純であり、非常に柔軟な、適応性の高い「プッシュトゥトーク」サービスを提供する利点を有する。それによって、端末が互換性のない符号化および復号能力を有する場合でも、端末レベルで機能を取り入れる必要なしに端末が通信することが可能となる。

さらに、本発明の一実施形態はしたがって、ＵＭＴＳ９９、４、５、６版以下によるネットワーク内において使用するのが容易である。

ＵＭＴＳの第５版向けに標準化されたＩＭＳマルチメディアＩＰネットワークのアーキテクチュアを示す図である。 図１に示すものなどのアーキテクチュア内でセッションを設定するためのメッセージ交換を示す図である。 「プッシュトゥトーク」セッションを管理するためのネットワークアーキテクチュアを示す図である。 本発明の一実施形態による、「プッシュトゥトーク」データ送信セッションを管理するための様々なネットワーク要素間のメッセージ交換を示す図である。

Claims (14)

1. それぞれのデータ符号化および復号能力を有する複数の端末間でウォーキートーキー（「プッシュトゥトーク」）モードセッションを管理する方法であって、前記セッションがウォーキートーキーモードセッション管理サーバおよび少なくとも１つの通信ネットワークを介して複数の端末を接続し、セッションが確立された後に、
   送信側端末が、初期符号化タイプを使用して符号化されたデータを、サーバを介して接続された複数の受信側端末に送信し、
   サーバが、初期符号化タイプを使用して符号化されたデータを受信し、受信側端末のそれぞれの能力と初期符号化タイプとの互換性をチェックし、
   サーバが初期符号化タイプと受信側端末のうちの少なくとも１つの端末の能力との間の非互換性を検出した場合、前記受信側端末がデータを復号することができるように、サーバが前記受信側端末へのデータ転送の前にデータの符号化を前記受信側端末の能力と互換性のある符号化タイプに適応させる、方法。
2. サーバが、セッションにログオンした端末の符号化および復号能力を格納する、請求項１に記載の方法。
3. 端末間のセッションが、サーバの仲介を介して特定のシグナリングプロトコルを使用した事前定義されたメッセージの交換によって確立され、前記セッションにログオンする端末が、セッションを確立する間にサーバと交換される前記メッセージでその符号化および復号能力をサーバに送信する、請求項２に記載の方法。
4. セッションが確立されているときに新しい端末がセッションへの参加を望む場合、セッションにログオンするために、該新しい端末の符号化および復号能力を含む事前定義されたメッセージを前記シグナリングプロトコルを使用してサーバに送信する、請求項３に記載の方法。
5. 前記特定のシグナリングプロトコルがセッション開始プロトコル（ＳＩＰ）であり、開始側端末の要求に応じて少なくとも１つの参加側端末とセッションを確立することが、
   開始側端末が、前記開始側端末の符号化および復号能力を含むＳＩＰ「ＩＮＶＩＴＥ」メッセージをサーバに送信するステップと、
   開始側端末から「ＩＮＶＩＴＥ」メッセージを受信するとサーバが参加側端末にＳＩＰ「ＩＮＶＩＴＥ」メッセージを送信するステップと、
   サーバからの「ＩＮＶＩＴＥ」メッセージに応答して参加側端末が、その符号化および復号能力を含むＳＩＰ「２００ ＯＫ」メッセージをサーバに送信することを備える、請求項３に記載の方法。
6. 新しい端末が確立されているセッションへの参加を望む場合、該新しい端末がサーバにその符号化および復号能力を含む「ＩＮＶＩＴＥ」メッセージを送信する、請求項５に記載の方法。
7. セッションにログオンした端末によってサポートされる符号化タイプが適応マルチレート（ＡＭＲ）コーデックのモードに対応する、請求項１に記載の方法。
8. セッションにログオンした端末のそれぞれの符号化および復号能力が、ＳＤＰを使用してサーバに送信される、請求項１に記載の方法。
9. 動作において請求項１に記載の方法のステップを実行することにあるサービスであって、少なくとも１つの通信ネットワークによってサポートされており、同じセッションにログオンした複数の端末によって実施されるための、ウォーキートーキー（「プッシュトゥトーク」）モードセッションを管理するためのサービス。
10. 請求項１に記載の方法を実施する手段を備える、ウォーキートーキー（「プッシュトゥトーク」）モードセッションを管理するためのサーバ。
11. 請求項１に記載の方法を実施する手段を備える、ウォーキートーキー（「プッシュトゥトーク」）モードセッションを管理するためのシステム。
12. 特定のシグナリングプロトコルによって定義されたメッセージをサポートしており、ウォーキートーキーモードのセッションに端末をログオンさせる機能を有する、端末によってウォーキートーキーモードのセッションを管理するためのサーバに送信されるデータストリームであって、前記メッセージが前記端末の符号化および復号能力を含むことを特徴とする、データストリーム。
13. サポートされるメッセージがセッション開始プロトコル（ＳＩＰ）によって定義される、請求項１２に記載のデータストリーム。
14. サポートされるメッセージが「ＩＮＶＩＴＥ」メッセージまたは「２００ ＯＫ」メッセージである、請求項１３に記載のデータストリーム。

Images