RFC2833中文文档.docx

资源描述

RFC2833中文文档.docx

《RFC2833中文文档.docx》由会员分享，可在线阅读，更多相关《RFC2833中文文档.docx（32页珍藏版）》请在冰豆网上搜索。

RFC2833中文文档.docx

RFC2833中文文档

组织：

中国互动出版网（http:

//www.china-

RFC文档中文翻译计划（http:

//www.china-

E-mail：

********************

译者：

吴晶（********************）李超（****************）

译文发布时间：

2001-6-27

版权：

本中文翻译文档版权归中国互动出版网所有。

可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。

NetworkWorkingGroupH.Schulzrinne

RequestforComments:

2833ColumbiaUniversity

Category:

StandardsTrackS.Petrack

MetaTel

May2000

用于DTMF数字信号、电话音和电话信号的RTP负载格式

本备忘录的状态

本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建

议以得到改进。

请参考最新版的“Internet正式协议标准”（STD1）来获得本协议的标准化

程度和状态。

本备忘录的发布不受任何限制。

摘要

本备忘录描述了在RTP数据包中传送双音多频（DTMF）信号、其它电话信号音和电话事

件的方法。

1介绍2

1．1术语3

2．语音与事件3

3．用于命名电话事件的RTP负载格式4

3．1介绍4

3．2同时产生音频和事件4

3．3事件类型4

3．4RTP头用法5

3．5负载格式5

3．6发送事件数据包6

3．7可靠性6

3．8举例7

3．9接收端使用SDP性能的表述7

3．10DTMF事件8

3．11数据调制解调器和传真事件8

3．12线路事件10

3．13扩展线路事件12

3．14信息通路事件12

4．用于电话话音的RTP负载格式13

4．1介绍13

4．2公共电话话音信号实例14

4．3RTP头字段的使用15

4．4负载格式15

4．5可靠性16

5．信号音合并和命名事件16

6．MIME注册16

6．1audio/telephone-event16

6．2audio/tone17

7．安全考虑18

8.IANA考虑18

鸣谢18

作者地址18

参考书目19

版权说明20

致谢21

1介绍

本备忘录定义了两种负载格式，一种用于在RTP包中传送双音多频数字信号、其它线

路和干线信号（第三节），第二种则用于RTP包中普通多频电话音的传输（第四节）。

由于

低速率声音编解码器无法保证能完全正确地自动识别重现的电话音信号，所以需要单独定义

RTP负载格式。

定义独立负载格式也使得在保持低比特率的同时系统能有更高的冗余性。

这里描述的负载格式将至少可应用于以下三种场合的DTMF处理：

网关、终端系统和

“RTP干线”。

在第一种应用中，因特网电话网关检测引入网路的DTMF并发送描述该内容

的RTP负载而不是通常的音频数据包。

网关一般必须得有数字信号处理器和相应的算法，

因为它经常要检测DTMF，例如在双阶段拨号中。

由网关检测话音可减轻Internet终端系统

的工作负担，同时也避免诸如G.723.1等低比特率编解码器误解DTMF音。

第二，如“因特

网电话”等因特网终端系统能够仿真DTMF的功能性，而不考虑自身产生精确的电话音对，

也不影响接收端的语音识别负担能力。

在“RTP干线”应用中，RTP常用于取代两点间通常的电路开关干线，这在仍然以电

路开关为主的电话网络中犹为重要。

这时，RTP干线端点将对音频通道中信号进行适当的编

码，如按G.723.1或G.729。

然而，这种编码过程破坏了通过最低位携带的带内信令信息，

也会干扰MF数字语音等段内信令话音。

另外，如ANSam音中的相位反转等语音属性不支

持语音编码。

因而，网关需要从比特流中除去这些带内信令信息。

它可以以带外方式通过待

定义的信令传输机制传送，也可以使用本备忘录描述的机制进行传送。

（如果两个干线端点

在同一个媒体网关控制器可控范围内，媒体网关控制器也可处理该信令。

）带内传送可以简

化音频数据包和电话音或信号信息之间的时间同步。

这在具有持续性和计时的事件中尤其重

要，如DTMF信号传送。

1．1术语

本文中的关键字“必须”，“必须不”，“要求的”，“应该”，“不应该”，“会”，“不会”，“建

议”，“或许”，“可选的”在RFC2119中解释。

2．语音与事件

网关处理DTMF数字信号和事件的方式有两种。

第一种，它可以简单测量声音波段信

号的频率成分并将这些信息传送到RTP接收端（第四节）。

在这种模式下，网关仅从语音信

号中简单辨别话音，无需鉴别话音的含义。

用于PSTN且人可感知的所有话音信号都是一系

列简单正弦波的组合，经过叠加或调制。

（至少有一种话音使用了周期性相位反转，如在话

