posts/2025/no-sound-during-a-call/

[giscus[bot]]

posts/2025/no-sound-during-a-call/

简化网络模型

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这么久，碰到过很多疑难杂症。排查思路往往都是从软件或者网络策略层面去排查。 很少考虑到终端的固件和硬件设备上。
但是这次排查通话无声的问题，让我印象深刻的是，排查到最后才发现是硬件问题。
从声音的输出输出上，有不同的设备，例如有线耳机、蓝牙耳机、话机手柄、免提等。
排查这类问题，需要多方面考量。需要挖掘客户的实际使用场景，才能定位到真正的问题。
反思
客户的硬件话机，有两个接口。 手柄的接口和耳麦的接口是共用一套接口的。虽然接口上标注的很清楚，但是客户在接线的时候，没有注意到这点。
这要怎么避免呢？ 骂客户是傻逼吗？
是不是在设计接口的时候，就应该使用不同形状的接口。 比如手柄接口是圆形，耳麦接口是方形。 这样就能避免这种问题了。
或者说，接口是通用的。无论是手柄还是耳麦，插上都能用呢。
还有一种方案，就是只保留一个接口，手柄和耳麦共用一套接口。两者是互斥关系。

https://wdd.js.org/posts/2025/no-sound-during-a-call/

[Kitoali]

话机厂家设计的问题，有的话机手柄接头是方孔的，耳麦用的3.5mm耳麦接头

[Kitoali]

实际生成过程中经常遇到A->S无声的情况，问题大部分出现在设备层面，当然网络层面也存在，如果是基于saas平台软件的外呼，现实中配合坐席抓包，都要费一番功夫，仅做参考