离谱的通话无声问题排查记录

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

2025-05-07 22:45:26 · 1 min · Eddie Wang

DNS域名解析对MicroSIP注册的影响分析

microSIP DNS域名解析影响分析 MicroSIP是一款流行的windows VoIP客户端,它允许用户通过互联网进行语音和视频通话。在使用MicroSIP时,DNS域名解析是确保正确连接到服务器的重要步骤之一。 DNS域名解析是将人类可读的域名(如www.example.com)转换为机器可读的IP地址的过程。这个过程通常由用户的网络服务提供商(ISP)或本地计算机上的DNS缓存完成。 域名解析可以将一个域名解析为多个IP地址,例如:[ip1, ip2, ip3], 但是每次解析返回的顺序往往是不确定的,这取决于DNS服务器的配置和负载均衡策略。 例如第一次解析的结果可能是[ip1, ip2, ip3],而第二次解析的结果可能是[ip2, ip3, ip1]。 MicroSIP客户端在注册时,会尝试连接到这些IP地址中的第一个。 当分机使用TCP方式注册时,如果其第一个IP地址无法连接,它会继续尝试下一个IP地址,直到成功或所有IP地址都失败为止 如果分机使用UDP方式注册,它只会用第一个IP地址尝试注册,如果失败,还是继续尝试第一个IP。 这种行为似乎有点傻,为什么一直要尝试第一个IP地址,而不是尝试下一个呢? MicroSIP底层用了pjsip库,而pjsip只有在用tcp/tls注册时, 才会自动尝试下一个IP。pjsip官网也给出了具体的解决方案,就是应用层主动调用 pjsua_acc_modify() 函数,手动修改账号配置,然后重新注册。 但是microSIP并没有这么做,而是直接用一个固定的IP地址去尝试注册。 Our DNS SRV failover support is only limited to TCP (or TLS) connect failure, which in this case pjsip will automatically retries the next server. https://docs.pjsip.org/en/latest/specific-guides/sip/dns_failover.html 所以,总体上说。在使用域名注册的情况下,当前的注册和上一次的注册可能发往不同的SIP服务器。 考虑如下场景: # t1 dns解析结果 ip1, ip2, ip3 REGISTER sip:ip1:5060 SIP/2.0 200 Ok # t2 dns解析结果 ip3, ip1, ip2 REGISTER sip:ip3:5060 SIP/2.0 200 ok 一般分机都在内网环境,出口的公网IP是不变的,但是t1和t2的注册由于目标IP不同,所以出口的NAT映射的端口也是不同的。 ...

2025-04-30 17:36:58 · 1 min · Eddie Wang

读到无法解析的TCP包后, kamailio如何处理?

