背景：

我可以按http://www.ietf.org/rfc/rfc2833.txt所述发送RFC 2833 dtmf事件未设置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到 -63 dBm0。有效DTMF的范围是0到-36 dBm0（必须接受）;低于-55 dBm0必须拒绝（TR-TSY-000181， ITU-T Q.24A）。因此，较大的值表示较低的体积。这个 value仅为DTMF数字定义。对于其他事件，它发送方将其设置为零，接收方将忽略它。“ 问题是当“事件结束”位被打开时。

Answer 1

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

它阻碍了RFC 2833。
第5章是了解如何生成DTMF数字的重要来源。

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

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

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

RFC声明（2.5.1.2。“事件包的传输”）：

为了健壮，发件人应该转发“国家”事件周期性。
和（2.5.1.4。“最终数据包的重传”）：


每个事件的最终数据包和   对于每个部分，应该发送一个
  每隔一段时间共三次   由来源用于更新。
  这确保了持续时间   事件或细分可以被识别   正确的，即使是一个实例   最后一个数据包丢失了。

至于你的问题：

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

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

Answer 2

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

Answer 3

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

总结出错了：

我需要数据包冗余。
将所有'E'设置为0表示忽略了重复的相同键事件。
将所有'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个好得多

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

背景：

3 个答案: