4

为什么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 规范中所述，音量为零是可获得的最大音量：

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

4

3 回答 3

6

我建议您从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数字被识别，其他数字被视为事件的重传。

于 2010-05-11T22:36:57.077 回答
0

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

于 2010-05-11T04:37:08.880 回答
0

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

总结出了什么问题：

  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好很多

于 2010-05-12T18:04:50.603 回答