1int receive_msg(char *buf, unsigned int len, receive_info_t *rcv_info) { 2 if(parse_msg(buf, len, msg) != 0) { 3 errsipmsg = 1; 4 evp.data = (void *)msg; 5 6 // note: 这里尝试查找并执行nosip模块的 event_route[nosip:msg]事件路由 7 // 一般情况下,如果没有找到,那么ret的值是-1 8 // 那么这里的if内部不会执行 9 if((ret = sr_event_exec(SREV_RCV_NOSIP, &evp)) < NONSIP_MSG_DROP) { 10 LM_DBG("attempt of nonsip message processing failed\n"); 11 } else if(ret == NONSIP_MSG_DROP) { 12 // 这里也不会执行 13 LM_DBG("nonsip message processing completed\n"); 14 goto end; 15 } 16 } 17 18 // 由于在上面的判断里errsipmsg被设置成1,所以这里的if条件成立 19 if(errsipmsg == 1) { 20 // 打印报错信息,并执行核心错误处理 21 LOG(cfg_get(core, core_cfg, sip_parser_log), 22 "core parsing of SIP message failed (%s:%d/%d)\n", 23 ip_addr2a(&msg->rcv.src_ip), (int)msg->rcv.src_port, 24 (int)msg->rcv.proto); 25 sr_core_ert_run(msg, SR_CORE_ERT_RECEIVE_PARSE_ERROR); 26 27 // 跳转到error02标签,执行后续的清理工作 28 goto error02; 29 } 30 31// 跳转到error02标签,执行后续的清理工作 32error02: 33 free_sip_msg(msg); 34 pkg_free(msg); 35error00: 36 ksr_msg_env_reset(); 37 /* reset log prefix */ 38 log_prefix_set(NULL); 39 40 // 返回-1,表示出错 41 return -1; 42} 如果调用receive_msg返回负数,那么从调用栈向上查找receive_tcp_msg函数也会返回负数 int receive_tcp_msg(char *tcpbuf, unsigned int len,struct receive_info *rcv_info, struct tcp_connection *con) receive_tcp_msg函数返回负数,那么向上查找,tcp_read_req也会返回负数 int tcp_read_req(struct tcp_connection *con, int *bytes_read,rd_conn_flags_t *read_flags) tcp_read_req返回负数 inline static int handle_io(struct fd_map *fm, short events, int idx)在这个函数内部 if(unlikely(bytes < 0)) { LOG(cfg_get(core, core_cfg, corelog), "ERROR: tcp_read_req: error reading - c: %p r: %p (%d)\n", con, req, bytes); resp = CONN_ERROR; goto end_req; } resp = tcp_read_req(con, &n, &read_flags); if(unlikely(resp < 0)) { /* some error occurred, but on the new fd, not on the tcp * main fd, so keep the ret value */ if(unlikely(resp != CONN_EOF)) con->state = S_CONN_BAD; release_tcpconn(con, resp, tcpmain_sock); break; } 整个调用链条是这样的: handle_io -> tcp_read_req -> receive_tcp_msg -> receive_msg ...

2025-04-18 23:05:15 · 2 min · Eddie Wang

Default

2025-03-29 15:49:28 · 0 min · Eddie Wang

Hot Reload OpenSIPS vs Kamailio

用过nginx的都知道,改了nginx的配置文件,只需要执行nginx -s reload就可以让改动生效,而不用重启整个服务。 在kamailio和opensips中,也有类似的热重载功能。 在kamailio中,如果要热重载配置文件,只需要执行kamcmd app_jsdt.reload即可。 在opensips中,如果要热重载配置文件,只需要执行opensips-cli -x mi reload_routes即可。 理想很丰满,现实很骨感。 如果要只是修改路由模块,两者都可以做热重载。 如果要动态的新增一些模块,那就必须要重启。 Kamailio的实现方案 必须要用KEMI框架: cfg + [lua|js|python|ruby] 用这个框架,你写的路由脚本将包括两个部分 核心模块,全局配置,模块加载,模块配置,事件路由这部分内容还是写在cfg文件中。 请求路由、响应路由、分支路由、失败路由等这部分内容可以用lua、js、 python等来写。 在热重载的时候,实际上只有外部脚本会被重新加载,而核心模块是不会被重新加载的。 因为部分路由用其他脚本编写,必然涉及到性能比较。官方给出的结论是,在同等条件下,lua的性能是最好的。 https://www.kamailio.org/wikidocs/devel/config-engines/#interpreters-performances 但是实际生产环境如何,还不好说。 另外一点,就是并不是所有模块都实现了KEMI框架的接口,可能存在风险。 OpenSIPS的实现方案 OpenSIPS在3.0版本首次引入了热重载路由脚本的能力,脚本还是cfg,没有引入其他语言。 https://www.opensips.org/Documentation/Interface-CoreMI-3-0#toc8 结论 总体而言,目的是相同的,都是为了热重载路由。 kamailio的方案看似灵活,实则复杂。如果cfg本身就能做热重载,那么就没必要引入其他语言。 我更倾向使用OpenSIPS的方案 参考 https://blog.opensips.org/2019/04/04/no-downtime-for-opensips-3-0-restarts/

2025-03-29 13:49:38 · 1 min · Eddie Wang

开发学习笔记

架构图 kamailio 1.x版本 kamailio 3.x版本。相比于1.x版本,两个核心模块移动到外部模块。 核心模块 The core includes: memory manager SIP message parser locking system DNS and transport layer management (UDP, TCP, TLS, SCTP) configuration file parser and interpreter stateless forwarding pseudo-variables and transformations engines RPC control interface API timer API The internal libraries include: some components from old Kamailio v1.5.x core database abstraction layers (DB API v1 and v2) management interface (MI) API statistics engine SIP消息处理 请求处理 响应处理。 这里可以看到,是先执行响应路由,再执行失败路由。 ...

2025-02-21 22:17:35 · 7 min · Eddie Wang

kamailio 继承 HEP Server

目标 kamailio将所收到的SIP消息封装成HEP格式,然后已UDP发送给Hep Server 环境说明 kamailio版本 5.6 Hep server地址 192.168.0.100 kamailio脚本 listen 参考文档 https://www.kamailio.org/docs/modules/5.6.x/modules/siptrace.html https://github.com/sipcapture/homer/discussions/619 https://github.com/sipcapture/homer/wiki/Examples%3A-Kamailio

2025-02-17 22:57:11 · 1 min · Eddie Wang

HEP 协议学习笔记

HEP简介 HEP协议目前叫做EEP(Extensible Encapsulation Protocol), 那之前的缩写HEP的H,我只能推测为homer。 这个协议的主要功能是对VoIP连路上的数据包,例如SIP进行封装,方便后续分析SIP信令图。 目前这个协议已经升级到V3版本,在这个pdfHEP3_Network_Protocol_Specification_REV_36中有详细的介绍。 今天我们主要看这个协议的V3版本的协议是如何实现的。 包头 packet-beta title HEP Packet 0-3: "版本号" 4-5: "总长度" 6-15: "数据段(变长)" HEPv3的包头是6个字节,主要分为三个部分 版本号:固定4个字节长度,是HEP3 总长度:固定2个字节长度,是包的总长度,这个总长度包括了包头的六个字节。所以HEP包的大小范围一般是6-65535之间。 数据段:数据段的长度不固定 注意事项:假如从传输层读到1000个字节的数据,在解析前6个字节是,发现总长度(total length)的子段是1200,那就说明本次读到的数据还不是一个完整的 数据段解析 数据段由固定6字节长度的头部和变长的payload部分。 packet-beta title HEP Packet 0-1: "vendor ID" 2-3: "type ID" 4-5: "length" 6-15: "payload" vendor ID: 固定2字节长度, 其实意义不大, type ID: 固定2字节长度,这个子段很重要,决定了payload的类型。可以理解为是一个对象的key, 然后把payload理解为value length: 固定2字节长度,范围是0-65535,这个字段是也是整个数据段的长度,也就是包括了6个字节的段头 payload: 长度是length的长度-6,表示数据长度 hep协议有个type ID的映射表 chunk type ID 类型 描述 0x0001 uint8 IP类型,0x02=IPv4, 0x0a=IPv6 0x0002 uint8 协议类型 0x06=TCP, 0x11=UDP, 可以参考IP协议号列表 其他的字段还有很多,可以参考HEP3_Network_Protocol_Specification_REV_36 ...

2025-02-02 15:12:40 · 1 min · Eddie Wang

RFC768 UDP包学习笔记

包格式 UDP包头工占用8个字节, 其中源端口和目标端口各占2个字节,长度占2个字节,校验和占2个字节。 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | | | | Length | Checksum | +--------+--------+--------+--------+ | | data octets ... +---------------- ... User Datagram Header Format 字段 源端口,可选字段,默认为0,如果是有意义的其他端口,表示后续响应可以送回到该端口 目标端口,必须字段,用来关联目标主机上进程监听的端口 长度,长度是整个UDP包的长度,也就是包头 + 包的数据,包头固定8字节,那么length的最小长度就是8 校验和,用来验证传输过程中是否发生了错误。校验和的计算结果与源IP、目标IP、UDP的包长有关。 如果校验和失败,那么消息会被丢弃。 有些校验和计算的工作会被放置在网卡上,从而减少CPU的负载。当然如果在网卡上因为校验和的问题被网卡丢弃,上层应用是收不到不到UDP包的。但是用tcpdump可以抓到这种校验和有问题的包。 思考1: 为什么源端口可以设置为0? 答:有些UDP包,是不需要响应的,只需要发送出消息。 参考 https://datatracker.ietf.org/doc/html/rfc768 https://wdd.js.org/opensips/ch7/big-udp-msg/ https://wdd.js.org/network/udp-checksum-offload/

2025-01-01 20:23:41 · 1 min · Eddie Wang

2024年的最后三天 - 甲流来袭

28号 - 抗体 28号晚上,我觉得嗓子有点刺痛。因为前两周发过一次烧,我觉得这次嗓子痛应该不会是发烧的前奏了,毕竟身体是有抗体的。 我高估了之前产生的抗体。 29号 - 梦 从29号上午开始,身体就好像在温水煮青蛙,最高到达惊人的峰值40度。 为了控制体温,我先洗个热水澡,吃了布洛芬,躺在床上,拿了一块冰袋,裹在卫生纸里,搁在脑门上。身体挺直,裹着两层厚被。 长夜慢慢,睡睡醒醒。 我梦见自己变成了一棵树,脚上好像长出了根须,缓慢的往地下生长。穿过泥土,与蚯蚓擦肩而过。穿过岩石,被石油染黑。然而到达的却是一块冰山,冰冷坚硬。 手上长出了树干,像天空伸展,摊开自己的枝叶,还没等我享受片刻温暖,太阳仿佛飞速向我飞来,炙热的阳光让我瞬间枯黄,灰飞烟灭。 长夜慢慢,我不敢辗转反侧。我头上还顶着一块冰。 30号 - 发热门诊 终于熬到早上,再测试一遍体温,38度。 算了,还是去医院吧。 穿戴整齐,刚下楼,迎面吹来一阵冷风。我有种无法压抑的,想要咳嗽的冲动,但是我必须忍住,我知道这咳嗽必然“感天动地"。 风继续吹,我忍不住咳了出来,那感觉,仿佛有人伸手把我的气管从我的嘴巴里扯了出来。 到了医院,发热门诊是单独一层的小房子,和气派的十几层的门诊大楼相比,简直像个保安室。 发热门诊虽小,但也五脏俱全。 进门先做鼻拭子,量体温,挂号。 再做血液分析,然后就排队等叫号。医生看了报告,说我是甲流,开了两盒药,一盒抗病毒,一盒用来退烧。 从医院出来,已经中午。我走进医院旁边的永X大王,准备随便吃点。 我挑了一个座位,扫码下单,点了馄炖、蒸蛋、豆浆、银耳莲子羹。 等餐期间, 我发现对面有个中年人大叔,穿这黑色的宽大的羽绒服,胡子拉碴、头发稀少, 他时不时的巡视着其他的人。 没过过久,我等到自己的餐。 馄炖上撒了淡黄的鸡蛋丝和黑色海苔碎,鸡蛋丝吃起来像绳子,海苔碎味同嚼蜡。混度汤非常浑浊,像是用了一天的澡堂池子水。馄炖我就吃了一个,就放弃了。 蒸蛋应该是预制菜,放在黑色塑料小杯中,应该是微波炉加热的。我吃了一口,味道奇怪。 豆浆没什么好说的,毕竟也味道也没有下降空间了。 银耳莲子羹还不错,我都个喝完了。 吃饱喝足,顺便我把医生给我开的药也吃了,我起身离开,刚走到餐桌不到2米, 就瞥见那个大叔匆匆走向我的餐桌。 急诊室 我吃完饭,回到家,每隔一个小时测一次体温,体温很稳定,稳定在38度左右。 一直到晚上,我的体温还是没怎么下降。 老婆给我打电话,说让我赶紧去急诊,去输液,光吃药效果不好,高烧不退会要人命的。 但是我觉得没必要,因为尽然发热门诊的医生都没有让我输液,说明我不需要输液,或者说输液也没有多大作用。 老婆说:“你想让我中年丧夫吗?” 我无话可说,只能默默穿上衣服,带上口罩,去了早上那家医院的急诊。 晚上9点急诊室人来人往,络绎不绝,仿佛是白天的门诊。 我挂上号,接着又等了将近1个小时,终于等到我了。 给我看病的是位女医生。 ”医生,我在你们医院发生门诊早上就看过了,诊断是甲流,药也吃了,到现在还是38度,还是给我输液吧。“,我说 ”甲流不是一天两天能好的,至少要发热三天,而且输液效果也不大“,医生说 “那我也烧了两天了,再烧下去人要烧没了。你给我开个输液的吧” “好的吧,那我就给你开一次输液,你看看效果” 一顿拉扯,我终于能输液了。其实输的也不是什么特殊的东西,就是一带左氧和一袋维C。 输完液,已经晚上11点50,叫了车,回到家里。感觉嘴巴好苦,还好家里有甜的冰糖心苹果。 我啃完第一个苹果,每一口都是苦味。接着我再啃一个苹果,每一口都还是苦味。 如果不是因为发烧,我简直立即想去吃点火锅底料漱漱口。 归梦 睡觉前,我又量了一次体温。体温恢复到37度,看起来正常正常了。 我不知道这是吃药起的效果还是输液的效果。 但是两盒药的价格是270,其中一盒西药50,另一盒重要220。 输液呢,一袋左氧+维C,总共也不过才30。 让我想起了电影《大腕》的名言 31号 这是24年的最后一天,美丽的烟花在天空中绽放璀璨的光芒。 有些人觉得烟花美丽,有些人只觉得吵。

2024-12-31 21:06:09 · 1 min · Eddie Wang