音线路上指示数据传输的ANSamtone[3]。

）

第二种，网关可以识别电话音并将它们译为名称，如振铃或忙音。

接收端即产生电话音

信号或其它相应的信号描述。

通常，由于信号识别依赖开/关模式或个别电话音序列，这种

识别会花几秒钟。

另一方面，网关可以访问产生电话音的真实信令信息，因此能够立刻生成

RTP包，无需绕开声音信号。

在电话网络中，电话音产生于不同的地方，取决于开关技术和音调特性。

这就决定了当

一个人给国外打电话时所听见的是她所熟悉的本地音调还是被叫国使用的音调。

对于模拟线路而言，拨号音通常是通过本地开关产生的。

ISDN终端可以在本地产生拨

号音，然后发送包含所拨数字的Q.931SETUP消息。

如果终端只发送SETUP消息而没有任

何被叫方号码，开关收集由终端KEYPAD提供的数字，并由B通道发出拨号音。

终端可在B

通道使用音频信号，或是用Q.931消息触发本地产生拨号音。

振铃声（也称为回响音）由被呼叫方的本地开关产生，被呼叫方电话一响就打开一个

单向声音通道。

（这减少了修剪被呼叫当事人应答后响应的机会。

它也允许预应答通告或带

内呼叫过程指示在振铃前/中到达呼叫者。

）拥塞音及特殊信息音可由通路中任何开关产生，

也可由呼叫者开关根据接收到的ISUP消息产生。

在模拟设备或ISDN终端中，忙音由呼叫

者开关产生，并由相应ISUP消息触发。

通过RTP发送信号事件的网关在一次单独RTP会话中会发送命名信号（第三节）以

及话音表述（第四节），使用3.7节中定义的冗余机制插入这两项表述。

因为它允许接收端

自由选择合适的表述，所以这种方法也是一种比较通用的好办法。

如果网关不能给出电话音表述，除命名信号外，它还应该在常规RTP音频数据包中（如

在PCMU负载中）发送音频音。

3．用于命名电话事件的RTP负载格式

3．1介绍

下面描述的命名电话事件的负载格式适合于网关和终端到终端的场合。

在网关中，将语

音包网络连接到PSTN网络上的Internet电话网关重新生成DTMF音或其它电话事件并将它

们插入到PSTN。

由于识别DTMF数字等操作会占用几十毫秒，则最开始的数毫秒内数字将

作为常规音频数据包到达。

因此，为了避免在接收端产生虚假数字信号，必须注意音频样本

及事件间的时间及功率（音量）队列。

DTMF数字信号及命名电话事件作为音频流的一部分进行发送，且为了简化网关中音频

波形的产生必须使用以相同序号和时间戳为基础的常规音频信道。

默认的时钟频率为8000

赫兹，但时钟频率可在动态分配负载类型时重定义。

这里描述的负载格式与VoiceoverFrameRelayImplementationAgreement[4]所提出

的方式相比，即使在连续数据包丢失的情况下也可达到更高的冗余性。

若终端系统直接与Internet相连且不必再产生电话音信号，那么时间队列和功率标准就

不相关了。

这些系统依赖PSTN网关或Internet端系统产生DTMF事件，并且不执行自己的

音频波形分析。

例如Internet交互式声音应答系统（IVR）就是这样一种系统。

在某些环境中，音频流和DTMF数字信号或其它事件间的时间对齐并不重要，如果象

前面提到的IVR一样，数据采用单播方式发送，最好采用比RTP更可靠的控制协议。

这时

就不能再使用本文定义的负载格式。

3．2同时产生音频和事件

使用事件作为音频流的冗余编码，信号源可以同时发送事件和已编码的音频数据包，或

者它会在事件音活动时阻塞发出的音频，只发送作为主编码和冗余编码的命名事件。

值得注意的是，一种已编码音的周期在时间上会与用其它方式编码的音产生周期交叠。

这在该信号音开始时就会发生，因此对远程终端重现信号音译码时必须避免此类错误。

支持

这种负载格式的实现应能处理这种交叠。

由于音频中会包含音频压缩算法产生的假话音，建

议网关只处理已译码的音。

不过，一般而言这些额外音通常并不会干扰远端的识别。

3．3事件类型

这种负载格式用于5种不同的信号格式：

DTMF音（3。

10小节）

传真相关音（3。

11小节）

标准用户线路音（3。

12小节）

特定国家用户线路音（3。

13小节）

干线事件（3。

14小节）

本文档兼容的实现必须支持表1中除“Flash”外的所有事件。

如果使用其它方式，如

带外机制实现信令线路条件，就不必实现其它事件。

在某些情况下，具体实现时有些事件可以简单忽略掉，例如传真音，在特定环境下它

可能没什么意义。

