[要約] RFC 7310は、標準的なapt-Xおよびエンハンスドapt-XコーデックのためのRTPペイロード形式に関する仕様です。このRFCの目的は、apt-Xコーデックを使用したリアルタイム通信の品質を向上させるための標準化を提供することです。
Internet Engineering Task Force (IETF) J. Lindsay
Request for Comments: 7310 H. Foerster
Category: Standards Track APT Ltd
ISSN: 2070-1721 July 2014
RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs
標準apt-Xおよび拡張apt-XコーデックのRTPペイロード形式
Abstract
概要
This document specifies a scheme for packetizing Standard apt-X or Enhanced apt-X encoded audio data into Real-time Transport Protocol (RTP) packets. The document describes a payload format that permits transmission of multiple related audio channels in a single RTP payload and a means of establishing Standard apt-X and Enhanced apt-X connections through the Session Description Protocol (SDP).
このドキュメントでは、標準のapt-Xまたは拡張apt-Xでエンコードされたオーディオデータをリアルタイムトランスポートプロトコル（RTP）パケットにパケット化するためのスキームを指定します。このドキュメントでは、単一のRTPペイロードで複数の関連するオーディオチャネルの送信を可能にするペイロード形式と、Session Description Protocol（SDP）を介して標準apt-Xおよび拡張apt-X接続を確立する方法について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7310.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7310で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions .....................................................3
3. Standard apt-X and Enhanced apt-X Codecs ........................3
4. Payload Format Capabilities .....................................5
4.1. Use of Forward Error Correction (FEC) ......................5
5. Payload Format ..................................................5
5.1. RTP Header Usage ...........................................5
5.2. Payload Structure ..........................................6
5.3. Default Packetization Interval .............................7
5.4. Implementation Considerations ..............................8
5.5. Payload Example ............................................8
6. Payload Format Parameters ......................................10
6.1. Media Type Definition .....................................10
6.2. Mapping to SDP ............................................12
6.2.1. SDP Usage Examples .................................13
6.2.2. Offer/Answer Considerations ........................14
7. IANA Considerations ............................................14
8. Security Considerations ........................................14
9. Acknowledgements ...............................................14
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative References ...................................15
This document specifies the payload format for packetization of audio data encoded with the Standard apt-X or Enhanced apt-X audio coding algorithms into the Real-time Transport Protocol (RTP) [RFC3550].
このドキュメントでは、標準apt-Xまたは拡張apt-Xオーディオコーディングアルゴリズムでエンコードされたオーディオデータをリアルタイムトランスポートプロトコル（RTP）[RFC3550]にパケット化するためのペイロード形式を指定します。
The document outlines some conventions, a brief description of the operating principles of the audio codecs, and the payload format capabilities. The RTP payload format is detailed, and a relevant example of the format is provided. The media type, its mappings to SDP [RFC4566], and its usage in the SDP offer/answer model are also specified. Finally, some security considerations are outlined.
このドキュメントでは、いくつかの規則、オーディオコーデックの動作原理の簡単な説明、およびペイロード形式機能について概説しています。 RTPペイロード形式が詳細であり、形式の関連する例が提供されます。メディアタイプ、SDP [RFC4566]へのマッピング、およびSDPオファー/アンサーモデルでの使用法も指定されています。最後に、セキュリティに関するいくつかの考慮事項について概説します。
This document registers a media type (audio/aptx) for the RTP payload format for the Standard apt-X and Enhanced apt-X audio codecs.
このドキュメントでは、標準apt-Xおよび拡張apt-XオーディオコーデックのRTPペイロード形式のメディアタイプ（audio / aptx）を登録します。
This document uses the normal IETF bit-order representation. Bit fields in figures are read left to right and then down. The leftmost bit in each field is the most significant. The numbering starts from 0 and ascends, where bit 0 will be the most significant.
このドキュメントでは、通常のIETFビット順表現を使用しています。図のビットフィールドは、左から右、そして下に読み込まれます。各フィールドの左端のビットが最も重要です。番号付けは0から始まり、昇順です。ビット0が最も重要です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
Standard apt-X and Enhanced apt-X are proprietary audio coding algorithms, which can be licensed from CSR plc. and are widely deployed in a variety of audio processing equipment. For commercial reasons, the detailed internal operations of these algorithms are not described in standards or reference documents. However, the data interfaces to implementations of these algorithms are very simple and allow easy RTP packetization of data coded with the algorithms without detailed knowledge of the actual coded audio stream syntax.
標準apt-Xおよび拡張apt-Xは、CSR plcからライセンスを取得できる独自のオーディオコーディングアルゴリズムです。そして、さまざまなオーディオ処理機器に広く展開されています。商業上の理由から、これらのアルゴリズムの詳細な内部操作は、標準または参照ドキュメントには記載されていません。ただし、これらのアルゴリズムの実装へのデータインターフェイスは非常にシンプルで、実際にコード化されたオーディオストリーム構文の詳細な知識がなくても、アルゴリズムでコード化されたデータのRTPパケット化を簡単に行うことができます。
Both the Standard apt-X and Enhanced apt-X coding algorithms are based on Adaptive Differential Pulse Code Modulation principles. They produce a constant coded bit rate that is scaled according to the sample frequency of the uncoded audio. This constant rate is 1/4 of the bit rate of the uncoded audio, irrespective of the resolution (number of bits) used to represent an uncoded audio sample. For example, a 1.536-Mbit/s stereo audio stream composed of two channels of 16-bit Pulse Code Modulated (PCM) audio that is sampled at a frequency of 48 kHz is encoded at 384 kbit/s.
標準のapt-Xと拡張apt-Xのコーディングアルゴリズムはどちらも、適応型差分パルスコード変調の原理に基づいています。それらは、コード化されていないオーディオのサンプル周波数に従ってスケーリングされる一定のコード化されたビットレートを生成します。この一定レートは、コード化されていないオーディオサンプルの表現に使用される解像度（ビット数）に関係なく、コード化されていないオーディオのビットレートの1/4です。たとえば、48 kHzの周波数でサンプリングされた16ビットのパルスコード変調（PCM）オーディオの2つのチャネルで構成される1.536 Mbit / sのステレオオーディオストリームは、384 kbit / sでエンコードされます。
Standard apt-X and Enhanced apt-X do not enforce a coded frame structure, and the coded data forms a continuous coded sample stream with each coded sample capable of regenerating four PCM samples when decoded. The Standard apt-X algorithm encodes four successive 16-bit PCM samples from each audio channel into a single 16-bit coded sample per audio channel. The Enhanced apt-X algorithm encodes four successive 16-bit or 24-bit PCM samples from each audio channel and respectively produces a single 16-bit or 24-bit coded sample per channel. The same RTP packetization rules apply for each of these algorithmic variations.
標準のapt-Xと拡張apt-Xはコード化フレーム構造を強制せず、コード化されたデータは連続的なコード化サンプルストリームを形成し、各コード化サンプルはデコード時に4つのPCMサンプルを再生成できます。標準のapt-Xアルゴリズムは、各オーディオチャネルからの4つの連続する16ビットPCMサンプルを、オーディオチャネルごとに1つの16ビットコードサンプルにエンコードします。拡張apt-Xアルゴリズムは、各オーディオチャネルからの4つの連続する16ビットまたは24ビットPCMサンプルをエンコードし、チャネルごとに1つの16ビットまたは24ビットのコード化サンプルをそれぞれ生成します。これらのアルゴリズムのバリエーションのそれぞれに、同じRTPパケット化ルールが適用されます。
Standard apt-X and Enhanced apt-X coded data streams can optionally carry synchronization information and an auxiliary data channel within the coded audio data without additional overhead. These mechanisms can, for instance, be used when the IP system is cascaded with another transportation system and the decoder is acting as a simple bridge between the two systems. Since auxiliary data channel and synchronization information are carried within the coded audio data without additional overhead, RTP payload format rules do not change if they are present. Out-of-band signaling is required, however, to notify the receiver end when autosync and auxiliary data have been embedded in the apt-X stream.
標準のapt-Xおよび拡張apt-Xコード化データストリームは、オプションで、追加のオーバーヘッドなしに、コード化されたオーディオデータ内で同期情報と補助データチャネルを伝送できます。これらのメカニズムは、たとえば、IPシステムが別のトランスポートシステムとカスケード接続されており、デコーダーが2つのシステム間の単純なブリッジとして機能している場合に使用できます。補助データチャネルと同期情報は、追加のオーバーヘッドなしでコード化されたオーディオデータ内で伝送されるため、RTPペイロード形式のルールが存在しても変更されません。ただし、自動同期データと補助データがapt-Xストリームに埋め込まれたときに受信側に通知するには、帯域外シグナリングが必要です。
Embedded auxiliary data is typically used to transport non-audio data and timecode information for synchronization with video. The bit rate of the auxiliary data channel is 1/4 of the sample frequency. For example, with a single audio channel encoded at Fs = 48 kHz, an auxiliary data bit rate of 12 kbit/s can be embedded.
埋め込まれた補助データは、通常、ビデオと同期するために非オーディオデータとタイムコード情報を転送するために使用されます。補助データチャネルのビットレートは、サンプル周波数の1/4です。たとえば、Fs = 48 kHzでエンコードされた単一のオーディオチャネルでは、12 kbit / sの補助データビットレートを埋め込むことができます。
apt-X further provides a means of stereo-pairing apt-X channels so that the embedded autosync and auxiliary data channel can be shared across the channel pair. In the case of a 1.536-Mbit/s stereo audio stream composed of two channels of 16-bit PCM audio that is sampled at 48 kHz, a byte of auxiliary data would typically be fed into the Standard apt-X or Enhanced apt-X encoder once every 32 uncoded left channel samples. By default, apt-X channel-pairing is not enabled. Out-of-band signaling is required to notify the receiver when the option is being used.
apt-Xはさらに、apt-Xチャネルをステレオペアリングする手段を提供するため、埋め込まれた自動同期および補助データチャネルをチャネルペア全体で共有できます。 48 kHzでサンプリングされた16ビットPCMオーディオの2つのチャネルで構成される1.536 Mbit / sステレオオーディオストリームの場合、1バイトの補助データが通常、標準apt-Xまたは拡張apt-Xに供給されます。 32のコード化されていない左チャネルサンプルごとに1回エンコーダ。デフォルトでは、apt-Xチャネルペアリングは有効になっていません。オプションが使用されているときにレシーバーに通知するには、帯域外シグナリングが必要です。
Standard apt-X and Enhanced apt-X decoders that have not been set up with the correct embedded autosync, auxiliary data, and stereo-pairing information will play out uncoded PCM samples with a loss of decoding quality. In the case of Standard apt-X, the loss of quality can be significant.
正しい埋め込まれた自動同期、補助データ、およびステレオペアリング情報が設定されていない標準のapt-Xおよび拡張apt-Xデコーダーは、コード化されていないPCMサンプルを再生しますが、デコード品質は低下します。標準のapt-Xの場合、品質の低下が著しくなる可能性があります。
Further details on the algorithm operation can be obtained from CSR plc.
アルゴリズム操作の詳細については、CSR plcから入手できます。
Corporate HQ Churchill House Cambridge Business Park Cowley Road Cambridge CB4 0WZ UK Tel: +44 1223 692000 Fax: +44 1223 692001 <http://www.csr.com>
本社HQチャーチルハウスケンブリッジビジネスパークカウリーロードケンブリッジCB4 0WZ UK電話：+44 1223 692000ファックス：+44 1223 692001 <http://www.csr.com>
This RTP payload format carries an integer number of Standard apt-X or Enhanced apt-X coded audio samples. When multiple related audio channels are being conveyed within the payload, each channel contributes the same integer number of apt-X coded audio samples to the total carried by the payload.
このRTPペイロード形式は、整数の標準apt-Xまたは拡張apt-Xコード化オーディオサンプルを伝送します。ペイロード内で複数の関連するオーディオチャネルが伝達される場合、各チャネルは、ペイロードによって運ばれる合計に同じ整数のapt-Xコード化オーディオサンプルを提供します。
Standard apt-X and Enhanced apt-X do not inherently provide any mechanism for adding redundancy or error-control coding into the coded audio stream. Generic schemes for RTP, such as forward error correction as described in RFC 5109 [RFC5109] and RFC 2733 [RFC2733], can be used to add redundant information to Standard apt-X and Enhanced apt-X RTP packet streams, making them more resilient to packet losses at the expense of a higher bit rate.
標準のapt-Xおよび拡張apt-Xは、コード化されたオーディオストリームに冗長性またはエラー制御コーディングを追加するメカニズムを本質的に提供しません。 RFC 5109 [RFC5109]やRFC 2733 [RFC2733]で説明されている前方誤り訂正などのRTPの一般的なスキームを使用して、標準のapt-Xおよび拡張apt-X RTPパケットストリームに冗長情報を追加し、回復力を高めることができます。より高いビットレートを犠牲にしてパケット損失に。
The Standard apt-X and Enhanced apt-X algorithms encode four successive PCM samples from each audio channel and produce a single compressed sample for each audio channel. The encoder MUST be presented with an integer number S of input audio samples, where S is an arbitrary multiple of 4. The encoder will produce exactly S/4 coded audio samples. Since each coded audio sample is either 16 or 24 bits, the amount of coded audio data produced upon each invocation of the encoding process will be an integer number of bytes. RTP packetization of the encoded data SHALL be on a byte-by-byte basis.
標準apt-Xおよび拡張apt-Xアルゴリズムは、各オーディオチャネルからの4つの連続するPCMサンプルをエンコードし、各オーディオチャネルに対して単一の圧縮サンプルを生成します。エンコーダーは、整数Sの入力オーディオサンプルで提示する必要があります。ここで、Sは4の任意の倍数です。エンコーダーは、正確にS / 4コード化オーディオサンプルを生成します。各コード化オーディオサンプルは16ビットまたは24ビットのいずれかであるため、エンコーディングプロセスの呼び出しごとに生成されるコード化オーディオデータの量は、整数バイトになります。エンコードされたデータのRTPパケット化は、バイト単位で行う必要があります。
Utilization of the Standard apt-X and Enhanced apt-X coding algorithms does not create any special requirements with respect to the contents of the RTP packet header. Other RTP packet header fields are defined as follows.
標準apt-Xおよび拡張apt-Xコーディングアルゴリズムを使用しても、RTPパケットヘッダーの内容に関して特別な要件は発生しません。その他のRTPパケットヘッダーフィールドは次のように定義されています。
o V - As per [RFC3550]
o V-[RFC3550]による
o P - As per [RFC3550]
o P-[RFC3550]による
o X - As per [RFC3550]
o X-[RFC3550]による
o CC - As per [RFC3550]
o CC-[RFC3550]による
o M - As per [RFC3550] and [RFC3551] Section 4.1 o PT - A dynamic payload type; MUST be used [RFC3551]
o M-[RFC3550]および[RFC3551]セクション4.1に従います。o PT-動的ペイロードタイプ。使用する必要があります[RFC3551]
o SN (sequence number) - As per [RFC3550]
o SN（シーケンス番号）-[RFC3550]による
o Timestamp - As per [RFC3550]. The RTP timestamp reflects the instant at which the first audio sample in the packet was sampled, that is, the oldest information in the packet.
o タイムスタンプ-[RFC3550]による。 RTPタイムスタンプは、パケット内の最初のオーディオサンプルがサンプリングされた瞬間、つまりパケット内の最も古い情報を反映しています。
Header field abbreviations are defined as follows.
ヘッダーフィールドの省略形は次のように定義されています。
o V - Version Number
o V-バージョン番号
o P - Padding
o P-パディング
o X - Extensions
o X-拡張
o CC - Count of contributing sources
o CC-提供元の数
o M - Marker
o M-マーカー
o PT - Payload Type
o PT-ペイロードタイプ
o PS - Payload Structure
o PS-ペイロード構造
The RTP payload data for Standard apt-X and Enhanced apt-X MUST be structured as follows.
標準apt-Xおよび拡張apt-XのRTPペイロードデータは、次のように構成する必要があります。
Standard apt-X and Enhanced apt-X coded samples are packed contiguously into payload octets in "network byte order", also known as big-endian order, and starting with the most significant bit. Coded samples are packed into the packet in time sequence, beginning with the oldest coded sample. An integer number of coded samples MUST be within the same packet.
標準のapt-Xおよび拡張apt-Xコード化サンプルは、ビッグエンディアン順とも呼ばれる「ネットワークバイト順」でペイロードオクテットに連続してパックされ、最上位ビットから始まります。コード化されたサンプルは、最も古いコード化されたサンプルから始めて、時間順にパケットにパックされます。コード化されたサンプルの整数は、同じパケット内になければなりません。
When multiple channels of Standard apt-X and Enhanced apt-X coded audio, such as in a stereo program, are multiplexed into a single RTP stream, the coded samples from each channel, at a single sampling instant, are interleaved into a coded sample block according to the following standard audio channel ordering [RFC3551]. Coded sample blocks are then packed into the packet in time sequence beginning with the oldest coded sample block.
ステレオプログラムなどで、標準apt-Xおよび拡張apt-Xコード化オーディオの複数のチャネルが単一のRTPストリームに多重化されている場合、各チャネルからのコード化サンプルは、単一のサンプリングの瞬間に、コード化サンプルにインターリーブされます。次の標準オーディオチャネルの順序[RFC3551]に従ってブロックします。次に、コード化されたサンプルブロックは、最も古いコード化されたサンプルブロックから時間順にパケットにパックされます。
l left r right c center S surround F front R rear
l左r右cセンターSサラウンドFフロントRリア
channels description channel
1 2 3 4 5 6
___________________________________________________
2 stereo l r
3 l r c
4 l c r S
5 Fl Fr Fc Sl Sr
6 l lc c r rc S
For the two-channel encoding example, the sample sequence is (left channel, first sample), (right channel, first sample), (left channel, second sample), (right channel, second sample). Coded samples for all channels, belonging to a single coded sampling instant, MUST be contained in the same packet. All channels in the same RTP stream MUST be sampled at the same frequency.
2チャネルエンコーディングの例の場合、サンプルシーケンスは（左チャネル、最初のサンプル）、（右チャネル、最初のサンプル）、（左チャネル、2番目のサンプル）、（右チャネル、2番目のサンプル）です。単一のコード化されたサンプリングインスタントに属するすべてのチャネルのコード化されたサンプルは、同じパケットに含まれている必要があります。同じRTPストリーム内のすべてのチャネルは、同じ周波数でサンプリングする必要があります。
The default packetization interval MUST have a duration of 4 milliseconds. When an integer number of coded samples per channel cannot be contained within this 4-millisecond interval, the default packet interval MUST be rounded down to the nearest packet interval that can contain a complete integer set of coded samples. For example, when encoding audio with either Standard apt-X or Enhanced apt-X, sampled at 11025 Hz, 22050 Hz, or 44100 Hz, the packetization interval MUST be rounded down to 3.99 milliseconds.
デフォルトのパケット化間隔は、4ミリ秒の持続時間を持つ必要があります。チャネルあたりの整数のコード化サンプルをこの4ミリ秒の間隔に含めることができない場合、デフォルトのパケット間隔は、コード化サンプルの完全な整数セットを含むことができる最も近いパケット間隔に切り捨てる必要があります。たとえば、11025 Hz、22050 Hz、または44100 Hzでサンプリングされた標準apt-Xまたは拡張apt-Xでオーディオをエンコードする場合、パケット化間隔は3.99ミリ秒に切り捨てられる必要があります。
The packetization interval sets limits on the end-to-end delay; shorter packets minimize the audio delay through a system at the expense of increased bandwidth, while longer packets introduce less header overhead but increase delay and make packet loss more noticeable. A default packet interval of 4 milliseconds maintains an acceptable ratio of payload to header bytes and minimizes the end-to-end delay to allow viable interactive applications based on apt-X. All implementations MUST support this default packetization interval.
パケット化間隔は、エンドツーエンドの遅延に制限を設定します。パケットが短いと、帯域幅の増加を犠牲にしてシステム全体のオーディオ遅延が最小限に抑えられますが、パケットが長いと、ヘッダーのオーバーヘッドは少なくなりますが、遅延が増加し、パケットの損失が顕著になります。デフォルトのパケット間隔は4ミリ秒で、ペイロードとヘッダーバイトの比率を維持し、エンドツーエンドの遅延を最小限に抑えて、apt-Xに基づく実行可能な対話型アプリケーションを可能にします。すべての実装は、このデフォルトのパケット化間隔をサポートする必要があります。
An application implementing this payload format MUST understand all the payload parameters that are defined in this specification. Any mapping of these parameters to a signaling protocol MUST support all parameters. Implementations can always decide whether they are capable of communicating based on the entities defined in this specification.
このペイロード形式を実装するアプリケーションは、この仕様で定義されているすべてのペイロードパラメータを理解する必要があります。これらのパラメータのシグナリングプロトコルへのマッピングは、すべてのパラメータをサポートする必要があります。実装は常に、この仕様で定義されているエンティティに基づいて、通信が可能かどうかを判断できます。
As an example payload format, consider the transmission of an arbitrary 5.1 audio signal consisting of six channels of 24-bit PCM data, sampled at a rate of 48 kHz and packetized on an RTP packet interval of 4 milliseconds. The total bit rate before audio coding is 6 * 24 * 48000 = 6.912 Mbit/s. Applying Enhanced apt-X coding with a coded sample size of 24 bits results in a transmitted coded bit rate of 1/4 of the uncoded bit rate, i.e., 1.728 Mbit/s. On packet intervals of 4 milliseconds, packets contain 864 bytes of encoded data that contain 48 Enhanced apt-X coded samples per channel.
ペイロード形式の例として、48ビットのレートでサンプリングされ、4ミリ秒のRTPパケット間隔でパケット化された、24ビットPCMデータの6チャネルで構成される任意の5.1オーディオ信号の送信を考えます。オーディオコーディング前の総ビットレートは6 * 24 * 48000 = 6.912 Mbit / sです。 24ビットのコード化サンプルサイズで拡張apt-Xコーディングを適用すると、送信されるコード化ビットレートは非コード化ビットレートの1/4、つまり1.728 Mbit / sになります。 4ミリ秒のパケット間隔では、パケットには864バイトのエンコードされたデータが含まれ、チャネルごとに48の拡張apt-Xコードサンプルが含まれます。
For the example format, the diagram below shows how coded samples from each channel are packed into a sample block and how sample blocks 1, 2, and 48 are subsequently packed into the RTP packet.
以下の図は、フォーマット例について、各チャネルからのコード化されたサンプルがサンプルブロックにパックされる方法と、サンプルブロック1、2、および48がRTPパケットにパックされる方法を示しています。
C: Channel index: Left (l) = 1, left center (lc) = 2, center (c) = 3, right (r) = 4, right center (rc) = 5, and surround (S) = 6.
C：チャネルインデックス：左（l）= 1、左中央（lc）= 2、中央（c）= 3、右（r）= 4、右中央（rc）= 5、サラウンド（S）= 6。
T: Sample Block time index: The first sample block is 1; the final sample is 48.
T：サンプルブロック時間インデックス：最初のサンプルブロックは1です。最終サンプルは48です。
S(C)(T): The Tth sample from channel C.
S（C）（T）：チャネルCからのT番目のサンプル。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(1)(1) | S(2)(1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(2)(1) | S(3)(1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(3)(1) | S(4)(1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(5)(1) | S(6)(1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(6)(1) | S(1)(2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(2)(2) | S(3)(2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(4)(2) | S(5)(2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(5)(2) | S(6)(2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(6)(2) | S(1)(3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(6)(47) | S(1)(48) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(1)(48) | S(2)(48) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(3)(48) | S(4)(48) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(4)(48) | S(5)(48) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(5)(48) | S(6)(48) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For the example format, the diagram below indicates the order that coded bytes are packed into the packet payload in terms of sample byte significance. The following abbreviations are used.
例のフォーマットの場合、以下の図は、サンプルのバイトの重要度の観点から、コード化されたバイトがパケットペイロードにパックされる順序を示しています。以下の略語を使用しています。
MSB: Most Significant Byte of a 24-bit coded sample
MSB：24ビットのコード化されたサンプルの最上位バイト
MB: Middle Byte of a 24-bit coded sample
MB：24ビットのコード化されたサンプルの中間バイト
LSB: Least Significant Byte of a 24-bit coded sample
LSB：24ビットのコード化サンプルの最下位バイト
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSB | MB | LSB | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This RTP payload format is identified using the media type audio/aptx, which is registered in accordance with RFC 4855 [RFC4855] and using the template of RFC 6838 [RFC6838].
このRTPペイロード形式は、RFC 4855 [RFC4855]に従って登録されているメディアタイプaudio / aptxと、RFC 6838 [RFC6838]のテンプレートを使用して識別されます。
Type name: audio
タイプ名：オーディオ
Subtype name: aptx
サブタイプ名：aptx
Required parameters:
必須パラメーター：
rate: RTP timestamp clock rate, which is equal to the sampling rate in Hz. RECOMMENDED values for rate are 8000, 11025, 16000, 22050, 24000, 32000, 44100, and 48000 samples per second. Other values are permissible.
rate：RTPタイムスタンプクロックレート。Hz単位のサンプリングレートと同じです。レートの推奨値は、8000、11025、16000、22050、24000、32000、44100、および48000サンプル/秒です。他の値は許容されます。
channels: The number of logical audio channels that are present in the audio stream.
チャネル：オーディオストリームに存在する論理オーディオチャネルの数。
variant: The variant of apt-X (i.e., Standard or Enhanced) that is being used. The following variants can be signaled:
バリアント：使用されているapt-Xのバリアント（標準または拡張）。次のバリアントを通知できます。
variant=standard variant=enhanced
バリアント=標準バリアント=拡張
bitresolution: The number of bits used by the algorithm to encode four PCM samples. This value MAY only be set to 16 for Standard apt-X and 16 or 24 for Enhanced apt-X.
ビット解像度：4つのPCMサンプルをエンコードするためにアルゴリズムが使用するビット数。この値は、標準apt-Xでは16に、拡張apt-Xでは16または24にのみ設定できます。
Optional parameters:
オプションのパラメーター：
ptime: The recommended length of time (in milliseconds) represented by the media in a packet. Defaults to 4 milliseconds. See Section 6 of [RFC4566].
ptime：パケット内のメディアによって表される推奨時間（ミリ秒単位）。デフォルトは4ミリ秒です。 [RFC4566]のセクション6をご覧ください。
maxptime: The maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. See Section 6 of [RFC4566].
maxptime：各パケットにカプセル化できるメディアの最大量。ミリ秒単位の時間として表されます。 [RFC4566]のセクション6をご覧ください。
stereo-channel-pairs: Defines audio channels that are stereo paired in the stream. See Section 3. Each pair of audio channels is defined as two comma-separated values that correspond to channel numbers in the range 1..channels. Each stereo channel pair is preceded by a '{' and followed by a '}'. Pairs of audio channels are separated by a comma. A channel MUST NOT be paired with more than one other channel. The absence of this parameter signals that each channel has been independently encoded.
stereo-channel-pairs：ストリームでステレオペアになっているオーディオチャネルを定義します。セクション3を参照してください。オーディオチャネルの各ペアは、範囲1..channelsのチャネル番号に対応する2つのコンマ区切り値として定義されます。各ステレオチャネルペアの前には「{」が続き、その後に「}」が続きます。オーディオチャネルのペアはカンマで区切られます。チャネルは、他の複数のチャネルとペアリングしてはなりません。このパラメータがないことは、各チャネルが個別にエンコードされていることを示しています。
embedded-autosync-channels: Defines channels that carry embedded autosync. Embedded-autosync-channels is defined as a list of comma-separated values that correspond to channel numbers in the range 1..channels. When a channel is stereo paired, embedded autosync is shared across channels in the pair. The first channel as defined in stereo-channel-pairs MUST be specified in the embedded-autosync-channels list.
embedded-autosync-channels：埋め込み自動同期を実行するチャネルを定義します。 embedded-autosync-channelsは、1..channelsの範囲のチャネル番号に対応するコンマ区切り値のリストとして定義されます。チャンネルがステレオペアの場合、埋め込まれた自動同期はペアのチャンネル間で共有されます。ステレオチャネルペアで定義されている最初のチャネルは、embedded-autosync-channelsリストで指定する必要があります。
embedded-aux-channels: Defines channels that carry embedded auxiliary data. Embedded-aux-channels is defined as a list of comma-separated values that correspond to channel numbers in the range 1..channels. When a channel is stereo paired, embedded auxiliary data is shared across channels in the pair. The second channel as defined in stereo-channel-pairs MUST be specified in the embedded-aux-channels list.
embedded-aux-channels：埋め込まれた補助データを運ぶチャネルを定義します。 Embedded-aux-channelsは、範囲1..channelsのチャネル番号に対応するコンマ区切り値のリストとして定義されます。チャンネルがステレオペアの場合、埋め込まれた補助データはペアのチャンネル間で共有されます。ステレオチャネルペアで定義されている2番目のチャネルは、embedded-aux-channelsリストで指定する必要があります。
Encoding considerations: This media type is framed in RTP and contains binary data; see Section 4.8 of [RFC6838].
エンコーディングに関する考慮事項：このメディアタイプはRTPでフレーム化され、バイナリデータを含みます。 [RFC6838]のセクション4.8をご覧ください。
Security considerations: See Section 5 of [RFC4855] and Section 4 of [RFC4856].
セキュリティに関する考慮事項：[RFC4855]のセクション5および[RFC4856]のセクション4を参照してください。
Interoperability considerations: none Published specification: RFC 7310
相互運用性に関する考慮事項：なし公開された仕様：RFC 7310
Applications which use this media type: Audio streaming
このメディアタイプを使用するアプリケーション：オーディオストリーミング
Fragment identifier considerations: None
フラグメント識別子の考慮事項：なし
Additional information: none
追加情報：なし
Person & email address to contact for further information:
John Lindsay <Lindsay@worldcastsystems.com>
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550].
使用制限：このメディアタイプはRTPフレーミングに依存するため、RTP [RFC3550]を介した転送に対してのみ定義されます。
Author/Change controller: IETF Payload Working Group delegated from the IESG.
著者/変更管理者：IESGから委任されたIETFペイロードワーキンググループ。
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC4566] that is commonly used to describe RTP sessions. When SDP is used to describe sessions, the media type mappings are as follows.
メディアタイプの仕様に含まれる情報には、RTPセッションの記述に一般的に使用されるセッション記述プロトコル（SDP）[RFC4566]のフィールドへの特定のマッピングがあります。 SDPを使用してセッションを説明する場合、メディアタイプのマッピングは次のとおりです。
o The type name ("audio") goes in SDP "m=" as the media name.
o タイプ名（ "audio"）は、メディア名としてSDP "m ="に入ります。
o The subtype name ("aptx") goes in SDP "a=rtpmap" as the encoding name.
o サブタイプ名（ "aptx"）は、エンコーディング名としてSDP "a = rtpmap"に入ります。
o The parameter "rate" also goes in "a=rtpmap" as the clock rate.
o パラメータ「rate」は、クロックレートとして「a = rtpmap」にも含まれます。
o The parameter "channels" also goes in "a=rtpmap" as the channel count.
o パラメータ「channels」もチャネル数として「a = rtpmap」に含まれます。
o The parameter "maxptime", when present, MUST be included in the SDP "a=maxptime" attribute.
o パラメータ「maxptime」が存在する場合、SDPの「a = maxptime」属性に含める必要があります。
o The required parameters "variant" and "bitresolution" MUST be included in the SDP "a=fmtp" attribute.
o 必要なパラメーター「バリアント」および「ビット解像度」は、SDPの「a = fmtp」属性に含まれている必要があります。
o The optional parameters "stereo-channel-pairs", "embedded-autosync-channels", and "embedded-aux-channels", when present, MUST be included in the SDP "a=fmtp" attribute.
o オプションのパラメーター「stereo-channel-pairs」、「embedded-autosync-channels」、および「embedded-aux-channels」は、存在する場合、SDPの「a = fmtp」属性に含める必要があります。
o The parameter "ptime", when present, goes in a separate SDP attribute field and is signaled as "a=ptime:<value>", where <value> is the number of milliseconds of audio represented by one RTP packet. See Section 6 of [RFC4566].
o パラメータ「ptime」が存在する場合、別のSDP属性フィールドに入り、「a = ptime：<value>」として通知されます。<value>は、1つのRTPパケットによって表されるオーディオのミリ秒数です。 [RFC4566]のセクション6をご覧ください。
Some example SDP session descriptions utilizing apt-X encodings follow. In these examples, long "a=fmtp" lines are folded to meet the column width constraints of this document.
apt-Xエンコーディングを利用したSDPセッションの説明の例を以下に示します。これらの例では、このドキュメントの列幅の制約を満たすために、長い "a = fmtp"行が折り返されています。
Example 1: A Standard apt-X stream that encodes two independent 44.1-kHz 16-bit PCM channels into a 4-millisecond RTP packet.
例1：2つの独立した44.1-kHz 16ビットPCMチャネルを4ミリ秒のRTPパケットにエンコードする標準のapt-Xストリーム。
m=audio 5004 RTP/AVP 98
a=rtpmap:98 aptx/44100/2
a=fmtp:98 variant=standard; bitresolution=16;
a=ptime:4
Example 2: An Enhanced apt-X stream that encodes two 48-kHz 24-bit stereo channels into a 4-millisecond RTP packet and carries both an embedded autosync and auxiliary data channel.
例2：2つの48 kHz 24ビットステレオチャネルを4ミリ秒のRTPパケットにエンコードし、埋め込まれた自動同期チャネルと補助データチャネルの両方を伝送する拡張apt-Xストリーム。
m=audio 5004 RTP/AVP 98
a=rtpmap:98 aptx/48000/2
a=fmtp:98 variant=enhanced; bitresolution=24;
stereo-channel-pairs={1,2}; embedded-autosync-channels=1;
embedded-aux-channels=2
a=ptime:4
Example 3: An Enhanced apt-X stream that encodes six 44.1-kHz 24-bit channels into a 6-millisecond RTP packet. Channels 1,2 and 3,4 are stereo pairs. Both stereo pairs carry both an embedded autosync and auxiliary data channel.
例3：6つの44.1 kHz 24ビットチャネルを6ミリ秒のRTPパケットにエンコードする拡張apt-Xストリーム。チャンネル1、2、3、4はステレオペアです。両方のステレオペアは、埋め込まれた自動同期と補助データチャネルの両方を伝送します。
m=audio 5004 RTP/AVP 98
a=rtpmap:98 aptx/44100/6
a=fmtp:98 variant=enhanced; bitresolution=24;
stereo-channel-pairs={1,2},{3,4}; embedded-autosync-channels=1,3;
embedded-aux-channels=2,4
a=ptime:6
The only negotiable parameter is the delivery method. All other parameters are declarative. The offer, as described in [RFC3264], may contain a large number of delivery methods per single fmtp attribute. The answerer MUST remove every delivery method and configuration URI that is not supported. Apart from this exceptional case, all parameters MUST NOT be altered on answer.
唯一の交渉可能なパラメーターは配信方法です。他のすべてのパラメーターは宣言型です。 [RFC3264]で説明されているように、オファーには単一のfmtp属性ごとに多数の配信方法が含まれる場合があります。回答者は、サポートされていないすべての配信方法と構成URIを削除する必要があります。この例外的なケースを除いて、すべてのパラメーターは回答時に変更してはなりません。
One media type (audio/aptx) has been registered in the "Media Types" registry. See Section 6.1.
「Media Types」レジストリに1つのメディアタイプ（audio / aptx）が登録されています。セクション6.1を参照してください。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and any appropriate RTP profile (for example, [RFC3551]). This implies that confidentiality of the media streams is achieved by encryption. Because the audio coding used with this payload format is applied end to end, encryption may be performed after audio coding so there is no conflict between the two operations. A potential denial-of-service threat exists for audio coding techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream that are complex to decode and cause the receiver to be overloaded. However, the Standard apt-X and Enhanced apt-X audio coding algorithms do not exhibit any significant non-uniformity. As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP [RFC3376] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it. [RFC6562] has highlighted potential security vulnerabilities of Variable Bit Rate (VBR) codecs using Secure RTP transmission methods. As the Standard apt-X and Enhanced apt-X codecs are Constant Bit Rate (CBR) codecs, this security vulnerability is therefore not applicable.
この仕様で定義されたペイロード形式を使用するRTPパケットは、RTP仕様[RFC3550]および適切なRTPプロファイル（[RFC3551]など）で説明されているセキュリティの考慮事項に従います。これは、メディアストリームの機密性が暗号化によって達成されることを意味します。このペイロード形式で使用されるオーディオコーディングはエンドツーエンドで適用されるため、オーディオコーディングの後に暗号化を実行して、2つの操作が競合しないようにすることができます。レシーバー側の計算負荷が不均一なオーディオコーディング技術には、潜在的なサービス拒否の脅威が存在します。攻撃者は、復号化が複雑な病理学的データグラムをストリームに挿入し、レシーバーを過負荷にする可能性があります。ただし、標準apt-Xおよび拡張apt-Xオーディオコーディングアルゴリズムは、大きな不均一性を示しません。他のIPベースのプロトコルと同様に、状況によっては、受信側は、必要以上に多くのパケットを受信しただけで過負荷になる場合があります。ネットワーク層認証は、望ましくないソースからのパケットを破棄するために使用できますが、認証自体の処理コストが高すぎる可能性があります。マルチキャスト環境では、特定のソースのプルーニングがIGMP [RFC3376]の将来のバージョンとマルチキャストルーティングプロトコルに実装され、受信者が到達できるソースを選択できるようになります。 [RFC6562]は、Secure RTP送信方法を使用した可変ビットレート（VBR）コーデックの潜在的なセキュリティの脆弱性を強調しています。標準apt-Xおよび拡張apt-Xコーデックは固定ビットレート（CBR）コーデックであるため、このセキュリティの脆弱性は適用されません。
This specification was facilitated by earlier documents produced by Greg Massey, David Trainer, James Hunter, and Derrick Rea, along with practical tests carried out by Paul McCambridge of APT Ltd.
この仕様は、グレッグマッセイ、デビッドトレーナー、ジェームスハンター、デリックレアによって作成された初期のドキュメントと、APT Ltdのポールマッケンブリッジによって実施された実際のテストによって促進されました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「オファー/アンサーモデルとセッション記述プロトコル（SDP）」、RFC 3264、2002年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小制御のオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[RFC2733] Rosenberg、J。およびH. Schulzrinne、「Generic Forward Error CorrectionのRTPペイロードフォーマット」、RFC 2733、1999年12月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855] Casner、S。、「RTPペイロード形式のメディアタイプ登録」、RFC 4855、2007年2月。
[RFC4856] Casner, S., "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", RFC 4856, February 2007.
[RFC4856] Casner、S。、「オーディオおよびビデオ会議のRTPプロファイルにおけるペイロード形式のメディアタイプ登録」、RFC 4856、2007年2月。
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007.
[RFC5109] Li、A。、編、「Generic Forward Error CorrectionのRTPペイロードフォーマット」、RFC 5109、2007年12月。
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2012.
[RFC6562]パーキンス、C。およびJM。 Valin、「Secure RTPでの可変ビットレートオーディオの使用に関するガイドライン」、RFC 6562、2012年3月。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、2013年1月。
Authors' Addresses
著者のアドレス
John Lindsay APT Ltd 729 Springfield Road Belfast Northern Ireland BT12 7FP UK
John Lindsay APT Ltd 729 Springfield Road Belfast北アイルランドBT12 7FP UK
Phone: +44 2890 677200
EMail: Lindsay@worldcastsystems.com
Hartmut Foerster APT Ltd 729 Springfield Road Belfast Northern Ireland BT12 7FP UK
Hartmut Foerster APT Ltd 729 Springfield Road Belfast北アイルランドBT12 7FP UK
Phone: +44 2890 677200
EMail: Foerster@worldcastsystems.com