RFC 4733 事件持续时间在结束位答案

【问题标题】：RFC 4733 event duraton in the end bitRFC 4733 事件持续时间在结束位
【发布时间】：2013-02-28 14:34:03
【问题描述】：

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

【问题讨论】：

“最后 3 个 e-bits”是指三个独立数据包的 E 位吗？
不，我指的是单独的事件。例如，当按下数字 752 时，对于数字 7 上的事件，将发送 3 个 ebit。在 3 个 ebit 中的每一个中，如果事件持续时间在 3 个 ebit 之间增加，是否应将其视为三个单独的事件导致数字 7 的三倍，或者是否应忽略事件持续时间并在收到第一个 ebit 时停止事件？
当您说“对于第 7 位的事件将发送 3 个 ebits”时，我感到很困惑。 4733 谈到了一个 E 位 - 一个结束标记 - 但一个数据包中只有 1 个。即使是长事件，也只有事件的最后一个数据包才会设置其 E 位。
在 RFC 4733 第 2.5.1.4 节重新传输最终数据包每个事件和每个段的最终数据包应该按照源用于更新的时间间隔总共发送 3 次。话虽如此，在标记的第一个结束位中，事件持续时间为 720，下一个结束位事件持续时间为 800，最后一个结束位持续时间为 880。我有一个wireshark 捕获，我可以分享以帮助说明这一点.所以，我想弄清楚发送 3 次的结束位的事件持续时间变化是否会导致问题，或者这不是什么大问题。

标签： events sip rfc dtmf

【解决方案1】：

鉴于事件may be transmitted three times 的最终数据包，持续时间字段应单调增加。因此，在 cmets 的讨论中，我们看到三个数据包，每个数据包都设置了 E 位，持续时间分别为 720、800 和 880。这表明数据包间隔 80 毫秒发送，因为duration field in the packet 表示事件“已经持续时间只要此参数所指示的时间”。

但是，它仍然是一个单一的事件，因此您的事件播放应该持续到您收到的第一个数据包的持续时间。

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

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

【讨论】：

谢谢弗兰克斯。我认为也有一个错误导致了这种情况，但我很想知道这是否违反了 RFC 或者这是一个灰色区域。另外，我想知道是否违反 RFC 将每个具有递增事件持续时间的 e-bit 视为单独事件，从而导致音调三重？
是的，我认为这违反了 RFC：数据包显示音调仍在播放。

【解决方案2】：

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

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

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

另一方面（从 2.5.2.2 开始）

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

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

【讨论】：