3.9小节指出了实现中如何使用SDP描述的"fmtp"参数以表示它无法理解

某一事件或一定范围内的事件。

依靠可用的用户接口，实现可以翻译表5中的所有电话音，更适合的方式是使用在并发

“tone”负载或其它RTP音频负载所传送的电话音。

作为可选项，它可以提供文本表述。

注意到由于MF主干也携带了大部分"line"信令，仿真电话的终端系统只需支持3.10小

节和3.12小节中提到的事件，而接收主干信令的系统需要实现3.10、3.11、3.12和3.14小

节提到的事件。

不支持传真和调制解调器功能的系统不用支持3.11描述的和传真相关的事

件。

RTP的负载格式定为“telephone-event”，MIME类型为“audio/telephone-event”。

默认的时间戳频率为8000赫兹，当然也可以定义其它频率。

为了同现有的实现一致，这种

负载格式没有静态负载类型号，而使用动态带外方式建立的RTP负载类型号。

3．4RTP头用法

时间戳：

RTP时间戳反映了当前数据包的测量点。

3.5小节描述的事件持续时间就从该

点算起。

接收方根据所有数据包的时间戳计算RTCP接收报告中需要的波动。

注意：

波动值

应主要用来比较两个用户或是两个时间段内的接收质量，并非是绝对的度量。

标志位：

RTP标志位指示一个新事件的开始。

3．5负载格式

图一所示为负载格式。

0123

01234567890123456789012345678901

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图一：

命名事件的负载格式

事件：

事件按照3.10到3.14小节所示编码。

volume：

音量，对于DTMF数字信号及其它可表示为音频的事件，本字段描述音频

的功率级，以dBm0标记。

功率级范围从0到-63dBm0。

有效的DTMF范围是从0到-36dBm0

（必须做到）；低于-55dBm0则必须丢弃（TR-TSY-000181,ITU-TQ.24A）。

因而，值越大表

明音量越小。

这里的值只为DTMF数字定义。

对于其它事件，发送端设置为零且接收端将

忽略该值。

duration：

数字信号的宽度以时间戳单元表示。

这样，事件从RTP时间戳表示的瞬间

开始，并一直持续到该参数表示的长度。

事件可以已经结束也可以没有结束。

以8000赫兹

取样来说，本字段最长可以表示8秒。

E：

结束位若设置为1表明数据包中含有事件的结束。

因此上述的duration参数即测定

了事件的完整宽度。

发送方重发电话音的最后一个数据包才设置结束位，而不是第一次传送时就发送。

这

就避免了不断等待测定话音是否真正结束。

接收端的实现可以使用不同算法产生话音，下面

列出了两种。

第一种，接收端简单地在音频播放缓冲区中时间戳描述的位置上放置给定宽度

的话音。

接收到扩充同一音频的附加数据时，播放缓冲区中的波形相应扩展。

（但要特别注

意，播放缓冲区中的音频可能要经过混合，例如叠加，而不是简单拷贝。

）所以，如果一个

数据包话音持续时间长于丢失的间隔时间且播放延迟很短，则会出现话音间隙。

另外一种方

法，接收端可以开始一段音频并一直播放至接收到有结束位的数据包，下一个话音可通过不

同的时间戳值或给定的流失周期区分。

此举提高了数据丢失时的鲁棒性，但如果事件的最后

数据包在所有重发中都丢失了，则会造成话音扩展。

为了避免话音“粘滞”，必须限制扩展

音频的时间周期。

无论使用哪种算法，话音不应该扩展到三个以上数据包间隔时间。

轻微的

扩展和短暂的暂停一般都是无害的。

R：

本字段为以后使用而保留。

发送方必须将它设为0，接收端则应忽略它。

3．6发送事件数据包

音源一识别到事件就应开始发送事件数据包，之后按每50毫秒或根据会话中使用的音

频编解码器的时间间隔连续发送。

（由于时间戳中包含了时间信息，发送方无须为了保持精

确的inter-event次数而维持精确的事件数据包间隔）

Q.24[5]，表A-1，指出了所有测量管理使用40毫秒的最小信号宽度，和不低于93毫

秒的信令速率（话音及中止）。

若一个事件延续了一个周期以上，信号源产生事件将发送一个新的事件数据包，其RTP

时间戳值为事件开始时刻加上事件已经持续的时间。

（RTP序列号按每个数据包依次增一。

）

如果最后间隔中没有新事件发生，那么事件应重发3次或直到下个事件被识别。

这确保了即

使最后一个数据包丢失，也能正确识别事件的宽度。

为了避免接收端等待事件的完成，DTMF数字信号及事件按递增形式发送。

由于一些音

频长达2秒，将造成实际延迟。

发送方并不知道事件长度是否重要，因而需要立即且递增式

地传送。

