Internet Engineering Task Force (IETF) J. Lindsay
Request for Comments: 7310 H. Foerster
Category: Standards Track APT Ltd
ISSN: 2070-1721 July 2014
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有效载荷中传输多个相关音频信道的有效载荷格式，以及通过会话描述协议（SDP）建立标准apt-X和增强apt-X连接的方法。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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有效负载格式注册媒体类型（音频/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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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）音频通道组成的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不强制执行编码帧结构，编码数据形成连续编码样本流，每个编码样本在解码时能够再生四个PCM样本。标准apt-X算法将来自每个音频通道的四个连续16位PCM样本编码为每个音频通道的单个16位编码样本。增强型apt-X算法对来自每个音频通道的四个连续16位或24位PCM样本进行编码，并分别为每个通道生成一个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
标准apt-X和增强型apt-X编码数据流可选择性地在编码音频数据内携带同步信息和辅助数据信道，而无需额外开销。例如，当IP系统与另一个传输系统级联并且解码器作为一个传输系统时，可以使用这些机制
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.
这两个系统之间的简单桥梁。由于辅助数据信道和同步信息在编码音频数据中携带，没有额外的开销，因此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音频通道组成的1.536 Mbit/s立体声音频流的情况下，通常每32个未编码的左通道采样将一字节辅助数据馈入标准apt-X或增强型apt-X编码器。默认情况下，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>
英国剑桥考利路剑桥CB4 0WZ商业园丘吉尔之家公司总部电话：+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本身不提供任何向编码音频流中添加冗余或差错控制编码的机制。RTP的通用方案，如RFC 5109[RFC5109]和RFC 2733[RFC2733]中所述的前向纠错，可用于向标准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算法对来自每个音频通道的四个连续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 抄送-根据[RFC3550]
o M - As per [RFC3550] and [RFC3551] Section 4.1
o M-根据[RFC3550]和[RFC3551]第4.1节
o PT - A dynamic payload type; MUST be used [RFC3551]
o PT-动态有效载荷类型；必须使用[RFC3551]
o SN (sequence number) - As per [RFC3550]
o 序号（序列号）-根据[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编码样本以“网络字节顺序”（也称为big-endian顺序）连续打包到有效负载八位字节中，并从最高有效位开始。编码样本按时间顺序打包到数据包中，从最早的编码样本开始。同一数据包中必须包含整数个编码样本。
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
左左右c中心S环绕F前右后
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
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.
对于双信道编码示例，样本序列是（左信道，第一样本），（右信道，第一样本），（左信道，第二样本），（右信道，第二样本）。属于单个编码采样瞬间的所有信道的编码样本必须包含在同一数据包中。同一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毫秒间隔内时，必须将默认数据包间隔向下舍入到可以包含完整整数编码样本集的最近数据包间隔。例如，当使用标准apt-X或增强型apt-X（采样频率为11025 Hz、22050 Hz或44100 Hz）对音频进行编码时，打包间隔必须向下舍入到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.
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.translate error, please retry
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的第Tth个样本。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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有效负载格式使用媒体类型audio/aptx标识，该媒体类型根据RFC 4855[RFC4855]注册，并使用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.
速率：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.
比特分辨率：算法用于编码四个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.
立体声通道对：定义流中立体声成对的音频通道。见第3节。每对音频通道定义为两个逗号分隔的值，对应于范围为1..channels的通道号。每个立体声通道对前面都有一个“{”，后面跟着一个“}”。成对的音频通道用逗号分隔。一个频道不得与多个其他频道配对。缺少此参数表示每个通道已独立编码。
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.
嵌入式自动同步通道：定义携带嵌入式自动同步的通道。嵌入式自动同步通道定义为逗号分隔值列表，这些值对应于范围为1..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.
嵌入式辅助通道：定义携带嵌入式辅助数据的通道。嵌入式aux通道定义为逗号分隔值列表，对应于范围为1..channel的通道编号。当一个通道为立体声配对时，嵌入式辅助数据将在该对通道之间共享。立体声声道对中定义的第二个声道必须在嵌入式辅助声道列表中指定。
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>
Person & email address to contact for further information:
John Lindsay <Lindsay@worldcastsystems.com>
Intended usage: 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.
媒体类型规范中携带的信息具有到会话描述协议（SDP）[RFC4566]中的字段的特定映射，该协议通常用于描述RTP会话。使用SDP描述会话时，媒体类型映射如下所示。
o The type name ("audio") goes in SDP "m=" as the media name.
o 类型名称（“音频”）以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”属性中必须包含所需参数“variant”和“bitresolution”。
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 可选参数“立体声通道对”、“嵌入式自动同步通道”和“嵌入式辅助通道”（如果存在）必须包含在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>是一个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：将两个独立的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
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：增强型apt-X流，将两个48 kHz 24位立体声通道编码为4毫秒RTP数据包，并携带嵌入式自动同步和辅助数据通道。
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
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：增强型apt-X流，将六个44.1-kHz 24位信道编码为6毫秒RTP数据包。通道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
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.
一种媒体类型（音频/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]）中讨论的安全注意事项的约束。这意味着媒体流的机密性是通过加密实现的。由于与此有效负载格式一起使用的音频编码是端到端应用的，因此可以在音频编码之后执行加密，因此两个操作之间没有冲突。对于具有非均匀接收端计算负载的音频编码技术，存在潜在的拒绝服务威胁。攻击者可以向流中注入难以解码的病理数据报，并导致接收器过载。然而，标准apt-X和增强apt-X音频编码算法没有表现出任何显著的非均匀性。与任何基于IP的协议一样，在某些情况下，接收机可能仅仅因为接收了太多的数据包而过载，不管是想要的还是不想要的。网络层认证可用于丢弃来自不希望的源的数据包，但认证本身的处理成本可能过高。在多播环境中，可以在IGMP[RFC3376]的未来版本和多播路由协议中实现特定源的修剪，以允许接收机选择允许哪些源到达它。[RFC6562]强调了使用安全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.
本规范由Greg Massey、David Trainer、James Hunter和Derrick Rea编制的早期文件以及APT有限公司的Paul McCambridge进行的实际测试提供了帮助。
[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：实时应用的传输协议”，STD 64，RFC 35502003年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：会话描述协议”，RFC4566，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，“通用前向纠错的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 48552007年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.，Ed.“通用前向纠错的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]Perkins，C.和JM。Valin，“带安全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
约翰·林赛公寓有限公司北爱尔兰贝尔法斯特斯普林菲尔德路729号BT12 7FP英国
Phone: +44 2890 677200
EMail: Lindsay@worldcastsystems.com
Phone: +44 2890 677200
EMail: Lindsay@worldcastsystems.com
Hartmut Foerster APT Ltd 729 Springfield Road Belfast Northern Ireland BT12 7FP UK
Hartmut Foerster公寓有限公司北爱尔兰贝尔法斯特斯普林菲尔德路729号BT12 7FP英国
Phone: +44 2890 677200
EMail: Foerster@worldcastsystems.com
Phone: +44 2890 677200
EMail: Foerster@worldcastsystems.com