ippbx出现单通故障解决过程总结

admin

公司售出的一套ippbx，下联iad，通过sip协议对接e1板卡，e1板通过dss1协议对接公网联通的程控交换机，反馈呼出电话接通后有一段时间被叫听不到声音，但过一段时间能恢复。还有问题是拨号后听到“您说拨打的用户现在不方便接听，请稍后再拨”。
2 E" t2 q- p" O' _( y1 q
  远程登录上去抓包，没有抓到现象，用户反馈是偶发现象，为此登录ippbx启动远程抓包服务器，用wireshark对远程设备进行抓包，启动多文件抓包方法。如下图：
" L  I' i8 S) k
+ _) c$ |: D8 E+ m

多文件抓包，每个包50M,进行预过滤，过滤udp port  5060  or  udp  portrange  10000-65500的sip消息和rtp流消息。

! d6 R6 _5 F. S# D' B$ c+ c8 ]用户反馈发生故障后，记录了用户的号码和主被叫号码和发生大概时间。找到对应时间的抓包，对抓包进行分析发现，
5 ]; V7 i* D! e" W
& o. E7 V# Q' U- k3 D

是固定电话拨打手机，听一下是那方通话掉了？

0 o1 ~3 q4 ]% V" X$ w' h6 w, D: Y

听到反馈的这次呼叫被叫说一段时间他听不到主机的声音，被叫的声音主叫听听着正常。被叫侧一段时间出现单通。
7 t6 `# |7 _, G5 v5 z% r7 J
但单独听主叫发给被叫的声音，是连续的，没有中断，是e1板没有发出还是对方手机网络或者传输中间环节造成了单通？
9 Z1 i! ?& F* w
据此无法判断哪里故障，因为可能e1版有问题，或者手机网络有问题，或者中间经过节点出现了问题？
+ T) c9 ]/ `5 ]) l- h7 B/ |$ q8 v  q3 G9 d


0 M2 D& V7 x# g/ @) _- u6 X) D因为用户仅反馈都是拨打手机出现的问题，无法确定是否是e1板发出的包有丢的还是对方手机网络的问题。

觉得e1板硬件出问题，应该出去的所以呼叫都会有问题，现在反馈的仅仅是拨打手机出问题。

6 x( c; M6 {- h" v% ?+ u4 s没有头绪，不知道怎么查找，因为e1发出的码流无法抓取监听，不能确定e1发出的有没问题？
0 F7 O5 I( K4 V* @' ]
1 e' x4 y# a( s* S, l再去查看拨出“听到无法接通“”提示音的问题，发现下面现象：

1 w6 }& S. Y9 N5 Z8 W
8 n% K, c3 Z/ s+ ^! }) K# U

4 v: u' f# b7 q! y0 N7 d$ [* R
' ]. B2 x- e; D8 J" a2 h0 P发现是转给e1板的呼叫没有收到后向消息，等超时后，ippbx给iad放音，释放了呼叫。

转给e1板的消息没有应答，100trying没有收到，5秒超时，ippbx直接给下面的iad放音了，暂时无法接通。
5 a* Q! a* I5 B
3 n, ^! b! \# z. m. A奇怪为什么e1板回invite的响应呢？要么没收到，要么收到了没回？这两种情况。
# U) g2 R$ m5 |( c3 T# Q
看这几个invite有啥特殊的地方？

$ q2 D  c# k# b7 W

' n. r- G3 j# q! J* K显然不是我司的产品00-0e-5e打头的mac地址。

, F; N0 e' W" ?  x对比正常呼叫的mac地址

: p9 {0 m( O( Z% j+ ~7 p% e

8 y5 k! I4 ?2 y1 c+ R9 L6 C据此，判断环境中存在两个172.31.234.108的ip地址，造成ippbx把invite消息发给了错误的mac地址，导致e1板没有收到这个invite消息，所以没有响应。当时没有抓arp包，应该是这个设备发出的查询172.31.234.220的mac地址，或者ippbx发出查询172.31.234.108的mac地址，这个冲突的设备回了，导致ippbx的mac地址被更新，导致的故障。
# t8 x7 O# X8 l3 `  n( R
9 B4 M6 }% v( i检查下面的iad有一个172.31.234.108的设备：
& j; i9 H: G& w/ t/ R

8 t$ ~6 e) M/ l( P( R: l6 C
让现场更改这个ip地址，防止和e1板冲突，后故障消除。
4 A9 \3 x1 I$ H8 z  ]1 t
改天抓的包里：
, X7 C5 u# w. i" m: k+ H
0 F4 M9 F. g/ L- g5 b( h8 M6 e
% j- V, V4 e" F: G
& ~( ^, b, V! I" ~9 d4 S改成了这个ip地址。
- H: g; W: y9 q! p8 m4 t
回头再去看单通的问题，发现单通的时间段里，消息发给了错误的mac地址。




- {; x* e5 e" p4 ~0 }


2 B& I% _2 ?9 @9 b+ H0 s5 z% U' P! s




0 W2 c- d7 |3 X3 g( N
' |& p3 C" W0 N结论：ip冲突导致单通和呼叫不通，arp单播消息导致mac地址被更改为错误的，导致ip层消息发给错误的地方，导致奇怪现象的发生。改天抓的包如下：
, \" ~9 ~/ e8 ^
& a1 W- a: l  v$ M/ }8 E9 @) h
& Q$ x+ Y$ _9 k- M
经验：不是下面那个拨叫不通听提示音的问题，还发现不了是ip冲突，以后遇到此类文件，还真得注意了，抓包要抓arp和sip协议和rtp协议和icmp协议（rtp发错地方会有icmp的提示），这样好排查故障。

wireshark里的ctrl+f可以快速找到字符串和16进制串，查找rtp的ssrc可以确定一个方向的语音流。sip contains 号码可以快速找到对应的通话流程包。
————————————————
" R* x3 H+ ^6 P/ C6 r9 Y4 c版权声明：本文为CSDN博主「wj31932」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
. x+ b) g- k8 S+ i+ M原文链接：https://blog.csdn.net/wj31932/article/details/100057318
1 X0 k/ [: w, w% B, E) h
9 o( j8 P% o, s/ ^1 p+ Z