如果接收端应用不在乎事件持续时间，那么这样的递增传输机制就避免了延迟。

而

有些应用则同时要关心延迟和事件持续时间，如PSTN网关等。

3．7可靠性

在一个事件中，RTP事件负载格式提供了事件的递增更新。

错误恢复性取决于接收端的

播放延迟。

例如，如果播放延迟为120毫秒，包间隙为50毫秒，一行丢失两个数据包不会

造成接收端产生音频间隙。

RFC2198[6]中描述的音频冗余机制可以用于恢复数据包中丢失的事件。

有效的数据速

率是每50毫秒r个64位（32位作为冗余头，32位作为电话事件负载）或每秒r个1280位，

其中r是每个数据包中携带的冗余事件数。

r值可在具体实现时确定，建议可以使用5。

冗余设计中时间戳的偏移量有14位，在采样频率8000Hz下，它可以携带2.048秒的电

话事件。

网关能利用其中包含的前一事件的开始时间精确地重建音频序列。

该机制可更具弹

性地处理2.048秒或r个信号的连续数据包丢失。

对于前一数字信号只表示其平均响度。

解码器将事件负载视为当前音频帧的高压缩版。

在那种模式下，事件中每个RTP数据

包都会包含当前音频编解码器对这些数字信号的翻译（在G.723.1或G.729提到）以及3.5

小节提到的表述，加上更早的事件。

这种方法使得那些不理解该格式的哑网关也能运行。

参见第1节。

3．8举例

一个典型的RTP数据包，用户正在拨DTMF序列的最后数字“911”。

第一个数字信号

200毫秒长（1600个时间戳单元）且在0时间开始，第二个数字信号持续了250毫秒（2000

个时间戳单元）且在800毫秒时开始（6400个时间戳单元），第三个数字信号在1.4秒处（11200

个时间戳单元）被压缩且数据包显示出是在1.45秒时（11600个时间戳单元）发出。

整个帧

宽度为50毫秒。

为能看清各部分，以下整体上忽视字节对齐。

假定时间戳和顺序号在第一

个数字开始设为0。

冗余机制和电话事件负载的动态负载类型分别为96和97。

3．9接收端使用SDP性能的表述

0123

01234567890123456789012345678901

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P|X|CC|M|PT|sequencenumber|

|2|0|0|0|0|96|28|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|timestamp|

|11200|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|synchronizationsource（SSRC）identifier|

|0x5234a8|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|1|97|11200|4|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|1|97|11200-6400=4800|4|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|F|BlockPT|

|0|97|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|9|10|7|1600|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|1|10|10|2000|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|1|00|20|400|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图2：

拨“911”之后的RTP数据包示例

接收端会指出它可以处理哪个命名事件，例如，使用SDP协议（RFC2327[7]）。

负载

格式使用了下列fmtp格式以列出可接受的事件值：

a=fmtp:

这个值列表由逗号分开成员，它可以是一个十进制数也可以是由连字符（波折号）隔开

的两个十进制数，且第二个数字要大于第一个。

数字或连字符间不允许空格。

列表无需排序。

例如，如果负载格式使用负载类型号为100，可处理DTMF音（事件0到15）和拨号

音和铃声，那它在SDP消息中可如下表述：

a=fmtp:

1000-15,66,70

因为所有实现必须能接收事件0～15，所以在a=fmtp行上这些事件是可列可不列。

相应的MIME参数是“events”，所以下面的样本媒体类型定义要和上面SDP的例子相

对应：

audio/telephone-event;events="0-11,66,67";rate="8000"

3．10DTMF事件

表1总结了电话事件负载格式中与DTMF有关的命名事件。

Eventencoding（decimal）

_________________________

0--90--9

*10

#11

A--D12--15

Flash16

表1：

DTMF命名事件

3．11数据调制解调器和传真事件

表3.11总结了出现在为传真机或调制解调器服务的用户线路中的事件及音频。

音频

部分如下描述，其详细说明在表7中介绍。

ANS：

这种频率为2100+/-15Hz的话音用于禁止数据传输中[8,9]的回声抑止。

对于

传真机，建议T.30[9]中引用了这种音频，称为终端标识（CED）应答。

/ANS：

本信号与ANS相同，但每450+/-25ms会反相。

它可以同时禁止回声消除和

回声抑止。

在ITU的建议V.25[8]中，本信号表示为ANS（带上划线）。

ANSam：

改进的应答话音（ANSam）[3]是频率为2100+/-1Hz的不带反相的正弦波信

号，调幅正弦波为15+/-0.1Hz。

如果不需要禁止网络回声消除效，则该音可由调制解调器

发送。

/ANSam：

改进的带相位反转的应答音（ANSam）[3]是频率为2100+/-1Hz，反相间隔

为450+/-

展开阅读全文