JP2014150584A - マルチメディアセッションのためのマルチユーザリアルタイムトランスコーディングシステムおよび方法 - Google Patents

マルチメディアセッションのためのマルチユーザリアルタイムトランスコーディングシステムおよび方法 Download PDF

Info

Publication number
JP2014150584A
JP2014150584A JP2014093620A JP2014093620A JP2014150584A JP 2014150584 A JP2014150584 A JP 2014150584A JP 2014093620 A JP2014093620 A JP 2014093620A JP 2014093620 A JP2014093620 A JP 2014093620A JP 2014150584 A JP2014150584 A JP 2014150584A
Authority
JP
Japan
Prior art keywords
transcoding
session
terminal
media
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2014093620A
Other languages
English (en)
Other versions
JP5749375B2 (ja
Inventor
Coulombe Stephane
ステファン・コロンブ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Vantrix Corp
Original Assignee
Vantrix Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vantrix Corp filed Critical Vantrix Corp
Publication of JP2014150584A publication Critical patent/JP2014150584A/ja
Application granted granted Critical
Publication of JP5749375B2 publication Critical patent/JP5749375B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/4061—Push-to services, e.g. push-to-talk or push-to-video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/104—Signalling gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/10—Push-to-Talk [PTT] or Push-On-Call services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/30—Connection release
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • H04W88/181—Transcoding devices; Rate adaptation devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】プッシュツートークオーバーセルラー(PoC)マルチメディアセッションのためのマルチパーティリアルタイムトランスコーディング方法を提供することである。
【解決手段】ユーザを前記通信セッションに参加するよう招待する段階と、前トランスコーディングサーバを通じて前記トランスコーディングセッションを設定するために中央ネットワーク要素から要求を受信する段階、トランスコーディングセッションを設定する段階と、前記トランスコーディングセッションに従って通信セッション記述を確立する段階であって、前記通信セッション記述は、少なくとも一つの端末の少なくとも一つのメディア特性を含む段階と、前記トランスコーディングサーバを通じてフローするメディアストリームを、トランスコードし、前記トランスコードされたメディアストリームを他の端末に伝送する段階と、を含む方法。
【選択図】図３

Description

関連出願の相互参照
本出願は、本明細書にその全体が組み込まれている、2005年12月28日に出願された「REAL-TIME TRANSCODING ARCHITECTURE FOR PoC」と題する米国仮出願第60/754194号の利益を主張するものである。
本発明は、一般に、マルチユーザ通信セッションを確立するためのシステムおよび方法に関する。より詳細には、限定はしないが、本発明は、プッシュツートークオーバーセルラーマルチメディアセッションのためのマルチパーティリアルタイムトランスコーディングシステムおよび方法に関する。
プッシュツートークオーバーセルラー(PoC)サービスは、モバイルユーザが、参加者が一対一または一対多ベースで音声およびデータ通信を行うことができるグループセッションを作成することを可能にする[1]。この音声通信は、端末が専用の「トーク」ボタンを有するウォーキートーキーサービスに似ている。一度に話せるのは1人だけであり、それぞれのトークバーストは比較的短く、たとえば、数秒間続く。ユーザは、インスタントメッセージを交換することもできる。近いうちにトークバーストは、音声およびビデオストリームのバーストへと進化し、インスタントメッセージは、音声、ビデオ、テキスト、アニメーション、等のリッチメディアコンテンツを含むようになるであろう。
プッシュツートークオーバーセルラー(PoC)サービス仕様は、Open Mobile Alliance (OMA)によって定義されている。この仕様は、Third Generation Partnership Project (3GPPまたは3GPP2) Internet Protocol Multimedia Subsystem (IMS)アーキテクチャのSession Initiation Protocol (SIP)に基づいている。さらに詳細には、PoCサービスは、3GPP IP Multimedia Sub-system (IMS)[4、5]または3GPP2 IMS[6、7]の仕様を満たすことができるSIP/IPコアの上位に構築されている。
汎用的な事例のための全体的PoCアーキテクチャは、複数のPoCクライアントを含み、それらの各クライアントは、(独自のネットワーク上で)独自のPoC参加機能に接続され、中央のPoC制御機能によって制御される共通セッションに参加する。すべてのPoC機能は、中央のPoC制御機能に接続される。
PoC制御機能は、任意の所与の時点でトーク許可を有するユーザ(すなわち、視聴覚メディアパケットまたはマルチメディアパケットを送信する許可を有するユーザ)を管理する役割と、1つの送信元から複数の宛先にメディアパケットをコピーする役割とを担うということに留意することが重要である。PoC参加機能は、これらの操作を実行できない。
端末およびネットワークが多様であるため、相互運用性の問題が発生している。たとえば、3GPPでは、PoCサービスにおける既定のスピーチコーデックとして、AMR (Adaptive Multi-Rate)狭帯域スピーチコーデックを使用することを義務付けている[2]。3GPPではまた、PoCクライアントが実装されているユーザ機器が16kHzのサンプリング周波数をスピーチに使用する場合、AMR広帯域スピーチコーデックをサポートすることを義務付けている。他方、3GPP2では、EVRC (Enhanced Variable Rate Codec)スピーチコーデックを既定のスピーチコーデックとして義務付けている[3]。したがって、AMR音声コーデックおよびEVRC音声コーデックをそれぞれサポートする3GPP PoC端末および3GPP2 PoC端末は、互換性がないために、PoCセッションを共に確立することはできない。同様の非互換性は、ビデオおよびメディアを含むインスタントメッセージについて発生することが予想される。この問題を解決するには、トランスコーディングが必要である。トランスコーディングは、各参加者の端末機能を満たすために、ネットワーク要素内で、あるフォーマットから別のフォーマットに変換することを可能にする。
PoCサービスは3GPP/3GPP2 IMS SIP/IPコアの上位に構築されるため、メディアは、通信目的でH.248/MGCP (Media Gateway Control Protocol)プロトコル[9〜11]を使用するMRFC/MRFP (Media Resource Function Controller/Media Resource Function Processor)[4、8]によって制御および処理される。しかし、これらの仕様はきわめて複雑であり、それらのプロトコルに準拠するソリューションを開発するには、膨大な労力を要する。さらに、H.248/MGCPは、複雑で高コストであるために批判や異議が唱えられており、またH.248/MGCPは、SIPベースではない唯一のIMS主要システムコンポーネントである。それらの理由により、PoCアプリケーションにおけるトランスコーディングの問題を、MRFC/MRFPおよびH.248/MGCPに制限されない、より汎用的なフレームワークを用いて解決するニーズが存在する。さらに、MRFC/MRFPの機能およびインターフェイスは、明確に定義されてはいるが、それらのPoCコンテキストでの利用法は定義されていない。
PoC標準では、トランスコーディングの必要性は認識されているが、詳細なソリューションは提供されていない。[1]では、トランスコーディングは、PoC制御機能(CPF)および/またはPoC参加機能(PPF)の両方により実行しうると述べられており、それ以上の詳細は述べられていない。したがってさまざまな構成および使用事例をサポートするトランスコーディングアーキテクチャを開発することが重要である。一部の事例では、既に配備されたPoC機器と連動しかつ適合することができるように、トランスコーディングを透過的な態様で追加することも非常に望ましい。
要約すれば、PoCコンテキストでトランスコーディングをサポートする汎用ソリューションに対するニーズが存在する。このソリューションは、3GPP、3GPP2およびOMAなどの標準スキームに受け入れられまた統合されるように、既存のPoCアーキテクチャおよびプロトコルとの互換性を備えている必要がある。さらに、このソリューションは、さまざまな機器配備シナリオおよび制約に適用できる柔軟性を備えている必要がある。
したがって、本発明の非制限的な目的は、プッシュツートークオーバーセルラー(PoC)マルチメディアセッションのためのマルチパーティリアルタイムトランスコーディングシステムおよび方法を提供することである。
さらに詳細には、本発明により、互換性のないメディア特性を有する端末間で、セッション記述を有するマルチユーザ通信セッションを確立するための方法であって、互換性のないメディア特性を有する端末を備えるユーザを通信セッションに参加するよう招待する段階と、招待を受諾したユーザの端末に関する情報に基づいて、端末の互換性のないメディア特性間でのトランスコーディングを可能にするトランスコーディングセッションを設定する段階であって、この情報はユーザの端末のメディア特性を含む段階と、トランスコーディングセッションに従ってセッション記述を確立する段階と、通信セッション中に、1人のユーザの端末からのメディアストリームを、トランスコーディングセッションに従ってトランスコードし、トランスコードされたメディアストリームを、セッション記述に従って、通信セッションに参加している他のユーザにそれらの他のユーザの端末のメディア特性を使用して伝送する段階とを含む方法が提供される。
本発明はまた、互換性のないメディア特性を有する端末間で、セッション記述を有するマルチユーザ通信セッションを確立するためのシステムであって、互換性のないメディア特性を有する端末を備えるユーザを通信セッションに参加するよう招待する手段と、招待を受諾したユーザの端末に関する情報に基づいて、端末の互換性のないメディア特性間でのトランスコーディングを可能にするトランスコーディングセッションを設定する手段であって、この情報はユーザの端末のメディア特性を含む手段と、トランスコーディングセッションに従ってセッション記述を確立する手段と、通信セッション中に、1人のユーザの端末からのメディアストリームを、トランスコーディングセッションに従ってトランスコードし、トランスコードされたメディアストリームを、セッション記述に従って、通信セッションに参加している他のユーザにそれらの他のユーザの端末のメディア特性を使用して伝送する手段とを含むシステムに関する。
本発明はさらに、互換性のないメディア特性を有する端末間で、セッション記述を有するマルチユーザ通信セッションを確立するためのシステムであって、互換性のないメディア特性を有する端末を備えるユーザを通信セッションに参加するよう招待するためのネットワーク要素と、招待を受諾したユーザの端末に関する情報に基づいて、端末の互換性のないメディア特性間でのトランスコーディングを可能にするトランスコーディングセッションを設定するためのトランスコーディングサーバであって、この情報はユーザの端末のメディア特性を含むトランスコーディングサーバを含み、このトランスコーディングサーバは、トランスコーディングセッションに従ってセッション記述を確立し、また通信セッション中に、このトランスコーディングサーバは、1人のユーザの端末からのメディアストリームを、トランスコーディングセッションに従ってトランスコードし、トランスコードされたメディアストリームを、セッション記述に従って、通信セッションに参加している他のユーザにそれらの他のユーザの端末のメディア特性を使用して伝送するシステムに関する。
本発明の前述および他の目的、利点および機能は、添付の図面を用いてほんの一例として示された、本発明の例示的実施形態の以下の非制限的な説明を読むことでさらに明らかになるであろう。
PoCアーキテクチャ内での音声伝送を用いた「一対多」グループセッションを示す概略図である。 汎用的なPoCアーキテクチャを示す図である。 本発明の第1の非制限的な例示的実施形態によるトランスコーディングを用いたPoCアプリケーションの高レベルアーキテクチャを示す図である。 セッションの設定時にSIP INVITE要求内に含まれるSDPセッション記述を示す図である。 適正な通信セッションを保証するというPoCアプリケーションにおけるCPFの役割を示す概略図（実施例Ａでは、CPFはトランスコーディングをサポートしておらず、実施例Ｂでは、CPFはトランスコーディングをサポートしている）である。 CPFで中央集約化され、すべてのメディアパケットが図3のアーキテクチャ内のTS(トランスコーディングサーバ)の前にCPFに到達するトランスコーディングスキームのメディア流れを示す図である。 CPFで中央集約化され、すべてのメディアパケットがCPFに行く前にTSに到達するトランスコーディングスキームのメディア流れの非制限的な実施例を示す図である。 図7のCPFで中央集約化されたトランスコーディングスキームのセッション制御流れを示す図である。 図7のCPFで中央集約化されたトランスコーディングスキームで新しい参加者がトーク許可を有する場合の事例のための制御流れを示す図である。 図7のCPFで中央集約化されたトランスコーディングスキームのための信号伝達流れを示す図である。 図7のCPFで中央集約化されたトランスコーディングスキームのための、トランスコーディングサーバ(TS)、CPFおよびユーザの端末の間のIPアドレスおよびポートルーティング設定を示す図である。 本発明の第2の非制限的な例示的実施形態により招待先ユーザのPPFで実行されるトランスコーディングスキームのアーキテクチャを示す図である。 本発明の第3の非制限的な例示的実施形態によりCPFで中央集約化された透過的トランスコーディングスキームのアーキテクチャを示す図である。 図13のCPFで中央集中化された透過的トランスコーディングスキームの信号伝達流れを示す図である。 図13のCPFで中央集約化された透過的トランスコーディングスキームの、TS、CPFおよびユーザの端末の間の例示的なIPアドレスおよびポートルーティング設定を示す図である。
以下の説明では、以下の説明の一部を形成し、本発明を実施しうるさまざまな非制限的な例示的実施形態を示す添付の図面を参照する。他の実施形態を利用することが可能であり、また本発明の範囲から逸脱することなく構造的および操作的な変更を加えられることを理解されたい。
以下の説明では、本発明についてプッシュツートークオーバーセルラー(PoC)のコンテキストで説明する。ただし、本発明は、PoCアプリケーションに制限されるものではなく、任意の所与の時点で1人の参加者のみがトーク許可を有する他のマルチパーティマルチメディアアーキテクチャに適用しうる。この許可は、中央ネットワーク要素によって管理される。中央ネットワーク要素は、PoC制御機能およびマルチポイント制御ユニット(MCU)を含む、セッションに対する任意の中央要素でよい。トーク許可もまた、より汎用的なコンテキストでは、1人または多数のユーザから派生しすべてのユーザに分配される任意の視聴覚メディアストリーム(たとえば、何人かのユーザのビデオストリームから作成されるビデオモザイクまたはいくつかの音声ストリームの混合)でよい。また、トークバーストおよびトーク許可について言及するが、トークとは一般に、メディアストリームを他の参加者に送信する許可を意味し、メディアストリームは音声、ビデオ、テキスト、グラフィック、または他のタイプのいずれであってもかまわないことにも留意されたい。したがって「メディアバースト」という用語のほうが適正でありうるが、「トークバースト」という用語を使用する。この使用法は、本発明の範囲を制限するものではなく、本発明は、あらゆるタイプおよび組み合わせのメディアに適用される。最後に、本発明の範囲内で、通信セッションに参加するユーザまたは当事者は、端末または任意の他のデバイスを使用してマルチメディアセッションに参加する人に限定されず、モニタリングデバイスまたはレコーディングデバイスなど、会議に参加する任意の自律デバイスも含む。
一般に、本発明の例示的実施形態は、任意の所与の時点で1人のユーザのみがメディアストリーム(たとえば、音声およびビデオ)を送信する許可を有するマルチユーザマルチメディアセッションを他の手段で確立できない、異なるメディア特性(型、フォーマット、コーデック、または属性)をサポートする端末の間の相互運用性を実現するためのシステムおよび方法を提供する。相互運用性は主要な関心事であるが、提案するシステムは、利便性のためにトランスコーディングも実行しうる。たとえば、ユーザの端末は音声をサポートしうるが、ユーザが会議中であり、音声の使用が許可されない場合、ユーザは、メディアをテキストに変換することを望むことがある。そのような利用法は、本発明の範囲内で考慮され、本発明における非互換性という用語の使用に含まれている。このシステムおよび方法は、各ユーザへのセッション提供をカスタマイズし、必要に応じて、ユーザ間のメディアストリームを各参加者の端末機能や好みにさえ準拠するように改変することにより、相互運用性を実現する。このシステムおよび方法は、マルチパーティマルチメディアセッションに対処し、PoCマルチメディアセッションのコンテキストに適用できる。本明細書では、いくつかの代替実施形態について説明する。特定の実施形態の選択は、特定のサービスの配備に関連する制約に左右される。一部の事例では、パフォーマンスが最も重要な場合があり、他の事例では、最も重要なのは透過的トランスコーディングである場合がある。
本発明の関心対象である考えられる用途の1つは、図1に示すように、PoCサービスにある。このサービスは、モバイルユーザが、参加者が一対一または一対多ベースで音声通信およびデータ通信を行うことができるグループセッションを作成することを可能にする[1]。図1は、PoCシステム100を示しており、ここでトーク許可を有するモバイル端末102は、伝送アンテナ104、無線ネットワーク106ならびに受信アンテナ108および110を介して、端末112、114、116および118にメディアストリームを送信する。無線ネットワーク106内の中央要素(図示せず)は、宛先端末112、114、116および118に対してメディアストリームを重複および転送する役割を担う。
汎用PoCアーキテクチャ200の実施例を図2に示す。端末202および204は、それらの端末のローカルネットワーク208内にあるローカルPoC参加機能(PPF) 206に接続され、PFC 206は、中央ネットワーク212内にあるPoC制御機能(CPF) 210に接続される。さらに、端末214は、ローカルネットワーク218内のローカルPPF 216に接続される。ローカルPPF 216もまた、CPF 210に接続される。したがって、端末202および204は、中央ネットワーク212を介して、端末214に相互接続される。端末202、204および214は、CPF 210によって制御される共通通信セッションに参加する。アーキテクチャ200はまた、202、204および214などの複数の端末に接続される206および216などの複数のPPFを含む、208および218などの複数のローカルネットワークによって構成されうることに留意されたい。
1. PoCアプリケーションでのトランスコーディング
1.1 PoCアプリケーションでのトランスコーディングを可能にするために考慮する要素
PoCバージョン1.0標準[1][14][15]では、トランスコーディングの必要性が認識されているが、詳細なソリューションは与えられていない。[1]では、トランスコーディングは、PoC制御機能(CPF)および/またはPoC参加機能(PPF)の両方により実行しうると述べられている。さまざまな構成および使用事例をサポートするトランスコーディングアーキテクチャがしたがって求められる。全体的なソリューションは、以下のようないくつかの要素を含む必要がある。
1. システムレベルのプロトコル流れ、クライアントまたはユーザなどの異なるエンティティ間の対話、トランスコーディングサーバ(TS)、PoCサーバ、および異なるエンティティ間で交換されるメッセージの改変。
2. トランスコーディングサーバの処理アーキテクチャ(TS内で行われる内部処理)。
3. トランスコーディングサーバとPoC機能との間のトランスコーディングインターフェイス(TI)。
これらの要素を図3に示す。さらに詳細には、図3は、図2のPoCアプリケーションに実質的に似ているが、トランスコーディング機能を備えるPoCアプリケーションの高レベルアーキテクチャ300を示している。N個のローカルネットワーク3021〜302Nは、中央ネットワーク304を介して互いに相互接続される。1≦n≦Nの各ローカルネットワーク302nは、PPF 308nに接続されるユーザの端末306nを含む。中央ネットワーク304は、各PPF 308nが接続されるCPF 310を含む。異なるエンティティ間の接続は、無線、有線、ケーブル使用、等の異なるタイプのものでよい。さらに、各ローカルネットワーク302nおよび中央ネットワーク304に、トランスコーディングサーバ312nおよび314がそれぞれ接続される。さらに詳細には、トランスコーディングサーバ312nは、トランスコーディングインターフェイス316nを通じてPPF 308nに接続される。またTS 314は、トランスコーディングインターフェイス318を通じてCPF 310に接続される。このような構成300により、N人のユーザ3061〜306Nが、中央ネットワーク要素CPF 310によって制御され、一度に1人のユーザがメディアストリームを伝送できる共通通信セッションに参加することが可能となる。
さらに、図3は、セッションを設定するための異なるエンティティ間のセッション流れも示している。いったんセッションがアクティブになると、メディア流れは、たとえば、TS 312nを通じて直接移動するか、またはTS 312nに到達する前にCPF 310および/またはPPF 308nを通過しうる。PoCサーバは、PoC制御機能(CPF)、PoC参加機能(PPF)または両方を含むことができ、すなわちCPFおよびPPFは、論理的には個別の機能に関するものの、単一のサーバを構成しうることに留意されたい。
1.2 セッション記述プロトコル
図4に示すセッション記述プロトコル(SDP)400は、SIPベース(Session Initiation Protocol)のマルチメディアセッションの主要な要素であり、[13]で定義されている。SDP 400は、セッションのパラメータを定義する複数のフィールドを含む。各行は、1つのフィールドに対応する。SDP 400は、他のユーザとのグループセッションを開始するときにユーザによって送信されるSIP INVITE要求[14]内に含まれる。
以下のSDPパラメータは、特に興味深いものである。
・メディアストリームが受信されるIPアドレスは、行422のフィールド「c=」で記述され、ここでは、例として、1000:900:800:700:600:efdf:2edf:3eceというIPV6アドレスが示されている。
・メディア特性のリストは、行424および432の「m=」フィールドで示されており、例として、このセッションの2つのメディアが示されている。
○ポート3456で受信され、関連するRTCP (Real-Time Control Protocol)を有するRTP (Real-Time Protocol)上の音声が、行424で示されている。音声メディアについては、2つのコーデックが提供され、97および98とタグ設定されている。
○ポート2000でUDP (User Datagram Protocol)を使用して受信されるTalk Burst Contr
ol Protocol (TBCP)が、行432で示されている。
・これら2つのメディアの詳細は、行426、428、430および434の「a=」フィールドで記述されている。
○音声メディアについては、2つのタグ97および98は、提供される2つの個別のコーデックに対応している。これらは、行426および428で示されるように、AMRコーデックまたは8,000HzでのEVRCコーデックである。
○ポート5560でのRTCPが、行430で提供されている。
○TBCPについては、いくつかのオプションが行434で提供されている。
2. PoC制御機能で中央集約化されたトランスコーディングスキームのためのPoC信号伝達流れ
PoC仕様では、いくつかの招待方法を含みうるいくつかのタイプのセッションを説明しており、これらの方法は、Open Mobile Alliance (OMA)によって作成されたPoC仕様で説明されており、本明細書では簡潔にするために説明しない。当業者は、PoC標準によってサポートされるすべての事例に、本発明を端的な態様で適用できるであろう。
本発明の第1の非制限的な例示的実施形態では、トランスコーディングスキームがPoC制御機能で中央集約化される事例が検討される。
2.1 セッション流れにおけるPoC制御機能の役割
図3に示す本発明の第1の非制約的な例示的実施形態では、トーク許可に加えて、トランスコーディングプロセス全体が、CPF 310によって管理される。確立されるPoCグループセッションのタイプに関係なく、CPF 310は、2つの主要な責務を有する。
1. ユーザ間の適正なセッション提供および設定を保証する。
・PoCユーザは互換性のないフォーマット/コーデックを有している可能性があるため、CPF 310は、さまざまなユーザへのSDP 400(図4を参照)の提供を変更して、それらのユーザがグループセッション中に使用でき、また他のフォーマット/コーデックへの適正なトランスコーディングが可能であるフォーマット/コーデックを含めなければならない場合がある。たとえば、AMRのみをサポートするユーザは、EVRCのみをサポートするユーザとの直接セッションを確立できない。AMR-EVRCのトランスコーディングをサポートするCPFは、セッション提供内にEVRCおよびAMRの両方を含めるであろう。これは、適正なセッション提供を保証するCPFの役割を概説する図5のシステム500で示されている。図5の実施例A)では、AMR音声コーデックのみをサポートする端末504は、セッション記述(図示せず)を用いて、EVRC音声コーデックのみをサポートする端末506を、CPF 502を通じた通信セッションに招待するが、CPF 502は、招待のセッション記述を変更しない。したがって端末506は提供されたAMR音声コーデックをサポートできないため、エラー「4xx Request Failure」が端末506によって生成される。実施例B)では、AMR音声コーデックのみをサポートする端末508は、セッション記述(図示せず)を用いて、EVRC音声コーデックのみをサポートする端末510を、CPF 512を通じた通信セッションに招待するが、CPF 512は、端末510の機能を満たすように招待のセッション記述を変更する。端末508によって発行される招待のセッション記述は、AMR音声コーデックのみを含んでいるが、CPF 512が端末510のためにセッション記述を拡張してEVRC音声コーデックも含めるため、端末510は、EVRCコーデックを選択されたコーデックとして用いて200 OK応答を発行することにより、招待を受諾する。CPF 512は、端末508および510の間でセッションを行うことができ、それらの端末の間でデータを交換することができるよう、端末508に対する招待受諾を改変して、EVRCコーデックの代わりにAMRコーデックを含める。
2. ユーザ間でのメディアストリームの流れを管理する。
・トランスコーディングが必要な場合、メディアストリームは、トランスコーディングサーバ(TS)(図5では図示せず)を通じて流れる必要があり、そのTSでメディアストリームは適合/トランスコードされ、その後宛先に送信される。このためには、メディアストリームの流れをCPF 512によって管理する必要がある。メディア流れに関しては、Talk Burst Control (TBC)および通常のメディアの2つのタイプのトラフィックをCPF 512によって管理する必要がある。第1のタイプは、ユーザおよびCPF 512の間のトーク許可の要求などのトーク要求と応答とに関する。第2のタイプは、転送される有益な情報および実際のデータを含む通常のメディアストリーム(たとえば、RTPおよびRTCP上のAMR)に関する。トラフィックの各タイプは、何らかの特定のポート番号に割り当てられる。したがって、CPF 512およびTSはそれぞれ、TBCP (Talk Burst Control Protocol)ポートなどのTBCトラフィック用のポートを少なくとも1つ含む。
2.2 メディア流れにおけるPoC制御機能の役割
メディア流れについては、2つの選択肢が考えられる。したがって、2つのメディア流れスキームを考慮し、図6のアーキテクチャ600および図7のアーキテクチャ700に示す。非制限的な実施例として、図6および図7の両方は、AMR/EVRCトランスコーディングを使用したアーキテクチャを示している。
トランスコーディングがCPF 602で中央集約化され、すべてのメディアパケットがトランスコーディングサーバ(TS)604の前にCPF 602に到達する、第1のメディア流れスキームを図6のアーキテクチャ600に示す。AMRコーデックを使用する端末606からのユーザは、EVRCコーデックを使用する端末608からのユーザと通信し、メディアストリームを交換したいと考えている。端末606は、メディア流れ610でAMRパケットをReal Time Protocol (RTP)上でCPF 602に送信する。CPF 602は、適合およびトランスコーディングのために、メディア流れ612でそれらのAMRパケットをRTP上でTS 604に送信する。TS 604は、適合されたEVRCパケットをメディア流れ614でRTP上でCPF 602に返し、CPF 602はその後、それらのパケットをメディア流れ616で端末608に転送する。別の代替方法では、TS 604は、CPF 602を経由することなく、適合されたEVRCパケットを端末608に直接送信できる。
CPF 602は、通常のメディアストリームをTS 604に転送する一方、端末606からTBCPポートに到達するTBCパケットを自ら処理し、その結果をメッセージ流れ618で端末606に返す。実際、TB要求および応答を含むメディア流れ618は、通信経路内にTS 604を含むことなく、端末606およびCPF 602の間でのみ通信される。
トランスコーディングがCPF 702で中央集約化され、すべてのメディアパケットがCPF 702の前に(あるいは、代わりに)TS 704に到達する、第2のメディア流れスキームを図7のアーキテクチャ700に示す。端末706は、メディア流れ708でAMRパケットをRTP上でTS 704に送信する。TS 704は、AMRパケットをEVRCパケットにトランスコードし、それによって適合されたEVRCパケットを流れ710でRTP上で端末712に送信する。TB要求および応答を含むメディア流れ714は、TS 704のみを介して、端末706およびCPF 702の間で交換される。さらに詳細には、TS 704は、メディア流れ714の着信パケットを、CPF 702へのメディア流れ716の発信パケットに転送する。またTS 704は、CPF 702からのメディア流れ716の着信パケットを、端末706へのメディア流れ714の発信パケットに転送する。同じ態様で、端末712およびCPF 702は、TS 704のみを介して、TB要求および応答を互いに交換しうる。
したがって、TS 704は、そのTBCPポートに到達するTBCパケットをCPF 702に転送し、一方で通常のメディアストリームをトランスコードして端末712などの宛先に送信する。CPF 702は、そのTBCPポートに到達するTBCメッセージを管理し、応答をTS 704に返してTS 704がそれらの応答を宛先に転送するか、あるいは、CPF 702は、応答を宛先に直接返す。
図7のアーキテクチャ700は、TS 704およびCPF 702の間のパケットの流れがより軽くて済むため、好ましいメディア流れスキームと考えられる。
2.3 PoC制御機能によって管理されるセッション制御
上述したメディア流れに加えて、セッション制御流れも管理/提供しなければならない。セッション制御流れは、図8に示されており、CPF 802によって管理されるが、CPF 802は、セッション自体も管理しなければならない。セッションは、メディア流れに影響を与えることがある。実際、通信セッションが設定された後に、たとえばユーザの参加または離脱に対処するためにセッションパラメータが変更されるか、または異なるユーザがトーク許可を有する場合、CPF 802は、メディアストリームの適正なトランスコーディングおよびルーティングを実行できるように、状況をTS 804に通知しなければならない。
さらに詳細には、図8のアーキテクチャ800は、セッションを設定するときにCPF 802、TS 804ならびに端末806および808の間で発生する制御流れを示している。アーキテクチャ800では、AMR音声コーデックおよびEVRC音声コーデックの間の相互運用性は、非制限的な実施例として対処されている。セッションの設定は、以下のとおりである。
1. 端末806のユーザは、メッセージ810で、サポートされる視聴覚フォーマット/コーデック(AMRコーデックなど)を含むセッション記述を用いて招待を送信することにより、別のユーザをセッションに招待する。
2. CPF 802は、提供されるセッションメディアのフォーマット/コーデック情報ならびにIPアドレスおよびポート情報を含む招待を受信し、TS 804に対してメッセージ812で、トランスコーディングセッションを設定し、セッションに参加する他のユーザに提供する受諾可能なフォーマット/コーデックのリストを提供するよう要求する。
3. TS 804は、トランスコーディングリソースを設定し、メッセージ814で、IPアドレスおよびポート情報をフォーマット/コーデック情報と共にCPF 802に返す。この特定の実施例では、EVRCコーデックがリストに追加される。
4. CPF 802は、拡張されたメディアフォーマット/コーデックならびにIPアドレスおよびポート情報を含む招待を、メッセージ815で、招待先端末808に転送する。
5. 端末808は、CPF 802に宛てられるメッセージ816で、自らのサポートされるコーデック(この実施例ではEVRC)を用いて招待を受諾する。
6. メッセージ816を受信すると、CPF 802は、TS 804に対し、メッセージ818で、招待を受諾した招待先端末808によって提供された情報に応じてトランスコーディングセッションを更新するよう要求する。この情報は、端末808に対して使用される受諾されたフォーマット/コーデックならびにIPアドレスおよびポートに関する。
7. TS 804は、要求された操作を実行し、フォーマット/コーデックならびにIPアドレスおよびポート情報を含む更新されたセッション情報を、メッセージ820で、CPF 802に提供する。
8. CPF 802はその後、メッセージ820で、使用されるおよび端末806によってサポートされるフォーマット/コーデックを用いて招待が受諾されたことを端末806に伝える。
9. 端末806はその後、既存のPoC機構を使用して、トーク許可を取得する。
10. 端末806は、TS 804へのAMRパケットの送信を開始する。その後、図7のアーキテクチャ700に順じて、TS 804は、AMRパケットをEVRCパケットにトランスコードし、それらを端末808に転送する。図6のアーキテクチャ600を代わりに使用した場合、パケットは、TS 804でトランスコードされる前に、最初にCPF 802に到達するであろう。さらなる詳細は、本明細書で以下に説明する図10の詳細な信号伝達流れで提供する。
ここで図9を参照すると、アーキテクチャ900は、906などのユーザがトーク許可を要求するときに、CPF 902、TS 904ならびにユーザ906および908の間で発生する制御流れの実施例を示している。一般に、最初は誰もトーク許可を有していないと想定される。ステップは以下のとおりである。
1. 端末906は、TB (Talk Burst)要求メッセージ910を発行することにより、トーク許可を要求する。この実施例では、図7のメディア流れが想定されているが、当業者は、図6によるメディア流れのための適正なメッセージ流れを容易に導き出すことができる。
2. TB要求メッセージ910は、TS 904に到達し、メッセージ912でCPF 902に転送される。
3. CPF 902は、TS 904がトランスコーディングリソースを適正かつ適宜に割り当てることができ、またメディアストリームに適正な制御を適用できるように、ユーザ端末906がトーク許可を求めていることをTS 904にメッセージ914で通知する。
4. TS 904がメッセージ916で要求が認められたことをCPF 902に確認した後、CPF 902は、TB確認メッセージ918をTS 904に送信することによってトーク要求が認められたことをユーザ端末906に伝え、TS 904はそのメッセージをメッセージ920でユーザ端末906に転送する。
5. ユーザ端末906はその後、メディア流れ922で、RTPトランスポート上でのAMRパケットの送信を開始することができる。
6. メディア流れ922は、TS 904に到達する。TS 904は、メディア情報をAMRフォーマットからEVRCフォーマットにトランスコードし、その後トランスコードされたメディアをメディア流れ924でユーザ端末908に送信する。
7. その後、たとえば端末908によって受信されたパケットの数などのメディア924についてのRTCPレポートが、メディア流れ926で端末908からTS 904に送信される。
8. メディア922についてのRTCPレポートが、メディア流れ928でTS 904からユーザ906に送信される。
AMRコーデックおよびEVRCコーデックの使用は、アーキテクチャ900内で実行する操作を例示しているだけであり、アーキテクチャ900は、これらのコーデックに制限されるわけではない。アーキテクチャ900は、さまざまなフォーマット/コーデックと、AMR、AVRC、H.263、MPEG-4パート2、MPEG-4パート10、などの視聴覚フォーマット/コーデックの組み合わせを含むフォーマット/コーデックの組み合わせとをサポートできる。たとえば、アーキテクチャ900は、AMR/H.263からEVRC/MPEG-4パート2へ、およびEVRC/MPEG-4パート2からAMR/H.263へのトランスコーディングをサポートしうる。また、本発明では、TB(要求/確認)メッセージは、例示のみを目的にTS 904およびCPF 902の間を流れる。本発明の他の変形および実施形態では、IPスイッチを使用して、そのような操作のためにTS 904を通過することなく、そのようなメッセージをCPF 902に直接ルーティングできる。
2.4 CPFで中央集約化された適合のための詳細な信号伝達流れ
ここで図10を参照すると、CPFで中央集約化されたトランスコーディングスキームの詳細な信号伝達流れが記述されている。いくつかのグループセッション事例とその変形とを考慮することが可能である。しかし、これによって本明細書は、さらなる利点を提供することなく、きわめて冗長な文章となるであろう。したがって、対応する詳細な信号伝達流れを備えた、代表的な使用事例について説明する。この信号伝達流れは、当業者により、すべての他の事例に端的な態様で適用できる。
以下では、「PoC仕様で記述される手動応答を用いたオンデマンドセッションを使用する確認済み指示」の事例を提供する。SIP/IPコアに関する信号伝達の詳細については、それらが明白であり、かついかなる利点もなく流れを複雑にするだけであるため、説明しない。加えて、すべてのメディアパケットがTSに到達する事例について検討する。ただし、当業者にとっては、すべてのメディアパケットがCPFに到達する事例を検討するのは容易であろう。
図10は、トランスコーディングスキームがCPFで中央集約化され、すべてのメディアストリームがTSに到達する事例についての、CPF 1002、TS 1004、ならびにユーザ端末1006および1008とそれらのそれぞれのPPF 1010および1012の間の詳細な信号伝達流れの例示的実施形態1000を示している。ステップは以下のとおりである。
0. PoCユーザ1006は、対応するPoC端末のPoCボタンを押して、グループセッションを開始する。
1. そうすることにより、ユーザ1006は、メッセージ1014で、SDP-Aと記されるSDP情報を含むSIP INVITEメソッドを発行する。SIP INVITEは、ユーザ1006のネットワーク内のPPF 1010(たとえば、ユーザのホームPPF)に最初に到達する。たとえば、SDP-Aは、非制限的な実施例として、以下を含みうる。
c=IN IP6 FF1E:03AD::7F2E:172A:1E24
m= audio 3456 RTP/AVP 97
a= rtpmap:97 AMR
a= rtcp:5560
m= application 2000 udp TBCP
a= fmtp:TCBP queuing=1;tb_priority=2;timestamp=1
2. SIP INVITEは次に、メッセージ1016で、PPF 1010からCPF 1002に送信される。CPF 1002は、ユーザ1006のネットワーク、ユーザ1008のネットワーク、または異なるネットワークなど、任意のネットワーク上に存在していてよい。
3. CPF 1002は、メッセージ1018で、TS 1004に連絡してセッション用のトランスコーディングリソースを設定する。要求には、SDP-Aに含まれるフォーマット/コーデックがIPアドレスおよびポート情報と共に含まれる。コーデック情報は、ユーザ1008などの招待先のフォーマット/コーデックを把握し、他のユーザへのセッション提供に追加することが可能な追加のフォーマット/コーデックを判定するために使用される。IPアドレスおよびポート情報は、他のユーザからのトランスコード結果をトランスコード後に招待元クライアント、この事例ではユーザ1006に到達するために、どこに送信する必要があるかを判定するために使用される。すべてのメディアパケットがTS 1004に到達するため、このIPアドレスおよびポート情報は、CPF 1002から来るトークバースト(TB)応答をユーザ1006に到達するためにどこに送信する必要があるかを判定するためにも使用される。また、招待元クライアント(ユーザ1006)がトークバースト要求を転送するために、CPF 1002のIPアドレスおよびポート情報が必要である。たとえば、CPF 1002のIPアドレスがIP6 FF1E:03AD::7F2E:172A:1E28である場合、SDPを使用する情報は、以下のように提供される(ただし、インターフェイスではSDPを使用する必要はない)。
c =IN IP6 FF1E:03AD::7F2E:172A:1E28
m= application 2002 udp TBCP
さらに、トランスコーディング設定操作では通常、i)SetupTranscodingSession(SDP-A, SDP-CPF)およびii)AddInvitee(Session ID)の2つのTS API(Application Program Interface)メソッドを呼び出す。
i)第1のメソッドは、新しいトランスコーディングセッションを開始する。このメソッドは、新しいセッションIDコンテキストを作成し、すべてのメディアのためにユーザ1006およびCPF 1002に到達するためのIPアドレスおよびポートを記憶する。このメソッドはまた、招待元当事者であるユーザ1006によってサポートされるメディアフォーマット/コーデックおよびプロトコルも記憶する。このメソッドは、セッションIDを返す。ユーザ1006のためのTS 1004内での予約プロセスは、図11では点線で1110示されている。
ii)第2のメソッドは、新しい参加者をセッションIDに招待する情報を提供する。このメソッドは、ユーザIDと、そのユーザがメディアストリームを送信でき、またCPF 1002がこのユーザにTS 1004を通じてTB応答を送信できるIPアドレスおよびポートとを返す。すべての情報は、セッションIDのコンテキストで更新される。
4. 次に、TS 1004は、メッセージ1020で、以下の情報をCPF 1002に返す。
・メッセージ1018でのSetupTranscodingSession(SDP-A, SDP-CPF)の呼び出しに対して、将来の参照のためのセッションIDを返す。
・AddInvitee(Session ID)の呼び出しに対して、(図11の短い破線1116で示されているように)将来の参照のためのユーザID(招待を受諾したユーザまたは離脱するユーザなど)、招待先1008へのセッション提供内で提供するフォーマット/コーデックのリスト(すなわち、TS 1004がユーザ1006によって提供されたフォーマット/コーデックとの間でトランスコーディングをサポートできるフォーマット/コーデックのリスト)、招待先ユーザ1008が他の参加者へのトランスコーディングのためにメディアを送信できるアドレス/入力ポートのリスト、およびCPF 1002が招待先ユーザ1008のためにトークバースト応答をTS 1004に送信できるアドレス/入力ポートのリストを返す。
・TS 1004は、SDPを以下のように使用して、情報を提供できる(ただし、インターフェイスでSDPを使用する必要はない)。i)他の参加者の招待については、以下のように情報を提供できる。
c= IN IP6 FF1E:03AD::7F2E:172A:1E30
m= audio 53456 RTP/AVP 97 98
a= rtpmap: 97 AMR
a= rtpmap: 98 EVRC/8000
a= rtcp:53080
m= application 50000 udp TBCP
a= fmtp:TCBP queuing=1; tb_priority=2; timestamp=1
またii)CPF 1002からのTB応答の送信については、以下のように情報を提供できる。
c =IN IP6 FF1E:03AD::7F2E:172A:1E30
m=application 53458 udp TBCP
CPF 1002が新しいユーザをセッションに招待しようとするたびに、AddInvitee(Session ID)を呼び出す必要があるということに留意されたい。また、すべてのメディアストリームがTS 1004に向かう前にCPF 1002に入る場合(もう1つの選択肢)、(メッセージ1018を有する)ステップ3のIPアドレスおよびポートは、SDP-Aに対応するのではなく、CPF 1002内のIPアドレスおよびポートに対応するであろう。また、CPF 1002およびTS 1004の間でTBCPの流れが存在しなくなるため、メディアTBCPを有する行「m=」は、パラメータ内に存在しなくなるであろう。TS 1004はしたがって、いかなるTalk Burst Control Message (TBCM)も処理する必要がないことを把握するであろう。
5. TS 1004から受信された情報応答は、CPF 1002によって処理され、改変された招待SDP-A'が生成されて、その後メッセージ1022で招待先1008にそのPPF 1012を通じて送信される。
6. PPF 1012は、受信した招待をメッセージ1024でPoCユーザ1008に転送する。
7. メッセージ1026で、アラートメッセージがユーザ1008からそのPPF 1012に送信される。アラートメッセージは、招待元ユーザ1006に、招待先ユーザ1008が招待を受信したがまだ招待を受諾していないことを通知する。
8. アラートメッセージはその後、メッセージ1028で、PPF 1012からCPF 1002に送信される。
9. アラートメッセージはその後、メッセージ1030で、CPF 1002からユーザ1006のPPF 1010に送信される。
10. アラートメッセージは、メッセージ1032でPPF 1010によって送信され、ユーザ1006
によって最終的に受信される。
11. ユーザ1008は、招待を受諾し、メッセージ1034で、SDP-AB'内の選択されたメディア情報をそのPPF 1012に提供する。たとえば、SDP-AB'は、以下を含みうる。
c= INIP6FF1E:03AD::7F2E:172A:1E34
m= audio 5458 RTP/AVP 98
a= rtpmap:98 EVRC/8000
a= rtcp:5480
m= application 4000 udp TBCP
a= fmtp:TCBP queuing=1;tb_priority=2;timestamp=1
12. メッセージ1034は、メッセージ1036で、PPF 1012によりCPF 1002に転送される。
13. CPF 1002はその後、メッセージ1038で、TS 1004に連絡してトランスコーディングセッションを更新する。この要求は、実際には以下の2つのTS APIメソッドを含む。
・Join(Session ID, User ID, SDP-AB', SDP-CPF)(図11の実線1112で示されている):このメソッドは、TS 1004に、ユーザ1008が招待を受諾したことを通知する。このメソッドは、User IDに対応するユーザ1008に到達するためのIPアドレスおよびポートと、そのメディア全体のためのCPF 1002とを記憶することにより、セッションIDコンテキストを更新する。このメソッドはまた、User ID、すなわち参加する当事者1008によってサポートされるメディアフォーマット/コーデックおよびプロトコルを記憶する。たとえば、CPF 1002は、User IDからのTB要求を送信できる、そのIPアドレスおよびポートに関する情報を提供する必要があるであろう。
c =IN IP6 FF1E:03AD::7F2E:172A:1E28
m= application 2008 udp TBCP
ユーザ1008のためのTS 1004内の予約プロセスは、図11の実線1112で示されている。
・AcceptInvite(Session ID, SDP-AB', SDP-CPF):このメソッドは、TS 1004に、ユーザ1006からの招待が少なくとも1人によって受諾されたことを通知する。このメソッドは、ユーザ1006が各入力ポートに対して使用することが期待されるフォーマット/コーデックを記憶することにより、セッションIDコンテキストを更新する。このメソッドは、ユーザ1006がメディアストリームを送信できると共に、CPF 1002がTS 1004を通じてユーザ1006にTB応答を送信できるIPアドレスおよびポートを返す。ユーザ1006のためのTS 1004内の予約プロセスは、図11の長い破線1114で示されている。
14. TS 1004はその後、メッセージ1040で、以下の情報をCPF 1002に返す。
・メッセージ1038で実行されたJoin(Session ID, User ID, SDP-AB', SDP-CPF)の呼び出しの要求のステータス。このステータスは通常、セッションへの新しいユーザの追加の成功またはそのユーザを追加できなかった理由を報告する。
・メッセージ1038で実行されたAcceptInvite(Session ID, SDP-AB', SDP-CPF)の呼び出しの戻りパラメータであって、ユーザ1006が他の参加者のフォーマットへのトランスコーディングのためにメディアストリームを送信できるアドレス/入力ポートのリストと、使用されるフォーマット/コーデックと、CPF 1002がユーザ1006のためにトークバースト応答をTS 1004に送信できるアドレス/入力ポートのリストとを含む戻りパラメータ。TS 1004は、図11の長い破線1114で示されているように、以下のようにSDPを使用して情報を提供できる(ただし、インターフェイスではSDPを使用する必要はない)。i)ユーザ1006へのセッション時のデータ伝送については、以下のように情報を提供できる。
c=IN IP6 FF1E:03AD::7F2E:172A:1E3
m= audio 48456 RTP/AVP 97
a= rtpmap:97 AMR
a= rtcp:48080
m= application 48000 udp TBCP
a=fmtp:TCBP queuing=1; tb_priority=2; timestamp=1
ii) CPF 1002から来るTB応答の送信については、以下のように情報を提供できる。
c=IN IP6 FF1E:03AD::7F2E:172A:1E30
m= application 48400 udp TBCP
15. TS 1004からの情報応答は、CPF 1002によって処理され、CPF 1002はその後、メッセージ1042で、招待元当事者1006のための改変された招待SDP-AB*をそのPPF 1010を通じて送信する。この招待は基本的に、使用されるメディアフォーマット/コーデックと、メディアストリームを送信するIPアドレスおよびポートとを含む。
16. PPF 1010は、メッセージ1044で、招待をPoCユーザ1006に転送する。
17. CPF 1002は、メッセージ1046で、ユーザ1006がトーク許可を有することをTS 1004に通知する。これは、APIメソッドTalkBurstInform(Session ID, User ID)を使用して行うことができる。情報は、セッションIDのコンテキスト内で更新される。
18. TS 1004は、メッセージ1048をCPF 1002に送信することにより、許可を承認する。
19. CPF 1002は、メッセージ1050で、ユーザ1006に宛てられたトークバースト確認をそのPPF 1010を通じて送信する。
20. PPF 1010は、メッセージ1052で、トークバースト確認をユーザ1006に送信する。
21. ユーザ1006は、通知1054で、トーク権限を与えられる。
22. CPF 1002は、メッセージ1056で、トークバースト受信メッセージをユーザ1008にそのPPF 1012を通じて送信する。
23. PPF 1012は、メッセージ1060で、トークバースト受信メッセージをユーザ1008に転送する。
24. ユーザ1008は、通知1062で、ユーザ1006がトーク権限を与えられたことを通知される。
25. メディアストリームが、メディア流れ1064で、ユーザ1006からTS 1004に移動する。本例示的実施形態では、AMRパケットが送信される。メディアストリームがTS 1004ではなくCPF 1002を通じて移動する事例を示すのは簡単であろう。セッション開始プロセス(SIP)で必要なのは、TS 1004ではなくCPF 1002を指し示す異なるアドレスおよびポートをユーザに提供することと、CPF 1002のIPアドレスおよびポートを出力宛先としてTS 1004に提供することだけであろう。
26. 次に、TS 1004は、ユーザ1006がトーク権限を有することを把握し、操作1066で、メディアストリームをAMRからEVRCにトランスコードする。
27. 次に、TS 1004は、メディア流れ1068で、EVRCにトランスコードされたパケットをユーザ1008に送信する。
28. ユーザ1006は、PoCボタンを解放する。
29〜41. 残りのステップは、通常のPoC操作であり、さらなる説明は不要である。これらのステップは、ユーザ端末1006によって送信された最後のパケットのトランスコーディングと、ユーザ1006がPoCボタンを解放した後に、トークバーストアイドル通知によって示される、メディアストリーム伝送の終了とに関する。
ただし、ユーザ1006および1008の一方による以降のPoCボタンの再押下は、その一方のユーザが他の参加者(複数も可)にメディアストリームを送信できるようにするために、前述の説明で示されているように、たとえば図10の操作1046(メディアストリームの伝送を望むユーザからのトークバースト通知を用いる)〜1076(メディアストリームの伝送およびトランスコーディング用)を通じて処理される。操作1070〜1094は、その一方のユーザがPoCボタンを解放したときに信号伝達流れで起こることを示している。
図11のメディア流れアーキテクチャ1100は、トランスコーディングスキームがCPF 1102で中央集約化されている場合の、CPF 1102およびTS 1104を通じたメディア流れのルーティングの例示的実施形態を示している。CPF 1102から端末1106へのTBCPメッセージに加えて、招待元端末1106から発行されるメディアのためのTS 1104の入力IPアドレスおよびポートは、長い破線1114で示されている。端末1106からの入力IPアドレスおよびポートは、メディア流れ1114で示されているように、コーデック、RTCPおよびTBCPなど、さまざまなタイプのメディア流れにマップされる。同様に、CPF 1102から端末1108へのTBCPメッセージに加えて、招待先端末1108から発行されるメディアのためのTS 1104の入力IPアドレスおよびポートは、短い破線1116で示されている。端末1108からの入力IPアドレスおよびポートは、メディア流れ1116で示されているように、コーデック、RTCPおよびTBCPなど、さまざまなタイプのメディア流れにマップされる。端末1106からCPF 1102へのTBCPメッセージに加えて、招待元端末1106に送信されるメディアのためのTS 1004の宛先IPアドレスおよびポートは、点線1110で示されている。端末1106の入力IPアドレスおよびポートは、メディア流れ1110で示されているように、コーデック、RTCPおよびTBCPなど、さまざまなタイプのメディア流れにマップされる。
端末1108からCPF 1102に宛てられるTBCPメッセージのためのIPアドレスおよびポートに加えて、招待先端末1108に送信されるメディアのためのTS 1104の宛先IPアドレスおよびポートは、図11の実線1112で示されている。端末1108の入力IPアドレスおよびポートは、メディア流れ1112で示されているように、コーデック、RTCPおよびTBCPなど、さまざまなタイプのメディア流れにマップされる。すべての個別の流れに対して異なるポートが使用されるものの、TS 1104が、この実施例では、「1E30」で終わり、1114および1116で示されるすべての着信メディア流れに使用されるIPアドレスを有することに注目されたい。発信流れについては、「1E24」で終わるIPアドレスは端末1106に宛てられ、「1E28」で終わるIPアドレスはCPF 1102に宛てられ、「1E34」で終わるIPアドレスは端末1108に宛てられる。
説明した例示的実施形態のいくつかのさらなる説明および変形に注目する必要がある。
・参加者が複数の事例: この事例では、招待される参加者ごとに、CPF 1102は、AddInvitee(Session ID)を呼び出してからSDP INVITEを送信し、ユーザが受諾したらJoin(Session ID, User ID, SDP-AB', SDP-CPF)を呼び出す必要があろう。参加者がセッションを離脱するとき、CPF 1102は、セッションを離脱するユーザIDを考慮して、セッションIDを更新するLeave(Session ID, User ID)の呼び出を行う必要がある。
・すべてのメディアパケットがCPF 1102に到達する事例: この代替事例については、図10を参照して本明細書で上述した。セッション開始プロセスで必要なのは、TS 1004ではなくCPF 1002を指し示す異なるアドレスおよびポートをユーザに提供することと、CPF 1002のIPアドレスおよびポートを出力宛先としてTS 1004に提供することだけであろう。また、TS 1004にメディア情報を提供する場合、TBCPメディアはCPF 1002によって完全に管理されるため、セッション記述の一部にならないであろう。これは、[1]の9.12項で述べられているように、すべてのメディア流れが(パケット複製のために)CPF 1002を通過しなければならない、PoCアプリケーションで想定する「安全な」事例であることに留意されたい。ただし、もう一方の事例(すべてのメディアストリームがTSに到達する)は、メディア処理をTS 1004に委任するため、はるかに効率的であり拡張性がある。ある意味で、TS 1004は、CPF 1002の拡張であると考えることができる。
本発明の性質および範囲から逸脱することなく、上述した例示的実施形態に多数の変形を加えられることに留意されたい。たとえば、ある変形では、TBCPメッセージはTS 1004を通って流れない可能性がある。TSの動作は、密制御されるかまたは疎制御されるものとして分類できる。密制御される場合、TS 1004は、TBCPメッセージを監視してトーク許可を有する人を判定するか、または特定の制御メッセージをCPF 1002から受信する。疎制御される場合、TS 1004は、メディアストリームのアクティビティを監視することにより、話す人を把握する。CPF 1002およびTS 1004の間の特定のメソッドおよびAPIも、本発明の範囲から逸脱することなく改変できる。さらに、PPF 1006、CPF 1002およびTS 1004などのメディア要素は、個別の論理要素として表現されているが、実際には、本発明の範囲から逸脱することなく、それらの1つまたは複数を単一のサーバ内に組み合わせることができる。
3. トランスコーディングスキームが招待先のPoC参加機能にあるPoC信号伝達流れ この従属項では、トランスコーディングが招待先当事者のPPFで実行される、本発明の第2の非制限的な例示的実施形態を提供する。
3.1 PoC参加機能およびPoC制御機能の役割
トランスコーディングが招待先PPFで実行される事例では、トランスコーディングプロセス全体がそのPPFによって管理されるが、一方でトーク許可と、メディアパケットのコピーの作成を含む各宛先へのメディアストリームのルーティングとは、依然としてCPFによって管理される。確立されるグループセッションのタイプに関係なく、PPFは、2つの主要な役割を有し、それらの役割は、2.1で説明したものと本質的に同じである。第1に、PPFは、ユーザ間の適正なセッション提供および設定を保証する。第2に、PPFは、ユーザおよびCPFの間のメディアストリームの流れを管理する。すべてのメディアストリームは、CPFを通じて移動しなければならないが、すべてのPPFを通じて移動する必要はないということに留意されたい。ただし、セッション制御メッセージは、すべてのPPFとCPFとを通過しなければならない。
CPFの役割は、i)誰がトーク許可を有するかを制御することと、ii)話しているユーザのメディアパケットを他のユーザに複製およびルーティングすることである。
本事例と、トランスコーディングスキームがCPFで中央集約化されている事例との主要な違いは、以下のとおりである。
i)PPFは、ユーザおよびCPFの間のトランスコーディングを制御する(したがって入力側に1人のユーザがいて、出力側に1人のユーザがいる)が、一方で前の事例では、CPFは、すべての宛先(多数のユーザ)へのトランスコーディングを制御しなければならなかった。これは、PPFは、さまざまな宛先へのパケットの複製を許可されないからである。複製は、CPFによってのみ実行できる。
ii)PPFは、誰が話すかを制御する必要はないが、CPFは、依然としてこれを行う。したがって、トランスコーディングサーバに対するPPF制御は、2つの方法で実行できる。a)疎制御 - いったんセッションが設定されれば、トランスコーディングサーバは常にアクティブであり、常にトランスコーディングを実行する準備ができているが、一部のチャネルはアイドル状態でありうる。b)密制御 - PPFは、TBCMを聴取し、トランスコーディングを開始または停止するようトランスコーディングサーバに通知するか、あるいは、PPFは、TBCMを分析し、誰がトーク許可を有するかを判定できる。
本発明の第2の非制限的な例示的実施形態では、適合またはトランスコーディングは、招待先参加者のPPFで実行される。招待元端末は、そのメディアセッション記述を含む招待を他の当事者に送信する。各招待先参加者のPPFは、図8でCPFが行っていたのと同じ操作を実行する。このため、招待元当事者のPPFはトランスコーディングを実行する必要はないが、トランスコーディングはセッションに参加している他の当事者(たとえば、招待先ユーザ)のPPFの役割である状況が生じる。したがって、招待元当事者によってサポートされるフォーマットのメディアが、CPF内を流れる。システム内のトランスコーディングに必要なコンピューティングリソースは、セッションに参加する多数の招待先当事者が招待元当事者のメディアフォーマットをサポートしていれば、軽減されうる。
図12は、招待先当事者のPPFでのトランスコーディングのための例示的アーキテクチャ1200を示している。事例A)では、トランスコーディングは、受信側PPFで行われる。トーク許可を有する招待元端末1202は、その端末のサポートフォーマット(この特定の実施例ではAMR)でメディアストリームを送信する。招待元端末1202によってサポートされ、セッション確立時に合意されるフォーマットのそのようなストリームは、CPF 1204内を流れる。招待先当事者のPPF 1214および1216は、端末1202によってサポートされるフォーマットでメディアストリームを受信し、その後それらのメディアストリームを必要に応じて招待先端末1212および1210の機能を満たすようにトランスコードする。この実施例では、PPF 1214は、受信したメディアストリームをユーザ1212のためにAMRからEVRCにトランスコードするTSを形成するが、一方でPPF 1216は、ユーザ1210の端末が既にAMRをサポートするため、ユーザ1210のためにトランスコーディングを実行する必要はない。
この実施例では、要素1202、1212および1214は、それぞれ単一のサーバ内に組み込まれたPPFおよびTSの組み合わせを形成することに留意されたい。
同じく図12で示されているように、事例B)は、トランスコーディングが送信側PPFおよび受信側PPFで発生する事例に対応する。ユーザ1224は、グループセッションを開始し、参加するようユーザ1232および1220を招待する。招待先ユーザ1220は、トーク許可を有している。PPF 1222は、ユーザ1220によってサポートされるフォーマットから、招待元端末1224によってサポートされ、セッション確立時に合意されたフォーマットに、メディア流れをトランスコードする。たとえば、PPF 1222は、EVRCからAMRにトランスコードするが、これはAMRが招待元端末1224によってサポートされ、セッション確立時に合意され、したがってCPF 1226内を流れるフォーマットであるからである。招待元端末1224のPPF 1228は、トランスコーディングを実行しない。PPF 1230は通常、招待先端末1232のためのトランスコーディングを実行する。しかし、CPF 1226によって提供されるメディア流れが招待先端末1232によってサポートされるフォーマットであるため、PPF 1230は、トランスコーディングを実行する必要がないことを確認する。実際、端末1232が、端末1224に対してセッション確立時に合意され、CPF 1226内を流れるものと同じフォーマット/コーデックをサポートするため、誰が話しているかに関係なく、端末1232での端末1232へのおよび端末1232からのトランスコーディングは不要である。たとえば、この実施例では、AMRは常にCPF 1226内を流れ、またAMRは端末1232によってもサポートされるため、PPF 1230は、トランスコーディングを実行する必要がない。ここでも、要素1222、1228および1230は、それぞれ単一のサーバに組み込まれたPPFおよびTSの組み合わせを形成する。
残りの説明では、招待元端末によってサポートされ、セッション確立時に合意される(したがってCPF内を流れる)フォーマットを、「共通ストリームフォーマット」(CSF)と呼ぶ。
3.2 PoC参加機能によって管理されるメディア流れとトラフィックのタイプ
メディア流れについては、トランスコーディングスキームがCPFで中央集約化されている事例と同様に、図6および7に示されているように、2つのスキームを考慮できるが、以下の改変が伴う。すなわち、CPF 602または702の代わりに、PPFは、TS 604または704と対話している。TS がCPFではなくPPFと対話するという事実に加えて、主要な違いは、PPFまたはTSに到達するTB要求がCPFに転送され、TB応答がPPFまたはTSに到達する前にCPFから来るということである。
3.3 PoC参加機能によって管理されるセッション制御
PPFは、セッション管理の役割をほとんど持たない。たとえば、CPFと異なり、ローカルPPFは、特定のユーザについてのCSFからのまたはCSFへのトランスコーディングを管理するだけなので、セッションが依然として進行中であり、サービスするユーザが依然として参加している限り、新しいユーザがセッションに参加するかまたは離脱するかを気にかける必要はない。またローカルPPFは、誰がトーク許可を有するかを管理する必要はなく、最悪の事例では、それを監視するだけである。
したがって、図8のセッション流れと、図9の制御流れとは、TBCMもCPFへ/からルーティングされ、TSが招待先当事者のPPFと置換されることを除いて、この事例にも依然として適用されるであろう。
3.4 PPFで中央集約化された適合のための詳細な信号伝達流れ
PPFで実行されるトランスコーディングの事例のための詳細な信号伝達流れは、トランスコーディングがCPFで中央集約化される事例と非常に似たものになるであろう。図10は、トランスコーディングサーバとの対話が各招待先当事者のPPFで処理されるようになることを除いて、同じままになるであろう。各招待先端末のPPFは、その端末のサポートメディアフォーマットから/へCSFへ/からトランスコーディングを実行しなければならない。このためには、セッションを確立できるようにするために、招待先当事者のPPFがセッション記述を変更することも必要である。この変更は、図10のCPF 1002が行ったのと同じ方法で行われる。TS 1004への関数呼び出しもまた、似たものになるであろう。
4. 透過的PoCトランスコーディング
この項では、トランスコーディングが透過的PoCトランスコーディングである、本発明の第3の非制限的な例示的実施形態について説明する。透過的トランスコーディングとは、PoC端末およびサーバが、トランスコーディングが行われていることを認識せず、トランスコーディングが実行されていないコンテキストで任意の従来のPoCエンティティが動作するように動作することを意味する。トランスコーディングサーバは、通信経路内にプロキシとして挿入される。この方法の主要な利点は、既存のPoC端末およびサーバを改変する必要がないということである。実際、PoCシステムを既に配備している操作者は、既に配備しているPoC端末およびサーバを変更することなく、PoCトランスコーディングを追加できる。この方法は、マルチメディアメッセージングサービスにトランスコーディングを円滑に導入するのに効果的であることが証明されている。
4.1 CPFで中央集約化された透過的PoCトランスコーディング
この実施形態では、トランスコーディングサーバ(TS)は、ネットワークの中央位置に配置され、そのためCPFと同じ位置に配置されることになり、したがってCPFに対してこの特有の態様で配置されることの利点を利用できる。TSは、メディア経路内ではCPFの後ろに配置されるが、セッション制御経路内ではCPFの前に配置される。さらに、すべてのメディアパケット(通常のメディアおよびTBCP)は、メディアストリーム流れ内でTSの前に位置するCPFを通じて移動する。
図13のアーキテクチャ1300は、CPF 1302での透過的トランスコーディングのための例示的アーキテクチャを示している。メディア経路内にあるCPF 1302は、通常の着信メディアストリーム(複数も可)のコピーを作成し、それ(それら)をセッション内の他のユーザに分配しようと試みる。それらの出力ストリームのそれぞれは、TS 1304に入り、必要に応じて宛先端末の機能を満たすように個別にトランスコードされ、その後各宛先端末1306および1308に分配される。TBCPパケットもまた、TS 1304に入り、TS 1304はそれらのパケットをそれらの宛先に転送する。TS 1304は、CPF 1302から送信されるTCBPパケットの内容を監視するか、または非アクティブである通常の着信メディアストリームを識別することにより、誰がトーク許可を有するかを学習できる(話しているユーザは、CPF 1302によってメディアストリームが配信されないユーザであるため)。それに基づいて、TS 1304は、各宛先に対して実行するトランスコーディング操作を判定する。たとえば、話している人がAMRコーデックを使用する場合、EVRCコーデックをサポートするユーザに対しては、AMRからEVRCへのトランスコーディングを実行する必要があるが、話している人がAMRコーデックではなくEVRCコーデックを使用するのであれば、トランスコーディングは不要である。
さらに、図13では、CPF 1302は、すべての宛先ユーザについて、ユーザ1310から取得したAMRストリームのコピーを作成する。TS 1304は、それらのメディアストリームを傍受し、宛先ユーザ1306および1308の機能に合うようにそれらをトランスコードし、トランスコードされたメディアストリームを宛先に送信する。したがって、TS 1304に入る端末1306宛てのAMRメディアは、TS 1304からの出力時には端末1306のためのEVRCメディアとなり、一方でTS 1304への入力時に端末1308宛てであるAMRメディアは、TS 1304からの出力時には端末1308のためのAMRメディアのままである。TS 1304はまた、未変更のTBCPメッセージを各宛先ユーザ1306および1308に転送する。
メディアストリームがCPF 1302を通り、その後TS 1304を通って移動するためには、セッション確立プロセス中に、特定のSDP改変を加える必要がある。CPF 1302には、情報の送信先に関係なく、TS 1304のIPアドレスおよびポート情報が与えられる。ユーザには、情報の送信先に関係なく、CPF 1302のIPアドレスおよびポート情報が与えられる。TS 1304は、それらのIPアドレスおよびポートのセットと、異なるエンティティがデータの受信を期待する場所との間の接続を管理する。
図14は、CPF 1402で中央集約化された透過的トランスコーディングの場合の、CPF 1402、TS 1404ならびに端末1405および1406の間の詳細な信号伝達流れの例示的実施形態を示している。一般性を損なうことなく説明を簡素化するために、端末1405および1406のPPFは示していない。以下では、メディアストリーム手続きのリルートにおける、CPF 1402からTS 1404への、提供されるフォーマット/コーデックなどのセッション提供の変更について説明する。信号伝達流れは以下のとおりである。
1. PoCユーザ1405は、操作1410で、PoCボタンを押してグループセッションを開始する。
2. PoCユーザ1405は、メッセージ1412で、SDP情報を用いたセッション記述を含むSIP INVITEメソッドを発行する。SIP INVITEは、TS 1404によって傍受されるが、TS 1404は、たとえば、CPF 1402と同じネットワーク内に位置していてよい。たとえば、SDP-Aは、以下を含みうる。
c = IN IP6 FF1E:03AD::7F2E:172A:1E24
m=audio 3456 RTP/AVP 97
a= rtpmap: 97 AMR
a= rtcp:5560
m= application 2000 udp TBCP
a= fmtp:TCBP queuing=1; tb_priority=2; timestamp=1
3. TS 1404は、ユーザ1405に宛てられたすべてのメディアストリームがユーザ1405に配信される前にまずTS 1404に到達するように、ユーザ1405によって提供されたフォーマット/コーデックならびにIPアドレスおよびポート情報を変更する(図15の点線を参照)。TS 1404はまた、新たに提供されたSDPと、ユーザ1405によって最初に提供されたSDPとの間のバインディング情報を格納する。加えて、TS 1404は、ユーザ1405によって提供されるメディアフォーマット/コーデックからのまたはそれらへのトランスコーディングをサポートできるメディアフォーマット/コーデックを追加することにより、セッション記述を強化する。次に、TS 1404は、メッセージ1414で、更新されたSDPセッション記述を含む招待をCPF 1402に送信する。たとえば、TS 1404によって提供されるSDPは、以下を含みうる。
c=IN IP6 FF1E:03AD::7F2E:172A:1E30
m= audio 18456 RTP/AVP 97 98
a= rtpmap: 97 AMR
a= rtpmap: 98 EVRC/8000
a=rtcp:18080
m= application 18000 udp TBCP
a= fmtp:TCBP queuing=1; tb_priority=2; timestamp=1
行「C=」でIPアドレスがユーザ1405からTS 1404に置換され、行「a=」でEVRCコーデックが追加されていることに留意されたい。
4. CPF 1402は、SDPセッション記述を受信し、メディアストリームが最初にCPF 1402を通過するようにSDPセッション記述を修正する。CPF 1402は次に、メッセージ1416で、改変された招待をユーザ1406に送信する。CPF 1402はまた、着信パケットを正しい宛先に転送できるように、IPアドレスおよびポートのマッピングを把握する。たとえば、このマッピングは、図15で示されているようになる可能性がある(短い破線を参照)。
c =IN IP6 FF1E:03AD::7F2E:172A:1E28
m= audio 53456 RTP/AVP 97 98
a= rtpmap: 97 AMR
a=rtpmap: 98 EVRC/8000
a= rtcp:53080
m= application 50000 udp TBCP
a= fmtp:TCBP queuing=1; tb_priority=2; timestamp=1
5. アラートメッセージ1418がユーザ1406からTS 1404に送信される。
6. アラートメッセージ1420がTS 1404からCPF 1402に送信される。
7. アラートメッセージ1422がCPF 1402からユーザ1405に送信される。
8. ユーザ1406は、招待を受諾し、メッセージ1424で、SDP-AB'内の選択されたメディア情報を提供する。この要求は、TS 1404によって傍受される。たとえば、SDP-AB'は以下を含みうる。
c=IN IP6 FF1E:03AD::7F2E:172A:1E34
m=audio 5458 RTP/AVP 98
a=rtpmap: 98 EVRC/8000
a=rtcp: 5480
m= application 4000 udp TBCP
a=fmtp:TCBP queuing=1; tb_priority=2; timestamp=1
9. TS 1404は、トランスコーディングリソースおよびポートを予約し、メッセージ1426で、改変されたSDPセッションをCPF 1402に提供する。たとえば、このSDPは、以下のようになりうる。
c=IN IP6 FF1E:03AD::7F2E:172A:1E30
m= audio 28456 RTP/AVP 97
a= rtpmap: 97 AMR
a= rtcp: 28080
m= application 28000 udp TBCP
a= fmtp:TCBP queuing=1; tb_priority=2; timestamp=1
10. この情報応答は、CPF 1402がメディア経路内の最初に含まれるように、CPF 1402によってさらに改変される。CPF 1402はその後、メッセージ1428で、改変された応答をユーザ1405に送信する。たとえば、このSDPは、以下のようになりうる。
c=IN IP6 FF1E:03AD::7F2E:172A:1E28
m=audio 48456
a= rtpmap: 98 EVRC/8000
a= rtcp:48080
m= application 48000 udp TBCP
a= fmtp:TCBP queuing=1; tb_priority=2; timestamp=1
11. ユーザ1405に対する「トークバースト確認」メッセージが、メッセージ1430でCPF 1402によって開始され、TS 1404に到達する(TS 1404がメディア経路内でCPF 1402の後の次に位置するため)。
12. 「トークバースト確認」メッセージが、メッセージ1432で、TS 1404からユーザ1405に送信される。
13. 「トーク続行」通知が、通知1434でユーザ1405に送信される。
14. ユーザ1406に対する、メッセージ1436でのユーザ1408からの「トークバースト」の受信が、CPF 1402から開始され、TS 1404に到達する。これは、TS 1404がメディア経路内でCPF 1402の後の次に位置するからである。
15. メッセージ1438でのユーザ1405からの「トークバースト」の受信が、TS 1404からユーザ1406に送信される。
16. 「トーク実行者ID」通知が、通知1440でユーザ1406に送信される。
17. 流れ1442でユーザ1405から送信されるメディアパケットが、CPF 1402に到達するが、これはCPF 1402がメディア経路内で最初に存在するからである(図15の長い破線を参照)。
18. CPF 1402は、受信したメディアストリームを必要に応じて複製し、複製されたメディアストリームをメディア流れ1444でTS 1404に転送する。
19. TS 1404は、操作1446で、ストリームを必要に応じてトランスコードする。
20. TS 1404は、メディア流れ1448で、適合およびトランスコードされたメディアストリームをユーザ1406に転送する。
21. 残りの信号伝達流れは簡単である。ユーザ1406が話す場合、ユーザ1406からユーザ1408へのメディア流れは、図15の短い破線および点線で示されているようになる。
セッションに複数の端末が含まれる場合、CPF 1402およびTS 1404は、SDPの改変を実行して、(CPF 1402が経路内で最初に位置し、TS 1404がその次に位置するように)各参加端末のためにメディアストリームの経路を同様の方法で改変する。TS 1404およびCPF 1402はまた、適正なトランスコーディングおよびルーティングを実行するために、IPアドレスおよびポートのどの組が、どのセッション記述に属するかを認識する。
CPF 1402はメディア流れ内でTS 1404の前にあるが、TS 1404はセッション流れ内で常にCPF 1402の前にあることに注目することが重要である。これを確実にするには、ネットワーク内でIPスイッチを使用し、TS 1404から来ていないCPF 1402が宛先である各SIPパケットがTS 1404にルーティングされるようにする。実際、CPF 1402に宛てられたすべてのセッション制御メッセージは、最初にTS 1404を通って移動し、TS 1404は、メッセージの内容を修正できる。
最後に、図15は、トランスコーディングセッションの設定中のCPF 1504、TS 1506ならびに端末1502および1508の間のIPアドレスのルーティング実施例を示している。CPF 1504への着信トラフィックは、「1E28」で終わるIPアドレスを有する。TS 1506への着信トラフィックは、「1E30」で終わるIPアドレスを有する。また、TS 1506から端末1508に宛てられた発信トラフィックは、「1E24」で終わるIPアドレスを有する。TS 1506から端末1502に宛てられた発信トラフィックについては、これらの発信トラフィックは「1E34」で終わるIPアドレスを使用する。
アーキテクチャおよび信号伝達流れのためのいくつかの代替実装について説明したところで、本発明の多くの改変および他の実施形態が、本発明が属する技術分野の当業者には想起されるであろう。したがって、本発明は開示した具体的な実施形態に制限されず、改変および他の実施形態が添付の請求項の範囲内に含まれるものであるということを理解されたい。本明細書では具体的な用語を用いたが、これらは実装をPoCサービスの範囲内で明らかにするために使用されており、本発明の範囲を何らかの方法で制限することを目的に使用されているわけではない。
本発明について上述の明細書で非制限的な例示的実施形態を用いて説明したが、これらの実施形態は、本発明の精神および性質から逸脱することなく、添付の請求項の範囲内で随意に改変できる。
(参考文献)
[1] Open Mobile Alliance,”Push to Talk Over Cellular (PoC)-Architecture. OMAAD_PoC-V1_0-20041117-D.”
[2] 3GPP TS 26.235, “Packet switched conversational multimedia applications; Default codes (Release 6).”
[3] 3GPP2 S.R0100-0, “Push to Talk Over Cellular (PoC) System Requirements.”
[4] 3GPP TS 23.228, “IP Multimedia Subsystem (IMS); Stage 2.”
[5] 3GPP TS 24.229, “IP Multimedia Call Control based on SIP and SDP; Stage 3.”
[6] 3GPP2 X.S0013.2, “IP Multimedia Subsystem (IMS); Stage 2.”
[7] 3GPP2 X.S0013.4, “IP Multimedia Call Control Protocol, Based on SIP and SDP stage 3.”
[8] 3GPP TS 23.218, “Multimedia (IM) session handling; stage 2.”
[9] IETF RFC 3435, “Media Gateway Control Protocol; version 1.”
[10] IETF RFC 3525, “Gateway Control Protocol; version 1.”
[11] ITU Recommendation H.248, “Gateway control protocol.”
[12] E. Burger and Guy Redmill, “Media Services in the IMS: Evolution for Innovation,“ Brooktrouth Technology, May 2005.
[13] IETF RFC 2327, “SDP: Session Description Protocol.”
[14] Open Mobile Alliance, “Push to Talk Over Cellular (PoC)-Control Plane Document. OMA-TS-PoCControlPlane-V1_0.”
[15] Open Mobile Alliance, “Push to Talk Over Cellular (PoC)-User Plane. OMA-TS
-PoC-UserPlane-V1_0.”
100 PoCシステム
102 モバイル端末
104 伝送アンテナ
106 無線ネットワーク
108、110 受信アンテナ
200 汎用PoCアーキテクチャ
208 ローカルネットワーク
206 ローカルPoC参加機能(PPF)
212 中央ネットワーク
210 PoC制御機能(CPF)
218 ローカルネットワーク
216 ローカルPPF
300 PoCアプリケーションの高レベルアーキテクチャ
3021〜302N ローカルネットワーク
304 中央ネットワーク
312n トランスコーディングサーバ
316n トランスコーディングインターフェイス
318 トランスコーディングインターフェイス
310 中央ネットワーク要素CPF
400 セッション記述プロトコル(SDP)
500 システム
600 アーキテクチャ
604 トランスコーディングサーバ(TS)
700 アーキテクチャ
800 アーキテクチャ
900 アーキテクチャ
910 TB要求メッセージ
918 TB確認メッセージ
1000 例示的実施形態
1100 メディア流れアーキテクチャ
1200 アーキテクチャ
1300 アーキテクチャ

