RFC 4733结束位的事件持续时间

时间:2013-02-28 14:34:03

标签: events sip rfc dtmf

在阅读RFC 4733时,它没有明确说明事件持续时间是否不应在最后3个e位中递增。事件中的重要信息似乎是m位,时间戳和e位。如果事件持续时间在最后3个e比特中增加,那么将3个e比特中的每一个视为单独的事件并将音调重复三次是否有意义?或者,收到的第一个e位是否应该是事件的结束,最后2个ebit是否应该被拒绝?我有一个wireshark捕获,显示3个ebits中的事件持续时间递增,我正在试图弄清楚这一点。

2 个答案:

答案 0 :(得分:0)

鉴于事件may be transmitted three times的最终数据包,持续时间字段应单调增加。在评论的讨论中,我们看到三个数据包,每个数据包都设置了E位,持续时间为720,800和880.这表明数据包相隔80ms发送,因为duration field in the packet表示事件“到目前为止,只要这个参数表示持续“。

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

例如,您看到三个数据包到达,但如果第一个数据包(持续时间为720)没有到达,您将看到第二个数据包(持续时间为800),您应该播放800毫秒的音调

那就是说,我希望发件人能够以相同的持续时间发送结束数据包,而不是你所看到的。这可能是发件人中的错误。 (Transmission必须导致持续时间增加,但这是重新传输。)

答案 1 :(得分:0)

发件人明显违反了RFC

  1. 事件结束时应设置'E'位
  2. 持续时间根据事件的持续时间而增加
  3. 如果持续时间仍然在增加,那么事件显然还没有结束,但如果设置了E位,则事件已经结束 - 即矛盾

    另一方面(来自2.5.2.2)

    1. 一旦接收器收到事件结束,它应该停止播放音调。
    2. 一旦播出停止,接收器不应重启音色。
    3. 接收方可以根据保留的历史记录以及当前数据包的时间戳和事件代码确定它对应于已经播放和已经播放的事件。在这种情况下,必须忽略该事件的进一步报告
    4. 即。您可以告诉该事件已经从时间戳中播出,并且在这种情况下不应重复该事件