voip - "RFC 2833 RTP Event"连续事件和 E "End"位

Question

为什么 E 位为 0 时有 dtmf 声音而为 1 时没有声音？ (RTP 数据包以任何一种方式出现在wireshark 中)

背景:

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

例如，如果按下 7874556332111111145855885#3 键，则所有事件都会被发送并显示在诸如wireshark 之类的程序中，但只有 87456321458585#3 声音。
所以第一个键(我认为这可能是一个单独的问题)和事件的任何重复(即 11111)都没有发声。

在上述链接文档的图 2 的第 3.9 节中，他们给出了一个 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 规范中所述，零音量是可获得的最大音量级别:

"volume: For DTMF digits and other events representable as tones, this field describes the power level of the tone, expressed in dBm0 after dropping the sign. Power levels range from 0 to -63 dBm0. The range of valid DTMF is from 0 to -36 dBm0 (must accept); lower than -55 dBm0 must be rejected (TR-TSY-000181, ITU-T Q.24A). Thus, larger values denote lower volume. This value is defined only for DTMF digits. For other events, it is set to zero by the sender and is ignored by the receiver." The issue is when the "End of Event" bit is switched on.

Answer 1

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

它废弃了 RFC 2833 。

第 5 章是了解 DTMF 数字如何产生的重要来源。

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

发出开始数据包。它设置了 M 标志，清除了 E 标志。事件的时间戳已设置。

发出一个或多个延续数据包(只要用户按下数字)。他们清除了他们的 M 和 E 标志。它们使用在开始数据包中定义的时间戳，但它们的序列号和它们的持续时间是递增的(有关间隔，请参阅 RFC)。

发送结束数据包(当用户停止按下数字时)。它清除了 M 标志并设置了它的 E 标志。

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

RFC 声明(2.5.1.2.“事件数据包的传输”):

For robustness, the sender SHOULD retransmit "state" events periodically.

和(2.5.1.4.“最终数据包的重传”):

The final packet for each event and for each segment SHOULD be sent a
total of three times at the interval used by the source for updates.
This ensures that the duration of the event or segment can be recognized correctly even if an instance of the last packet is lost.

至于你的问题:

If for example keys 7874556332111111145855885#3 are pressed, then ALL events are sent and show up in a program like wireshark, however only 87456321458585#3 sound. So the first key (which I figure could be a separate issue) and any repeats of an event (ie 11111) are failing to sound.

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