Claims (19)

  1. 少なくとも３つの端末間でのマルチユーザ通信セッションを確立するための方法であって、
    （ａ）セッションイニシエーションプロトコルを用いて、互換性のないメディア特性を有する端末を備えるユーザおよび互換性のあるメディア特性を有する端末を備えるユーザを前記通信セッションに参加するよう招待する段階と、
    （ａ１）前記セッションイニシエーションプロトコルを用いて前記端末を招待することに応答して、前記端末によってサポートされるメディア特性を含む前記端末から情報を受信する段階と、
    （ｂ）前記端末に関する前記情報は前記端末のメディア特性を含み、該情報に基づいて、前記端末間でのトランスコーディングを可能にするトランスコーディングセッションを設定する段階であって、
    トランスコーディングサーバを通じて前記トランスコーディングセッションを設定するために中央ネットワーク要素から要求を受信する段階、および
    前記トランスコーディングサーバによってサポートされるフォーマットおよびコーデックのリスト、および
    メディアストリームが互換性のあるメディア特性を有する端末間を直接フローし、かつ互換性のないメディア特性を有する端末間を前記トランスコーディングサーバを通じてフローするのを許容するためのIPアドレスおよびポートのリスト
    を含むトランスコーディングセッション情報を提供することを含む
    前記トランスコーディングサーバにおいてトランスコーディングリソースを確立する段階、
    を含む前記トランスコーディングセッションを設定する段階と、
    （ｃ）前記トランスコーディングセッションに従って通信セッション記述を確立する段階であって、前記通信セッション記述は、少なくとも一つの端末の少なくとも一つのメディア特性を含む段階と、
    （ｄ）前記通信セッション中に、前記トランスコーディングセッションに従って、前記トランスコーディングサーバを通じてフローするメディアストリームを、トランスコードし、前記トランスコードされたメディアストリームを、前記通信セッション記述に従って、他の端末に、メディアストリームにおけるパケットのヘッダを検査することなく、前記セッションイニシエーションプロトコルから得られる前記他の端末のメディア特性を使用して伝送する段階と、
    （ｄ１）前記通信セッション中に、新たなユーザが前記通信セッションに参加するときに前記新たなユーザの端末に関する情報に基づいて前記トランスコーディングセッションを更新すると共に、参加しているユーザが前記通信セッションを離脱するときに前記トランスコーディングセッションを更新する段階と
    を含む方法。
  2. （ｅ）前記段階（ａ）は、前記通信セッション記述を含む招待要求を前記少なくとも一つの端末から中央ネットワーク要素に伝送する段階を含み、または、
    （ｇ）前記段階（ｃ）において、前記メディア特性はコーデックである請求項１記載の方法。
  3. 前記段階（ｂ）は、
    （ｉ）前記トランスコーディングサーバを通るメディアストリームフローを確立する段階
    を更に含む請求項１記載の方法。
  4. （ｊ）前記段階（ｂ）は、セッション識別情報を含むトランスコーディングセッション情報を提供する段階を含み、または、
    （ｋ）前記段階（ｉ）において、前記メディアストリームフローは、トークバーストパケットおよびメディアパケットを含み、または、
    （ｌ）前記段階（ｉ）は、前記メディアストリームフロー、前記通信セッション、および中央ネットワーク要素を通じた前記トランスコーディングセッションを管理する段階を含み、または、
    （ｉｉ）前記段階（ｉ）は、すべてのメディアストリームフローを前記トランスコーディングサーバに供給する段階を含み、または、
    （ｉｉｉ）前記段階（ｉ）は、すべてのメディアストリームフローを中央ネットワーク要素に供給する段階を含む請求項３記載の方法。
  5. （ｍ）前記段階（ｊ）は、前記セッション識別情報を有する前記トランスコーディングセッション情報、前記ＩＰアドレスおよびポートのリスト、および前記端末のトランスコーディングフォーマットおよびコーデックを更新する段階を更に含み、
    （ｎ）前記段階（ｃ）は、前記更新されたトランスコーディングセッション情報に従って前記通信セッション記述を更新する段階を含む請求項４記載の方法。
  6. （ｐ）前記段階（ｍ）は、各ユーザの前記端末によって供給される情報に基づいて前記トランスコーディングサーバを通る前記メディアストリームフロー及び前記トランスコーディングリソースを更新する段階を更に含み、
    （ｒ）ここで、前記トランスコーディングリソース及び前記メディアストリームフローを更新する段階は、実行すべきトランスコーディング操作と、トランスコードされたメディアストリームが送信されるべき前記ＩＰアドレス及びポートを判定する段階を含む請求項５記載の方法。
  7. （ｓ）前記段階（ｋ）では、前記トークバーストパケットは、前記端末と前記中央ネットワーク要素との間のトーク要求および応答を含み、または、
    （ｔ）前記段階（ｋ）では、前記メディアパケットは、前記トランスコーディングサーバでトランスコードされ、前記トークバーストパケットは、前記中央ネットワーク要素に転送され、または、
    （ｕ）前記段階（ｋ）では、前記メディアパケットのみが前記トランスコーディングサーバに転送され、または、
    （ｖ）前記段階（ｌ）では、前記トランスコーディングは、前記端末が配置されたローカルネットワークによって更に管理され、トーク許可は、前記中央ネットワーク要素によって管理される請求項４記載の方法。
  8. 少なくとも３つの端末間でのマルチユーザ通信セッションを確立するためのシステムであって、
    （ａ）セッションイニシエーションプロトコルを用いて、互換性のないメディア特性を有する端末を備えるユーザおよび互換性のあるメディア特性を有する端末を備えるユーザを前記通信セッションに参加するよう招待するための手段と、
    （ａ１）前記セッションイニシエーションプロトコルを用いて前記端末を招待することに応答して、前記端末によってサポートされるメディア特性を含む前記端末から情報を受信するための手段と、
    （ｂ）前記端末に関する前記情報は前記端末のメディア特性を含み、該情報に基づいて、前記端末間でのトランスコーディングを可能にするトランスコーディングセッションを設定する手段であって、
    トランスコーディングサーバを通じて前記トランスコーディングセッションを設定するために中央ネットワーク要素から要求を受信する手段、および
    前記トランスコーディングサーバによってサポートされるフォーマットおよびコーデックのリスト、および
    メディアストリームが互換性のあるメディア特性を有する端末間を直接フローし、かつ互換性のないメディア特性を有する端末間を前記トランスコーディングサーバを通じてフローするのを許容するためのIPアドレスおよびポートのリスト
    を含むトランスコーディングセッション情報を提供することを含む
    前記トランスコーディングサーバにおいてトランスコーディングリソースを確立する手段、
    を含む前記トランスコーディングセッションを設定する手段と、
    （ｃ）前記トランスコーディングセッションに従って通信セッション記述を確立するための手段であって、前記通信セッション記述は、少なくとも一つの端末の少なくとも一つのメディア特性を含む手段と、
    （ｄ）前記トランスコーディングセッションに従って、前記トランスコーディングサーバを通じてフローするメディアストリームをトランスコードし、前記トランスコードされたメディアストリームを、前記通信セッション記述に従って、他の端末に、メディアストリームにおけるパケットのヘッダを検査することなく、前記セッションイニシエーションプロトコルから得られる前記他の端末のメディア特性を使用して伝送するための手段と、
    （ｄ１）前記通信セッション中に、新たなユーザが前記通信セッションに参加するときに前記新たなユーザの端末に関する情報に基づいて前記トランスコーディングセッションを更新すると共に、参加しているユーザが前記通信セッションを離脱するときに前記トランスコーディングセッションを更新するための手段と
    を含むシステム。
  9. （ｅ）前記手段（ａ）はネットワーク要素を備え、該ネットワーク要素は、
    （ｅ１）中央ネットワーク要素、または、
    （ｅ２）ユーザの端末を包含するローカルネットワークの要素からなるローカルネットワーク要素
    のうちの１又は２以上を備えた請求項８記載のシステム。
  10. （ｆ）前記中央ネットワーク要素は、メディアストリームフロー、前記通信セッション、および前記トランスコーディングセッションを管理するための手段を備え、
    または、
    （ｆ１）前記中央ネットワーク要素および前記ローカルネットワーク要素の両方は、メディアストリームフロー、前記通信セッション、および前記トランスコーディングセッションを管理するための手段を備えた請求項９記載のシステム。
  11. （ｇ）前記手段（ａ）は、前記通信セッション記述を含む招待要求を前記少なくとも一つの端末から中央ネットワーク要素に伝送するための手段を含み、または、
    （ｉ）前記手段（ｃ）において、前記メディア特性はコーデックである
    請求項８乃至１０の何れか１項記載のシステム。
  12. 前記手段（ｂ）は、
    （ｋ）前記トランスコーディングサーバを通るメディアストリームフローを確立するための手段を更に備えた請求項１１記載のシステム。
  13. 前記トランスコーディングサーバは、
    （ｌ）トランスコーディングセッション情報を提供するための手段を更に備えた請求項１１または１２記載のシステム。
  14. （ｍ）前記手段（ｌ）は、
    セッション識別情報を提供し、または、
    （ｎ）前記手段（ｋ）において、前記メディアストリームフローは、トークバーストパケットおよびメディアパケットを含み、または、
    （ｐ）前記手段（ｋ）は、すべてのメディアストリームフローを前記トランスコーディングサーバに供給するための手段を含み、または、
    （ｒ）前記手段（ｋ）は、すべてのメディアストリームフローを前記中央ネットワーク要素に供給するための手段を備えた請求項１３記載のシステム。
  15. 前記トランスコーディングサーバは、
    前記ユーザの前記端末に関する情報を有する前記トランスコーディングセッション情報を更新するための手段、または、
    前記更新されたトランスコーディングセッション情報に従って前記通信セッション記述を更新するための手段、または、
    各ユーザの前記端末によって供給される情報に基づいて前記トランスコーディングサーバを通る前記メディアストリームフロー及び前記トランスコーディングリソースを更新するための手段、または、
    実行すべきトランスコーディング操作と、トランスコードされたメディアストリームが送信されるべき前記ＩＰアドレス及びポートのリストを判定するための手段、または、
    メディアパケットをトランスコーディングするための手段および前記トークバーストパケットを前記中央ネットワーク要素に転送するための手段、または、
    前記メディアパケットのみを受信してトランスコーディングするための手段のうちの１又は２以上を更に備えた請求項１３または１４記載のシステム。
  16. 前記トークバーストパケットは、前記端末と前記中央ネットワーク要素との間のトーク要求および応答を含む請求項１４または１５記載のシステム。
  17. 前記トランスコーディングサーバは、複数のトランスコーディングサーバを含み、各トランスコーディングサーバは、ユーザの端末を包含するローカルネットワークの要素からなる各ローカルネットワーク要素に接続され、前記各ローカルネットワーク要素は、前記トランスコーディングサーバを管理するための手段を備えた請求項８記載のシステム。
  18. 前記トランスコーディングサーバは、前記少なくとも一つの端末から前記中央ネットワーク要素への前記招待要求を傍受し、前記中央ネットワーク要素と前記少なくとも一つの端末との間の通信経路内のプロキシサーバとして機能するための手段を備えた請求項１１乃至１７の何れか１項記載のシステム。
  19. 前記中央ネットワーク要素は、どの端末がトーク許可を有するかを前記トランスコーディングサーバに通知するための手段を備え、または、
    前記トランスコーディングサーバは、前記トークバーストパケットを調べることにより、どの端末がトーク許可を有するかを推論する請求項１４乃至１８の何れか１項記載のシステム。
JP2014093620A 2005-12-28 2014-04-30 マルチメディアセッションのためのマルチユーザリアルタイムトランスコーディングシステムおよび方法 Active JP5749375B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US75419405P 2005-12-28 2005-12-28
US60/754,194 2005-12-28

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2008547817A Division JP2009522830A (ja) 2005-12-28 2006-12-27 マルチメディアセッションのためのマルチユーザリアルタイムトランスコーディングシステムおよび方法

Publications (2)

Publication Number Publication Date
JP2014150584A true JP2014150584A (ja) 2014-08-21
JP5749375B2 JP5749375B2 (ja) 2015-07-15

Family

ID=38217652

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2008547817A Withdrawn JP2009522830A (ja) 2005-12-28 2006-12-27 マルチメディアセッションのためのマルチユーザリアルタイムトランスコーディングシステムおよび方法
JP2014093620A Active JP5749375B2 (ja) 2005-12-28 2014-04-30 マルチメディアセッションのためのマルチユーザリアルタイムトランスコーディングシステムおよび方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2008547817A Withdrawn JP2009522830A (ja) 2005-12-28 2006-12-27 マルチメディアセッションのためのマルチユーザリアルタイムトランスコーディングシステムおよび方法

Country Status (8)

Country Link
US (2) US8019371B2 (ja)
EP (1) EP1987684A4 (ja)
JP (2) JP2009522830A (ja)
KR (1) KR101307021B1 (ja)
CN (1) CN101390415B (ja)
CA (1) CA2633398C (ja)
IL (1) IL192326A (ja)
WO (1) WO2007073602A1 (ja)

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0500483D0 (en) * 2005-01-11 2005-02-16 Nokia Corp Multi-party sessions in a communication system
US7366972B2 (en) * 2005-04-29 2008-04-29 Microsoft Corporation Dynamically mediating multimedia content and devices
US8582559B2 (en) * 2006-08-03 2013-11-12 Aspect Software, Inc. System and method for handling media streams
CN101822093A (zh) * 2007-08-14 2010-09-01 爱立信电话股份有限公司 编解码器协商和选择中的或与之相关的改进
US8311058B2 (en) * 2008-05-10 2012-11-13 Vantrix Corporation Modular transcoding pipeline
CN101388883B (zh) * 2007-09-12 2012-04-25 华为技术有限公司 多媒体会话中特定设备的管理方法、系统和设备
JP5044380B2 (ja) * 2007-12-04 2012-10-10 株式会社日立国際電気 配信装置及びコーデック変換装置、通信システム
US8855103B2 (en) 2008-01-17 2014-10-07 Blackberry Limited Personal network access control system and method
CN102160353B (zh) * 2008-09-19 2015-07-22 爱立信电话股份有限公司 用于建立poc会话的方法和设备
KR101489432B1 (ko) * 2008-12-16 2015-02-03 삼성전자주식회사 접속 설정 프로토콜 기반의 브이오 아이피 네트워크에서 미디어 코덱 결정 방법 및 장치
CN101938648B (zh) * 2009-10-15 2012-08-15 北京暴风科技股份有限公司 一种媒体文件格式转换方法及系统
US9628831B2 (en) 2010-03-25 2017-04-18 Whatsapp, Inc. Multimedia transcoding method and system for mobile devices
US8995965B1 (en) 2010-03-25 2015-03-31 Whatsapp Inc. Synthetic communication network method and system
GB2495435A (en) * 2010-06-29 2013-04-10 Zte Usa Inc Method and system for cloud-based media adaption and transcoding service
WO2012015908A2 (en) 2010-07-30 2012-02-02 Millipore Corporation Chromatography media and method
JP5656712B2 (ja) * 2011-03-29 2015-01-21 西日本電信電話株式会社 通信制御装置、通信制御方法
CN103548369B (zh) 2011-06-09 2017-07-21 松下电器（美国）知识产权公司 网络节点、终端、带宽变更判断方法及带宽变更方法
CN102347947B (zh) * 2011-09-21 2015-01-21 杭州海康威视数字技术股份有限公司 一种流媒体适配器、流媒体网络交互的系统及方法
US8832298B2 (en) 2012-03-16 2014-09-09 Qualcomm Incorporated Managing early media for communication sessions established via the session initiation protocol (SIP)
CA2791935A1 (en) 2012-03-30 2013-09-30 Disternet Technology, Inc. Transcoding system and method
US9246741B2 (en) * 2012-04-11 2016-01-26 Google Inc. Scalable, live transcoding with support for adaptive streaming and failover
KR20130138497A (ko) * 2012-06-11 2013-12-19 주식회사 케이티 발신단말로의 음원 송출 방법 및 이를 위한 통신 시스템
CN103051927A (zh) * 2012-12-28 2013-04-17 捷思锐科技（北京）有限公司 一种流媒体转码控制方法及装置和流媒体转码装置
WO2014127787A1 (de) * 2013-02-22 2014-08-28 Unify Gmbh & Co. Kg Verfahren zur steuerung von datenströmen einer virtuellen sitzung mit mehreren teilnehmern, kollaborationsserver, computerprogramm, computerprogrammprodukt und digitales speichermedium
JP6347115B2 (ja) * 2013-02-28 2018-06-27 株式会社リコー 通信管理システム、通信管理方法、及びプログラム
US9408241B2 (en) * 2013-10-09 2016-08-02 At&T Intellectual Property I, Lp Method and apparatus for mitigating network failures
EP3113489A4 (en) * 2014-02-28 2017-04-26 Ricoh Company, Ltd. Transfer control system, transfer system, transfer control method, and recording medium
US9660836B2 (en) 2014-05-06 2017-05-23 Lattice Semiconductor Corporation Network topology discovery
US9590825B2 (en) * 2014-05-09 2017-03-07 Lattice Semiconductor Corporation Stream creation with limited topology information
US9774687B2 (en) * 2014-07-07 2017-09-26 Twilio, Inc. System and method for managing media and signaling in a communication platform
KR101581947B1 (ko) * 2014-07-17 2015-12-31 주식회사 케이티 선택적 트랜스코딩 시스템 및 방법
CA2954425C (en) 2014-09-02 2019-05-07 Emd Millipore Corporation High surface area fiber media with nano-fibrillated surface features
EP3230299A1 (en) 2014-12-08 2017-10-18 EMD Millipore Corporation Mixed bed ion exchange adsorber
CN106912030B (zh) * 2015-12-22 2021-03-12 大唐移动通信设备有限公司 一种组呼方法及装置
AU2016415048B2 (en) * 2016-07-15 2020-05-07 Huawei Technologies Co., Ltd. Method for applying for media transmission permission, and method and apparatus for canceling media transmission permission
US11310868B2 (en) * 2017-03-31 2022-04-19 Telefonaktiebolaget Lm Ericsson (Publ) Application topology aware user plane selection in NR and 5GC
US11083028B2 (en) 2017-03-31 2021-08-03 Telefonaktiebolaget Lm Ericsson (Publ) Coordinated selection of user plane functions in core and radio access networks
EP3831028A4 (en) * 2018-08-01 2022-05-25 Telefonaktiebolaget Lm Ericsson (Publ) METHODS AND DEVICES FOR IMPROVING AN IP MULTIMEDIA SUBSYSTEM
CN115002081B (zh) * 2022-05-30 2023-12-26 重庆紫光华山智安科技有限公司 媒体流传输方法及相关装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003152820A (ja) * 2001-11-19 2003-05-23 Nec Corp シグナリング中継システムおよびシグナリング中継方法
JP2005039724A (ja) * 2003-07-18 2005-02-10 Motorola Inc 通信制御方法及び通信制御装置
WO2005101876A1 (fr) * 2004-03-17 2005-10-27 France Telecom Procede, serveur et systeme de gestion d’une session «push-to-talk»

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6208345B1 (en) * 1998-04-15 2001-03-27 Adc Telecommunications, Inc. Visual data integration system and method
US20030028643A1 (en) * 2001-03-13 2003-02-06 Dilithium Networks, Inc. Method and apparatus for transcoding video and speech signals
US7688764B2 (en) * 2002-06-20 2010-03-30 Motorola, Inc. Method and apparatus for speaker arbitration in a multi-participant communication session
US20040121729A1 (en) * 2002-10-24 2004-06-24 Chris Herndon Telecommunications infrastructure linkage method and system
JP2004165742A (ja) * 2002-11-08 2004-06-10 Matsushita Electric Ind Co Ltd グループ通信配送路制御方法及びグループ通信システム
KR20050000025A (ko) * 2003-06-23 2005-01-03 주식회사 케이티 Ｓｉｐ 기반의 망에서 가입자의 미디어 정보를 이용한 호처리 시스템 및 방법
US20050060411A1 (en) * 2003-09-16 2005-03-17 Stephane Coulombe System and method for adaptation of peer-to-peer multimedia sessions
US8886824B2 (en) * 2004-01-26 2014-11-11 Core Wireless Licensing, S.a.r.l. Media adaptation determination for wireless terminals
EP1728402B1 (fr) 2004-03-17 2018-05-16 Orange Procede, serveur et systeme de gestion d"une session «push-to-talk»
KR20070004103A (ko) * 2004-04-23 2007-01-05 노키아 코포레이션 그룹 초대
US7983706B2 (en) * 2004-09-07 2011-07-19 At&T Intellectual Property I, L.P. System and method for voice and text based service interworking
US7359731B2 (en) * 2004-09-09 2008-04-15 Nextel Communications Inc. Architecture to facilitate interoperability and inter-working of push to talk technologies
US20070033592A1 (en) * 2005-08-04 2007-02-08 International Business Machines Corporation Method, apparatus, and computer program product for adaptive process dispatch in a computer system having a plurality of processors

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003152820A (ja) * 2001-11-19 2003-05-23 Nec Corp シグナリング中継システムおよびシグナリング中継方法
JP2005039724A (ja) * 2003-07-18 2005-02-10 Motorola Inc 通信制御方法及び通信制御装置
WO2005101876A1 (fr) * 2004-03-17 2005-10-27 France Telecom Procede, serveur et systeme de gestion d’une session «push-to-talk»

