摘要
    本备忘录描述了在RTP数据包中传送双音多频(DTMF)信号、其它电话信号音和电话事件的方法。
目录
1 介绍 2
1．1术语 3
2．语音与事件 3
3．用于命名电话事件的RTP负载格式 4
3．1介绍 4
3．2同时产生音频和事件 4
3．3事件类型 4
3．4 RTP头用法 5
3．5负载格式 5
3．6发送事件数据包 6
3．7可靠性 6
3．8举例 7
3．9接收端使用SDP性能的表述 7
3．10 DTMF事件 8
3．11数据调制解调器和传真事件 8
3．12线路事件 10
3．13扩展线路事件 12
3．14信息通路事件 12
4．用于电话话音的RTP负载格式 13
4．1介绍 13
4．2公共电话话音信号实例 14
4．3 RTP头字段的使用 15
4．4 负载格式 15
4．5可靠性 16
5．信号音合并和命名事件 16
6．MIME注册 16
6．1 audio/telephone-event 16
6．2 audio/tone 17
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术语
   本文中的关键字“必须”，“必须不”，“要求的”，“应该”，“不应该”，“会”，“不会”，“建议”，“或许”，“可选的”在 RFC 2119 中解释。
2．语音与事件
网关处理DTMF数字信号和事件的方式有两种。第一种，它可以简单测量声音波段信号的频率成分并将这些信息传送到RTP接收端（第四节）。在这种模式下，网关仅从语音信号中简单辨别话音，无需鉴别话音的含义。用于PSTN且人可感知的所有话音信号都是一系列简单正弦波的组合，经过叠加或调制。（至少有一种话音使用了周期性相位反转，如在话音线路上指示数据传输的ANSam tone [3]。）

  第二种，网关可以识别电话音并将它们译为名称，如振铃或忙音。接收端即产生电话音信号或其它相应的信号描述。通常，由于信号识别依赖开/关模式或个别电话音序列，这种识别会花几秒钟。另一方面，网关可以访问产生电话音的真实信令信息，因此能够立刻生成RTP包，无需绕开声音信号。

    在电话网络中，电话音产生于不同的地方，取决于开关技术和音调特性。这就决定了当一个人给国外打电话时所听见的是她所熟悉的本地音调还是被叫国使用的音调。

    对于模拟线路而言，拨号音通常是通过本地开关产生的。ISDN终端可以在本地产生拨号音，然后发送包含所拨数字的Q.931 SETUP消息。如果终端只发送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赫兹，但时钟频率可在动态分配负载类型时重定义。

    这里描述的负载格式与Voice over Frame Relay Implementation Agreement[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．4 RTP头用法
时间戳：RTP时间戳反映了当前数据包的测量点。3.5小节描述的事件持续时间就从该点算起。接收方根据所有数据包的时间戳计算RTCP接收报告中需要的波动。注意：波动值应主要用来比较两个用户或是两个时间段内的接收质量，并非是绝对的度量。
标志位：RTP标志位指示一个新事件的开始。
3．5负载格式
     图一所示为负载格式。
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+
   |     event     |E|R| volume    |          duration        &nbs p;    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+
图一：命名事件的负载格式
事件：事件按照3.10到3.14小节所示编码。
volume：音量，对于DTMF数字信号及其它可表示为音频的事件，本字段描述音频的功率级，以dBm0标记。功率级范围从0 到-63 dBm0。有效的DTMF范围是从0 到-36 dBm0（必须做到）；低于-55 dBm0则必须丢弃（TR-TSY-000181,ITU-T Q.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毫秒，一行丢失两个数据包不会造成接收端产生音频间隙。
RFC 2198 [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。