1

在阅读RFC 4733时，它没有明确说明事件持续时间是否不应在最后 3 个电子位中增加。事件中的重要信息似乎是 m-bit、timestamp 和 e-bit。如果事件持续时间确实在最后 3 个 e-bits 中增加，将 3 个 e-bits 中的每一个视为单独的事件并将音调重复三倍是否有意义？还是应该接收到的第一个 e-bit 是事件的结束而最后 2 个 ebit 被忽略？我有一个 Wireshark 捕获，它显示事件持续时间在 3 个 ebit 中增加，我很想理解这一点。

4

2 回答 2

0

鉴于事件的最后一个数据包可能被传输 3 次，持续时间字段应该单调增加。在评论中的讨论中，我们因此看到三个数据包，每个数据包都设置了 E 位，持续时间分别为 720、800 和 880。这表明数据包间隔 80 毫秒发送，因为数据包中的持续时间字段表明事件“一直持续到此参数所指示的时间”。

然而，它仍然是一个单一的事件，所以你的事件播放应该持续到你收到的第一个数据包的持续时间。

例如，您看到三个数据包到达，但如果第一个数据包（持续时间为 720）没有到达，您会看到第二个数据包（持续时间为 800），您应该播放 800 毫秒的音调。

也就是说，我希望发件人以相同的持续时间发送结束数据包，而不是您所看到的。这可能是发件人的错误。（传输必须导致持续时间增加，但这是重传。）

于 2013-03-06T10:56:54.573 回答
0

发件人显然违反了 RFC，因为

  1. 事件结束时应设置“E”位
  2. 持续时间根据事件的持续时间增加

如果持续时间仍在增加，则显然事件尚未结束，但如果设置了 E 位，则事件已结束 - 即矛盾

另一方面（来自 2.5.2.2）

  1. 一旦接收器收到事件的结束，它应该停止播放音调。
  2. 一旦播放停止，接收器不应重新启动音调。
  3. 接收方可以根据保留的历史记录以及当前数据包的时间戳和事件代码确定它对应于一个已经播放和失效的事件。在这种情况下，必须忽略该事件的进一步报告

ie你可以从时间戳看出事件已经结束，在这种情况下不应该重复事件

于 2013-09-24T09:39:30.617 回答