简化网络模型
- A 硬件话机
- S SIP 服务器/媒体服务器
- B 客户手机
A <-SIP/RTP> S <-SIP/RTP> B
问题说明
通话接通后,双方听不到对方的声音。
呼叫流程
S 发起呼叫,A 接听后,bridge B
排查思路
- 检查S在INVITE A时,SDP里携带的c=行,是否是S的公网IP。检查后无问题
- 在A上抓包,发现有 S->A的RTP包,也有 A->S 的 RTP 包。
- 将第二步的抓包文件拿到wireshark中分析。发现S->A方向的包是正常的,能播放出声音;A->S方向虽然有RTP包,但是看波形是一条直线,非常奇怪。
- S->A方向的RTP包,在wireshark中能播放出声音,理论上A应该能听到B的声音的。但是用户反馈听不到。
- 咨询用户,用户是如何接听电话的。用户反馈是通过话机手柄接听的电话
- 让后让客户使用免提的方式拨打接听电话,发现可以听到声音。
- 让客户拍照话机手柄插入话机的接口,发现手柄插入的接头插入了耳麦的接口。
- 让客户将手柄插入正确的手柄接口,问题解决。
延伸思考
这次问题排查,让我想起了之前看过的思科的排除语音质量问题
这篇文章把语音质量问题分为三类:
- 网络相关(包括网关(GW)和PSTN问题)
- 电话型号/固件相关
- 设备(例如头戴式耳机)相关
在步骤上:
步骤1.隔离语音质量问题的第一步是找出确切的用户体验并与他们交谈(无论是面对面还是通过电话),以获得对语音质量问题的准确描述。如果有大量用户报告问题,请与他们的样本(可能是5-10个)交谈,以获得对症状的准确描述。
但是实际情况下,我们有时候迫于形势,往往只从一两个客户那里获得只言片语的信息,然后就开始排查了。客户的只言片语如果带有误导性,那么排查的方向就错了。
步骤2.记录物理位置(例如站点A,2楼)、用户名(用户的电话)、目录号码(DN)、电话型号(例如8865)、电话固件(例如11.5.1)和遇到语音质量问题的电话的IP地址。创建一个按物理位置排序的电子表格。在开始排除故障时创建此电子表格需要30分钟(或更短时间),可节省数小时甚至数天的故障排除时间。
记录信息很重要,但是实际操作中,往往因为时间紧迫,而没有记录这些信息。或者这些信息记录在头脑中,但是排查到最后才发现,自己忘记了某些信息。
步骤3.创建电子表格后,查看电话列表,了解电话有哪些共同之处,以及它们与没有语音质量问题的其他电话有何不同。之后,您可以意识到所有有问题的电话都位于同一栋大楼和同一楼层,您可以意识到有问题的电话连接到最近升级的交换机,或者您可以看到所有有问题的电话都位于特定固件上。
总结
搞VoIP这么久,碰到过很多疑难杂症。排查思路往往都是从软件或者网络策略层面去排查。 很少考虑到终端的固件和硬件设备上。
但是这次排查通话无声的问题,让我印象深刻的是,排查到最后才发现是硬件问题。
从声音的输出输出上,有不同的设备,例如有线耳机、蓝牙耳机、话机手柄、免提等。
排查这类问题,需要多方面考量。需要挖掘客户的实际使用场景,才能定位到真正的问题。
反思
客户的硬件话机,有两个接口。 手柄的接口和耳麦的接口是共用一套接口的。虽然接口上标注的很清楚,但是客户在接线的时候,没有注意到这点。
这要怎么避免呢? 骂客户是傻逼吗?
是不是在设计接口的时候,就应该使用不同形状的接口。 比如手柄接口是圆形,耳麦接口是方形。 这样就能避免这种问题了。
或者说,接口是通用的。无论是手柄还是耳麦,插上都能用呢。
还有一种方案,就是只保留一个接口,手柄和耳麦共用一套接口。两者是互斥关系。