Also Published As

Publication number Publication date
JP2009522830A (ja) 2009-06-11
CN101390415B (zh) 2012-07-18
IL192326A (en) 2016-03-31
CA2633398C (en) 2012-02-28
EP1987684A4 (en) 2015-04-15
KR20080108405A (ko) 2008-12-15
JP5749375B2 (ja) 2015-07-15
US8285316B2 (en) 2012-10-09
KR101307021B1 (ko) 2013-09-11
IL192326A0 (en) 2008-12-29
EP1987684A1 (en) 2008-11-05
CA2633398A1 (en) 2007-07-05
WO2007073602A1 (en) 2007-07-05
US8019371B2 (en) 2011-09-13
CN101390415A (zh) 2009-03-18
US20100004014A1 (en) 2010-01-07
US20120021796A1 (en) 2012-01-26

Similar Documents

Publication Publication Date Title
JP5749375B2 (ja) マルチメディアセッションのためのマルチユーザリアルタイムトランスコーディングシステムおよび方法
JP5294841B2 (ja) プッシュツートークオーバーセルラーネットワークの端末分離方法及びそのシステム
KR101214326B1 (ko) 멀티미디어 통신 시스템에서 여러 서비스를 제공하는 방법및 장치
RU2394393C2 (ru) Пользовательское оборудование, способ и система для управления одновременным сеансом связи
US8145250B2 (en) Method for managing pre-established session, PoC system and PoC user equipment for implementing the same
US20090279455A1 (en) Method, a device and a system for converging ip message
US8670354B2 (en) Sharing ongoing data session
JP2009530928A (ja) ドメイン間グループ通信
JP2008536392A (ja) プッシュツートークオーバーセルラー網のメディア格納サービス実行方法及びそのシステム
CN100409701C (zh) 控制集群系统无线一键通方式讲话权的方法
JP5241275B2 (ja) グループ通信サーバ、通信端末および通信システム
CN103139216B (zh) 管理无线一键通话会话支持的媒体类型的方法和用户设备
US20080039065A1 (en) Data transmission in a communication session
CN100544466C (zh) 实现按键即说业务的蜂窝系统及方法
Katrinis et al. A Comparison of Frameworks for Multimedia Conferencing: SIP and H. 323
Coulombe Real-time multi-user transcoding for Push to talk over Cellular
EP1729475A1 (en) SIP based floor control method in "Push to" over cellular services
Tam Collaboration-Oriented Modeling of an Offshore Group Communication System
Doan-Thi-Hong Collaboration-Oriented Modeling Of An Offshore Group Communication System

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150209

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20150212

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150326

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20150413

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150513

R150 Certificate of patent or registration of utility model

Ref document number: 5749375

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250