2010-10-02 105 views
0

我捕获了一个SIP调用的tcpdump来调试DTMF问题(重复数字),但我解释它有一些问题。在tcpdump上奇怪的流DTMF捕获

据我了解,当我经过的Wireshark“VoIP通话”分析捕获的流量,我应该看到这样的事情(为数字123):

捕捉1
RTP电话事件DTMF一个1
(事件的结束)
RTP电话事件DTMF两个2
(事件的结束)
RTP电话事件DTMF三个3
(事件的结束)

但我看到这个代替
CAPTURE 2
RTP电话事件DTMF一个1
RTP电话事件DTMF一个1
RTP电话事件DTMF一个1
(完)
RTP电话事件DTMF双2
RTP电话事件DTMF两个2
RTP电话事件DTMF两个2
(结束)
RTP电话事件DTMF两个3
RTP电话事件DTMF两个3
RTP电话事件DTMF两个3
(结束)

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

这是RTP流量:
CAPTURE 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 EV ENT 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(end)
RTP PAYLOAD
...
...
...
RTP有效载荷

而CAPTURE 2是:
RTP EVENT DTMF 1
RTP有效载荷
RTP EVENT DTMF 1
RTP有效载荷
RTP EVENT DTMF 1(端)
RTP有效载荷
RTP EVENT DTMF 1(结束)
RTP PAYLOAD
RTP EVENT DTMF 1(结束)
RTP PAYLOAD
RTP有效载荷
RTP有效载荷
RTP有效载荷
RTP有效载荷
RTP EVENT DTMF 2
RTP有效载荷
RTP EVENT DTMF 2
RTP有效载荷
RTP EVENT DTMF 2(结束)
RTP有效载荷
RTP EVENT DTMF 2(结束)
RTP PAYLOAD
RTP EVENT DTMF 2(结束)
RTP有效载荷
RTP有效载荷
RTP有效载荷
RTP有效载荷
RTP EVENT DTMF 3
RTP有效载荷
RTP EVENT DTMF 3
RTP有效载荷
RTP EVENT DTMF 3(端部)
RTP有效载荷
RTP EVENT DTMF 3(end)
RTP PAYLOAD
RTP EVENT DTMF 3(end)
RTP有效载荷
RTP有效载荷
RTP有效载荷
RTP有效载荷
RTP有效载荷
RTP负载

的是捕获2以下RFC2833?

回答

2

RFC 2833“事件”很可能被编码为多个RTP数据包。第3.6节告诉我们,

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

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

所以

RTP事件DTMF 1
RTP事件DTMF 1
RTP事件DTMF 1(完)

意味着我们有专人按1个键周围150毫秒。

+0

谢谢,你知道这是否会导致其他系统将其解释为重复的数字? – rtpquestion 2010-10-03 14:50:31

+0

它们不应该:最后一个数据包应该设置E位,表示事件结束。 – 2010-10-03 15:52:22

+0

@FrankShearar陈述弗兰克...但我有查询你....我想检测DTMF模式的思科PH从RTP数据包...我做的是我检查有效载荷类型....然后我检查dtmfeventend是否为1,如果1则在名为“tobematchpattern”....的本地变量中添加DTMF事件值的值,并等待下一个dtmfeventend,但如果要匹配的模式可以说为111或222 ....如果要匹配的模式是123或456,我的意思是数字是有区别的 – Harry 2017-11-20 14:44:04

3

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

这也是为什么End数据包发送3次。 (请参阅section 3.6 of RFC 2833)。