在tcpdump上捕获奇怪的流DTMF

时间:2010-10-02 05:48:40

标签: sip rtp dtmf

我捕获了一个SIP调用的tcpdump来调试DTMF问题(重复的数字),但是我有一些问题需要解释它。

根据我的理解,当我通过wireshark的“VOIP CALL”解析捕获的流量时,我应该看到类似这样的内容(数字123):

捕获1
RTP电话活动DTMF One 1
(活动结束)
RTP电话活动DTMF二2
(活动结束)
RTP电话活动DTMF三3
(活动结束)

但我看到的却是这样 捕获2
RTP电话活动DTMF One 1
RTP电话活动DTMF One 1
RTP电话活动DTMF One 1
(端部)
RTP电话活动DTMF二2
RTP电话活动DTMF二2
RTP电话活动DTMF二2
(端部)
RTP电话活动DTMF二3
RTP电话活动DTMF二3
RTP电话活动DTMF二3
(结束)

在1系统上,CAPTURE 2被检测为123,但在另一个系统上,它似乎将其解码为具有重复数字。 Wirehark没有将它们组合在一起作为单个RTP事件的原因是什么?

这是rtp交通流量:
捕获1:

RTP EVENT DTMF 1
RTP EVENT DTMF 1
RTP EVENT DTMF 1(结束)
RTP EVENT DTMF 1(结束)
RTP EVENT DTMF 1(结束)
RTP EVENT DTMF 2
RTP EVENT DTMF 2
RTP EVENT DTMF 2(结束)
RTP EVENT DTMF 2(结束)
RTP EVENT DTMF 2(结束)
RTP EVENT DTMF 3
RTP EVENT DTMF 3
RTP EVENT DTMF 3(结束)
RTP EVENT DTMF 3(结束)
RTP EVENT DTMF 3(结束)
RTP PAYLOAD
...
...
...
RTP PAYLOAD

而CAPTURE 2则是:
RTP EVENT DTMF 1
RTP PAYLOAD
RTP EVENT DTMF 1
RTP PAYLOAD
RTP EVENT DTMF 1(结束)
RTP PAYLOAD
RTP EVENT DTMF 1(结束)
RTP PAYLOAD
RTP EVENT DTMF 1(结束)
RTP PAYLOAD
RTP PAYLOAD
RTP PAYLOAD
RTP PAYLOAD
RTP PAYLOAD
RTP EVENT DTMF 2
RTP PAYLOAD
RTP EVENT DTMF 2
RTP PAYLOAD
RTP EVENT DTMF 2(结束)
RTP PAYLOAD
RTP EVENT DTMF 2(结束)
RTP PAYLOAD
RTP EVENT DTMF 2(结束)
RTP PAYLOAD
RTP PAYLOAD
RTP PAYLOAD
RTP PAYLOAD
RTP EVENT DTMF 3
RTP PAYLOAD
RTP EVENT DTMF 3
RTP PAYLOAD
RTP EVENT DTMF 3(结束)
RTP PAYLOAD
RTP EVENT DTMF 3(结束)
RTP PAYLOAD
RTP EVENT DTMF 3(结束)
RTP PAYLOAD
RTP PAYLOAD
RTP PAYLOAD
RTP PAYLOAD
RTP PAYLOAD
RTP PAYLOAD

CAPTURE 2是否遵循RFC2833?

2 个答案:

答案 0 :(得分:3)

实际上,该规范鼓励您冗余传输RTP事件数据包,因为可能丢包,他们建议至少每次发送3次。检查每个重复事件的开始和结束时间。如果你需要扩展事件(键仍然按下,比你想在一个事件中编码的时间长,等等),那么你可以扩展它而不会结束它。

这也是End数据包发送3次的原因。 (见section 3.6 of RFC 2833)。

答案 1 :(得分:2)

RFC 2833“事件”完全编码为多个RTP数据包是完全可能的。第3.6节告诉我们

  

如果事件持续超过   一个时期,产生的源头   事件应该发送一个新的事件包   使用RTP时间戳值   对应的开头   事件和事件的持续时间   相应增加。

RFC将“一个周期”定义为50ms。

所以

RTP EVENT DTMF 1
RTP EVENT DTMF 1
RTP EVENT DTMF 1(结束)

意味着我们有人按下1键约150ms。