“RFC 2833 RTP事件”连续事件和E“结束”少量

Question

为什么E位为0时有dtmf声音，为1时没有声音？ （RTP 数据包以任何方式出现在wireshark 中）

背景：

我可以发送 RFC 2833 dtmf 事件，如 http://www.ietf.org/rfc/rfc2833.txt 当未设置 E 位时，将获得以下行为：

例如，如果按下 7874556332111111145855885#3 键，则所有事件都会发送并显示在像wireshark这样的程序中，但只有 87456321458585# 3 声音。 因此，第一个键（我认为这可能是一个单独的问题）和事件的任何重复（即 11111）都无法发出声音。

在上述链接文档的第 3.9 节图 2 中，他们给出了一个 911 示例，其中除了最后一个事件之外的所有事件都设置了 E 位。

当我将所有数字的“E”位设置为 1 时，我永远不会听到事件的声音。

我想到了一些可能的原因，但不知道是否是原因：

1）图2显示了发送的96和97的有效负载类型。我还没有发送这些标头。在第 3.8 节中，代码 96 和 97 被描述为“动态负载类型 96 和 97 已分别分配给冗余机制和电话事件负载”

2) 在第 3.5 节中，“E：”，“发送方可以延迟设置直到重新传输最后一个数据包以获取音调，而不是在第一次传输时结束位”有人知道如何实际执行此操作吗？

3）我有一个单独的输出流，它也在播放，所以想知道它是否会干扰听到这个流。

4) 还摆弄了时间戳间隔和 RTP 标记。

非常感谢任何帮助。以下是相关区域的 Wireshark 事件捕获示例：

6590 31.159045000 xx.x.x.xxx --.--.---.-- RTP EVENT Payload type=RTP Event, DTMF Pound # (end)
Real-Time Transport Protocol
 Stream setup by SDP (frame 6225)
  Setup frame: 6225
  Setup Method: SDP
 10.. .... = Version: RFC 1889 Version (2)
 ..0. .... = Padding: False
 ...0 .... = Extension: False
 .... 0000 = Contributing source identifiers count: 0
 0... .... = Marker: False
 Payload type: telephone-event (101)
 Sequence number: 0
 Extended sequence number: 65536
 Timestamp: 2000
 Synchronization Source identifier: 0x15f27104 (368210180)
RFC 2833 RTP Event
 Event ID: DTMF Pound # (11)
 1... .... = End of Event: True
 .0.. .... = Reserved: False
 ..00 0000 = Volume: 0
 Event Duration: 1000

请注意：音量为零是可获得的最大音量，如 ietf.org/rfc/rfc2833.txt 规范中所述：

“音量：对于 DTMF 数字和其他可表示为音调的事件， 该字段描述了音调的功率级别，表示为 去掉符号后以 dBm0 为单位。功率级别范围从 0 到 -63dBm0。有效 DTMF 范围为 0 至 -36 dBm0（必须 接受）;低于 -55 dBm0 必须被拒绝（TR-TSY-000181， ITU-T Q.24A）。因此，较大的值表示较小的体积。这 值仅针对 DTMF 数字定义。对于其他事件，它 被发送者设置为零并被接收者忽略。” 问题出在“事件结束”位打开时。

Answer 1

我建议您从 RFC 4733 开始，原因有两个：

1. 它废弃了 RFC 2833。
2. 第 5 章是了解如何生成 DTMF 数字的重要来源。

以下是我对如何发送 DTMF 数字的理解：

• 发出起始数据包。它设置了 M 标志并清除了 E 标志。事件的时间戳已设置。
• 发出一个或多个连续数据包（只要用户按下该数字）。他们的 M 和 E 旗帜已清除。它们使用起始数据包中定义的时间戳，但它们的序列号和持续时间会递增（有关间隔，请参阅 RFC）。
• 发送结束数据包（当用户停止按数字时）。它清除了 M 标志并设置了 E 标志。

为什么要为一个事件发送多个数据包？因为网络并不总是完美的，并且可能会发生一些丢失：

• RFC 声明（2.5.1.2.“事件数据包的传输”）：

  <块引用>

  为了稳健性，发送者应该
  重传“状态”事件
  定期。

  ：

• 并且（2.5.1.4.“最终数据包的重传”）：​​

  <块引用>

  每个事件的最终数据包以及
  对于每个段应该发送
  间隔期间总共 3 次
  由源用于更新。
  这确保了持续时间
  可以识别事件或片段
  正确地即使是一个实例
  最后一个数据包丢失。

至于你的问题：

如果例如键
7874556332111111145855885#3 是
按下，然后发送所有事件并且
出现在像wireshark这样的程序中，
但只有 87456321458585#3 声音。
所以第一把钥匙（我认为可以
是一个单独的问题）和任何重复
事件（即 11111）未能
声音。

如果没有 WireShark 跟踪，很难判断发生了什么，但我怀疑重复的 1 数字被忽略，因为连续事件之间没有区别；第一个 1 数字被识别，其他数字被视为事件的重传。

Answer 2

我注意到您的音量设置为 0；这似乎是听不到任何声音的可能原因？

Answer 3

美丽！非常感谢劳伦特。我已经根据您的建议实施了一个可行的解决方案。 （只是作为另一个答案发布以获得更好的文本格式 - 我会给你赏金）

总结出什么问题：

1. 我需要数据包的冗余。
2. 将所有“E”设置为 0 意味着重复的相同按键事件将被忽略。
3. 将所有“E”设置为 1 意味着我发出了事件结束的信号，但不是实际事件 - 因此是沉默。

这是一个总结的流程示例：

Event_ID    M    E    Timestamp      Duration    Sequence_number  
3           1    0    400            400          1
3           0    0    400            800          2
3           0    0    400            1200         3
3           0    0    400            1600         4
3           0    1    400            1600         5
3           0    1    400            1600         6
3           0    1    400            1600         7
7           1    0    800            400          8
7           0    0    800            800          9
7           0    0    800            1200         10
7           0    0    800            1600         11
7           0    1    800            1600         12
7           0    1    800            1600         13
7           0    1    800            1600         14

*注意：刚刚查看了第 5 节中建议的 rfc4733 第一个示例，非常棒！比2833好多了