2026 服务器租用搭建 Kamailio 信令网关怎么选：UDP 丢包/注册风暴/并发会话 对比避雷全解

2026 服务器租用搭建 Kamailio 信令网关怎么选：UDP 丢包/注册风暴/并发会话 对比避雷全解

把 Kamailio 装到租来的物理机上，是做 VoIP、呼叫中心、语音机器人的团队迟早要走的一步。它开源、能扛量、路由逻辑想怎么写就怎么写，但"能跑通"和"能扛住业务量"之间隔着好几次事故。我见过最典型的翻车不是配置写错，而是资源账一开始就算错了方向：把信令机当成一台要吃掉所有语音流量的机器去买带宽，结果网卡每秒包数先撑不住；或者反过来，认定"信令包很小"于是按最低配买内存，注册量一上来 usrloc 就把共享内存啃光。这篇文章只讲一条主线——信令面要什么资源、媒体面要什么资源、两者什么时候必须分家，以及分家之后故障面落在哪一层。

先认清 Kamailio 是什么：它只管信令，不碰语音

Kamailio 是一个用 C 写的开源 SIP 服务器，GPL 授权。它的谱系得从德国 Fraunhofer FOKUS 研究所的 SIP Express Router（SER）说起：SER 第一行代码写于 2001 年，2002 年以 GPL 公开发布；2005 年，几位 SER 核心开发者因为项目管理与贡献政策上的分歧分出 OpenSER；2008 年 OpenSER 因商标问题改名为 Kamailio，几乎同时，持有 openser.org 域名的一方另起了 OpenSIPS 项目。两支从此各走各路，代码树再也没有合并。2010 年 1 月发布的 Kamailio v3.0.0，才是 SER 与 Kamailio 源码树真正合并后的第一个版本。这段历史不是八卦，它解释了一件事：你在网上搜到的很多"OpenSER 配置"在今天的 Kamailio 上仍然大体可用，但模块名和参数名变了，照抄会踩空。

它在生产里通常承担四种角色：registrar（注册服务器，维护用户位置）、proxy（信令代理与路由）、负载均衡器（把 INVITE 分给后面的 Asterisk/FreeSWITCH 群）、会话边界（做拓扑隐藏、限速、协议规整）。这四种角色的共同点是——全部只处理 SIP 报文。RTP 语音流要么在两端之间直连，要么交给 rtpengine、rtpproxy 这类专门的中继进程。Kamailio 自己不转发一个字节的音频。这个事实是所有资源估算的地基。

带宽账的真正算法：并发通话数乘编码码率，而不是包数

一次 G.711 通话在以太网上的开销，按思科那份被广泛引用的算法是每方向约 87.2 kbps：编码净荷 64 kbps，20 毫秒打包即每秒 50 个包，每个包背 40 字节的 IP+UDP+RTP 头，再加 18 字节的以太网二层开销。G.729 净荷只有 8 kbps，但同样 50 pps，算上头就是每方向约 31.2 kbps。看清了吗——编码码率差了八倍，实际占用只差不到三倍，因为头部开销是固定的。所以压低编码能省带宽，但省不到你以为的那么多。

信令这一侧的账完全是另一个量级。一次呼叫从 INVITE 到 BYE，生命周期内大约十几个 SIP 报文，每个几百字节到 1KB 出头。摊到 60 秒的通话时长上，信令占用的带宽通常不到 1 kbps，就算把重传和 OPTIONS 保活算进去也是零头。结论很直接：信令机的带宽需求几乎与并发通话数无关，媒体机的带宽需求与并发通话数成正比。一千路 G.711 双向通话，如果媒体要从你这台机器上过，就是 87.2 × 2 × 1000 ≈ 174 Mbps，同时每秒十万个包；如果这个量不过媒体，那台机器的公网流量可能只有几 Mbps。

这里有个容易被忽略的次序问题：先到瓶颈的通常不是带宽，而是 pps。10 万 pps 的小包在一张没做多队列、没绑中断的千兆卡上就已经很难看了，哪怕带宽只用了不到两成。所以选机器时，网卡的队列数和 CPU 的核数，比"给多少兆带宽"更值得较真。

kamailio.cfg 的执行顺序：为什么照抄示例配置一上线就炸

配置文件的执行模型必须先搞清，否则排障时你连该看哪一段都不知道。request_route 是主入口，每个 SIP 请求都从这里进；它的隐式动作是丢弃——想回复或转发必须在块里显式调用。branch_route 由 tm 模块通过 t_on_branch 挂载，对每个分支各执行一次，适合做按目的地址的差异化改写。failure_route 由 t_on_failure 挂载，注意它处理的是发起事务的那个请求，不是收到的失败响应，这一点搞混的人非常多。reply_route（也叫 onreply_route[0]）由核心执行，早于任何模块处理响应，可选，缺失时响应按第二个 Via 头发回；tm 的 onreply_route 需要用 t_on_reply 单独挂载。还有 onsend_route，在报文真正发出时触发，只允许 drop、if 判断、日志、send() 这类有限动作。

模块加载同样有秩序：loadmodule 的先后顺序体现依赖，auth_db 依赖 auth 与数据库模块，dmq_usrloc 依赖 dmq 与 usrloc，dispatcher 的健康探测需要 tm 在场；modparam 必须写在对应模块加载之后。至于"照抄示例就炸"，我总结下来就四类原因。第一类是数据库没准备好：示例默认连接本地 MySQL 的 kamailio 库，库没建、账号没授权，usrloc 和 auth_db 在启动阶段就报错，进程起不来或者起来了但注册全 500。第二类是监听地址写错：listen 写成 127.0.0.1 或者内网地址，公网终端发来的 Via 与源地址永远对不上，nat_uac_test 恒为真，注册能成功但呼不进去。第三类是传输层没开全：只 listen 了 udp:5060，走 5061 的 TLS 终端连握手都做不了。第四类是 RTP 端口段没放行：信令一切正常，接通即静音。

我的做法是，新机器上线前先跑一遍"空配置验证"：只加载核心加 sl 模块，确认能从公网收到包并回 200，然后一层一层往上加模块。加一层，抓一次包。这样炸的时候你知道是哪一层炸的，而不是面对一个几百行的配置文件发呆。

UDP、TCP、TLS 三选一：重传定时器、连接内存与强制加密的场景

UDP 是 SIP 的默认承载，代价是可靠性得靠事务层自己补。RFC 3261 第 17 章给出的定时器默认值是 T1=500ms（RTT 估计）、T2=4s（非 INVITE 请求与 INVITE 响应的重传上限）、T4=5s（报文在网络中的最长停留）。INVITE 的重传间隔从 T1 起步逐次翻倍——500ms、1s、2s、4s、8s、16s、32s，事务超时 Timer B 为 64*T1，也就是约 32 秒。这组数字直接决定了丢包的用户感受：丢一个 INVITE，用户不是听到杂音，而是按拨号键之后干等好几秒才回铃，或者直接等来一个 408。丢一个 REGISTER 更隐蔽，终端可能在你察觉之前就已经掉线几十秒了。

事务层（tm 模块）为每一个进行中的事务保留状态，这是 UDP 模式下的主要内存开销来源之一。事务表配小了，峰值时不是慢，而是直接创建事务失败、回 500。所以我把 tm 的事务数量当成和 usrloc 同等级别的容量参数来算，而不是丢在默认配置里不管。

TCP 与 TLS 换成另一套账：长连接。好处很实在——NAT 映射的保活周期可以从 UDP 的二三十秒拉长到十几分钟，移动终端因此省电，注册也更稳；报文不再受 MTU 限制。RFC 3261 明确要求，报文超过一定大小（业界通常按 1300 字节这个经验值把握）就必须改用具备拥塞控制的传输协议，而带 SDP、多编码、ICE 候选的 INVITE 轻轻松松就会超过这个线，UDP 分片被中间设备丢弃是常见故障。代价是每台机器要多扛一张连接表，文件描述符、每连接内存、并发连接数上限都得算。

什么时候必须 TLS？公网暴露且要保护摘要认证的凭据、浏览器侧的 WebRTC 要走 WSS、对接方或合规要求加密信令——这三种情况没有商量余地。需要提醒的是，TLS 只保护信令，语音本身要用 SRTP，两者不是一回事。TLS 握手是非对称运算，重连风暴时 CPU 会突然拉满，务必开启会话恢复（RFC 5077 的 session ticket）；媒体侧则依赖 CPU 的 AES-NI 指令集，跑 SRTP 却没有硬件加速的老机器，吞吐会难看得多。这一条我在选型时是硬卡项。

注册风暴与扫号：CPU 尖峰的来源和限速的三层做法

机器只要暴露在公网上，很快就会被扫描器光顾，这几乎是必然事件，不是概率事件。现实中的威胁形态主要是三类：撞用户名密码（你的平台每秒能处理几千个包，对攻击者来说猜口令非常划算）、撞路由前缀（探测哪些号码段能出局）、以及纯粹的 DoS 消耗 CPU。第三类的杀伤力常被低估——每一个携带凭据的报文都要触发一次数据库查询和一次哈希运算，带凭据的包比空包贵一个数量级，几秒钟几千个 REGISTER 就能把 CPU 打到 100%。

限速我一般分三层做。最内层是 pike 模块：它按源 IP 统计单位时间内的请求数，用 sampling_time_unit 和 reqs_density_per_unit 两个参数定义阈值，超限就丢弃。模块文档写明实际封禁阈值落在 x 与 3x 之间（IPv4），不是精确值；项目核心开发者在邮件列表里也解释过，孤立 IP 通常需要 3 倍采样周期才被封，而同一 /24 网段里已有 IP 被封时会更快触发。别指望它做精确计量，它是个粗糙但有情的闸门。

第二层是 htable 配合 pike 做"封一段时间"：定义一张带 autoexpire 的 ipban 表，命中后把源 IP 写进去，到期自动清除。攻击者即使降速，在这段时间里也进不来。第三层才是 fail2ban 读日志写 iptables，代价最低但对容器化和多网卡环境不太友好。判读指标也简单：盯 401 与 403 的比例、以及每秒 REGISTER 数的基线，基线翻倍且伴随 CPU 抬升，基本就是扫号来了。补一句合规边界：这里讲的是防护自有平台，任何主动绕过他人风控、伪造号码、批量骚扰的行为都不在讨论范围内，也不该出现在你的业务里。

usrloc 的五种存储模式与认证哈希：重启掉号与写放大怎么权衡

usrloc 的 db_mode 决定注册记录存在哪。新版模块文档给出五种：0 是纯内存，最快，重启即丢；1 是 write-through，每次变更立刻落库，最可靠也最慢；2 是 write-back，变更先进内存，由定时器批量刷库，适合有明显波峰但非持续高负载的场景；3 是 db-only，不走内存缓存，所有操作直连数据库，适合多机共享同一个库但不在 SIP 层做复制的场景，代价是每次 NAT 保活都要从库里捞一遍记录，注册量大时数据库会很难受；4 是启动时从库加载、运行期纯内存且不回写，配合复制到专门做持久化的节点使用。默认值是 0。

我的判断是：注册量上了规模就别指望数据库扛写放大。write-through 在注册风暴里是第一个挂掉的组件，而它的挂掉方式是整个平台的注册全失败。更合理的组合是 usrloc 用 0 或 2，冗余交给 SIP 层的复制去做，数据库只当冷备。代价是重启会丢最后一批注册，这个可以用缩短 timer_interval 来压缩窗口——默认是 60 秒，我通常调到 20 到 30 秒。

认证侧的取舍在哈希算法。传统做法是预计算 HA1，即 MD5(username:realm:password)，存进 subscriber 表的 ha1 列，服务端不需要知道明文口令，数据库泄露也无法直接反推密码。calculate_ha1 参数决定服务端是拿明文现算还是直接比对预计算值，选预计算。更强的算法方面，OpenSIPS 的 auth_db 模块文档里已经列出了 RFC 8760 对应的 ha1_sha256、ha1_sha512t256 列；Kamailio 侧对 SHA-256 摘要的支持方式与版本相关，公开资料口径不一，动手之前请以你所用版本的官方模块文档为准，不要凭一篇博客就上生产。

多实例分发与共享位置表：高可用到底做在哪一层

单台撑不住或者不能停机的场景，标准做法是前置多台 Kamailio 加 dispatcher 分发。ds_select_dst(set, alg) 的 alg 参数里，0 是按 Call-ID 哈希、1 按 From URI、2 按 To URI、3 按 Request-URI、4 是轮询、8 按优先级排序、9 按权重分配。哈希类算法的好处是同一个会话的请求会落到同一台机器，对有状态处理友好；轮询分发更均匀但要求后端无状态或状态已共享。健康探测用 ds_ping_method（默认 OPTIONS）、ds_ping_interval、ds_probing_mode、ds_probing_threshhold 这一组参数调，探测太灵敏会误摘，太迟钝会把流量继续打到已故障的节点上。

真正的难点是位置表。终端注册在 A 节点，呼叫落到 B 节点，B 查不到位置就呼不通。dmq_usrloc 模块就是解决这个的：它通过 DMQ 在节点间复制 usrloc 记录，消息用 SIP 承载、通常单独监听一个端口（示例配置里常见 5090），方法名是 KDMQ，节点通过 DNS 的多个 A 记录互相发现。启动时可以请求全量同步，用 batch_size、batch_usleep、batch_msg_size、batch_msg_contacts 几个参数限流，避免同步流量把新加入的节点自己冲垮。anycast 场景还要开 replicate_socket_info。

这里有个坑我见过不止一次：如果客户端在 NAT 后面，即使位置记录同步到了所有节点，发往它的请求也必须经回它注册的那个节点，否则路径不对。这个要靠 registrar 的 Path 支持或者 socket 信息复制来解决，光复制 usrloc 不够。至于单点故障面，请按这张清单逐个过：数据库（db_mode 选 1 或 2 时它是硬依赖）、RTP 中继（它挂了的表现是"能接通但没声音"，最容易被误判成网络问题）、CDR 写入、以及 dispatcher 自身的探测链路。多数团队以为做了双机就没单点，实际上把数据库放在了其中一台上。

NAT、SIP ALG 与 RTP 端口范围：单通和无音的定位顺序

对称 NAT 下终端无从得知自己的公网地址，SDP 里填的是私网地址，媒体必须中继，这是硬约束，没有取巧空间。而 SIP ALG 是另一种性质的麻烦：家用和企业路由器上的 ALG 本意是帮忙改写地址，实际却经常改错，典型后果是单通、注册成功但打不通、通话在固定时长（常见三十分钟左右）被掐断。路由器厂商的公开资料几乎一致建议关掉它，运维界的共识也是先关了再说——关掉 ALG 解决的是"结构性"故障，而双向都断续、机器人音这类是链路质量问题，别混为一谈。

Linux 一侧要注意 nf_conntrack 的 SIP helper 与 UDP 超时。连接跟踪表被打满会直接丢包，表现是随机的注册失败和呼叫建立失败；UDP 的 conntrack 超时偏短，注册刷新周期必须小于它，否则 NAT 映射在两次 REGISTER 之间就消失了，现象是"话机一会儿在线一会儿离线"。运营商级 NAT 和家庭宽带光猫的场景尤其明显。

端口规划也要提前算。rtpengine 常见配置是 10000 到 20000 这段，一万路双向通话需要约两万个端口（每路 RTP 与 RTCP 各占一个端口、两个方向共四个）。别等到"No ports available"才开始扩段。定位单通时我的固定顺序是：用 sngrep 抓包看 SDP 的 c= 行是不是私网地址；确认 onreply_route 里对 1xx 和 2xx 也调了 rtpengine_manage（只改写 INVITE 不改写 200 OK 是最经典的单通原因）；再核对防火墙端口段双向放行；最后查 rtpengine 对外通告的地址是否正确。这个顺序能省掉大量来回猜测。

conntrack 表、时钟与 CDR 口径：不显眼但会让对账崩掉的细节

CDR 是语音平台最容易出争议的地方，而争议大多源自口径没提前定死。起算时间用 200 OK 还是被叫实际应答？结束时间用 BYE 还是主叫挂机的那一刻？未接通的呼叫要不要出话单？重协商（re-INVITE）导致的编码变化要不要记？这些问题在上线前不定清楚，等财务来对账时你会发现两套系统算出来的时长永远差几个百分点，而且说不清差在哪。

时钟同步是另一个低调的杀手。多节点平台的 CDR 时间戳如果各走各的，话单排序会错乱，极端情况下算出来负的通话时长。所有节点统一 NTP 源，监控里加上时钟偏移告警，这两件事花不了多少时间但能救一次大事故。日志方面，xlog 的级别决定写盘量，生产环境别开到 DEBUG；syslog 走异步，且日志分区要和根分区分开——磁盘被日志写满导致进程异常，是完全可以避免的低级事故。

配置账：CPU、内存、磁盘、网卡与管理口怎么配

CPU 这一项，信令处理的主要消耗是报文解析、路由脚本执行、摘要认证的哈希运算，以及 TLS 握手。多进程模型下核数比单核主频更值钱，但 TLS 握手的峰值会打在单个核上，所以别选核数很多却单核很弱的型号。媒体与加密场景务必确认 CPU 支持 AES-NI。内存要用两段来算：共享内存 shm 存放 usrloc 记录、tm 事务、dispatcher 目标集等全局数据，官方默认从 4.2.0 起是 64MB，pkg（每进程私有内存）默认 8MB；注册规模上万、并发事务多的时候，shm 必须主动调大，并养成用 kamctl stats shmem 定期看剩余的习惯。进程数乘 pkg 是另一块开销，children 配太多会白白吃掉内存。磁盘倒是不吃容量，CDR 和日志量都不大，但要求稳定写入和独立分区。网卡看队列数与中断绑定，pps 比带宽先到瓶颈。管理口一定要独立：DMQ 同步、数据库访问、rtpengine 控制信令、监控采集都不该和公网 SIP 挤同一张网卡。

地区选择上，用户与中继侧集中在哪就往哪放——华南、华东、华北是最常见的三个落点，跨境与出海业务会考虑中国香港节点。需要说明的是，语音业务涉及号码资源与经营资质，各地要求不同，需要自行向当地主管部门核实，机房位置的选择代替不了这一步。以一万网络官网公开的起步信息为例，华南 ¥799、华东 ¥699、华北 ¥899、中国香港 ¥1500 起，具体机型、带宽与报价以官网实时信息或咨询确认为准。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。裸金属形态在这类业务里比虚拟化更省心，中断延迟和 pps 抖动都可控，媒体中继尤其明显。

六种部署形态的横向对比与判读方法

下面这张表按"是否过媒体"这条主线把常见部署形态摊开，六种形态的带宽量级和故障面完全不同，选错了多花钱还更难维护。

判读这张表的方法只有三步。先看第二列"是否过媒体"，它直接决定你要买带宽还是买 pps——过媒体的形态，带宽按并发通话数线性增长；不过的形态，带宽根本不是约束条件。再看第四列"并发瓶颈"，它告诉你扩容该加什么：写的是 CPU 与事务表，就加核、调 shm；写的是 pps 与中断，就换多队列网卡、做中断绑定、把媒体拆出去。最后看第五列"主要故障面"，列出的每一项都应该有对应的冗余或预案，列了三项却只做了双机的方案，等于默认接受另外两个单点。我给客户做选型时基本就是按这三步走完一遍，剩下的才是谈机型和报价。

哪些业务其实不该自建：资质、号码与团队能力的三条红线

不是所有语音业务都适合自己搭。三条红线我每次都会摆到台面上。第一条是资质：语音业务、号码资源的经营许可以及外呼的合规要求，各地规定不同，需要自行向当地主管部门核实，也可以请服务商协助对接合规架构建议，但没有人能替你绕过这一步。第二条是号码与中继资源：没有稳定的中继侧对接方，自建平台只是把复杂性搬到了自己机房，成本反而不降。第三条是团队能力：平台半夜出单通、出注册风暴，有没有人能在半小时内上机抓包看日志？如果没有，托管或云呼叫中心总账更低。

还有一个技术性的判断容易被漏掉：呼叫中心与语音机器人这类业务，压力峰值往往体现在每秒新建呼叫数（CPS）而不是并发通话数。一次营销活动可能让 CPS 翻十倍，而并发只涨两倍。这时打垮信令机的是短时间的报文洪峰和 TLS 握手风暴，扩容方向完全不同——要的是 CPU 余量和会话恢复，不是更大的带宽。一万网络在这类场景上能帮的是底层：把机器的核数、内存、网卡队列和 BGP 多线接入先配到位，让上层的调优有发挥空间；至于号码与资质，仍以客户自行确认为准。

上线前必须跑完的四类压测与灰度动作

第一类是注册洪峰。问题在于真实注册行为是潮汐式的——早高峰、断网恢复、机房切换都会形成数倍于平常的 REGISTER 洪峰；为什么危险，因为每个带凭据的包都要查库加算哈希，CPU 会在几十秒内拉满而注册成功率断崖下跌；怎么判断，盯每秒 REGISTER 数与 401/403 比例的基线，压测时用 sipp 或同类工具按目标峰值的三倍灌；怎么避，把 pike 与 htable 限速在压测阶段就调到生效，usrloc 用内存模式，数据库不参与关键路径。

第二类是事务峰值。问题在于 tm 事务表容量是静态配置，超过就不再创建事务；为什么危险，因为它失败的方式是回 500 而不是变慢，业务侧看到的是"突然大面积打不通"；怎么判断，压测时观察事务相关统计的峰值与失败计数；怎么避，按峰值 CPS 乘以事务平均存活时间估算事务数，再留一倍余量，并把 shm 同步调大。

第三类是媒体面并发。问题在于媒体机的 pps 与端口段是两个独立约束；为什么危险，端口段耗尽的报错和带宽打满的表现完全不同，前者是新呼叫直接失败；怎么判断，压测时同时看网卡 pps、带宽占用和 rtpengine 的可用端口数；怎么避，按并发峰值乘四估算端口数，端口段一次性开足，别等扩容。

第四类是故障切换演练。问题在于很多高可用方案从未真正切过；为什么危险，因为切换路径上的 NAT 注册回程、位置复制延迟、dispatcher 探测收敛时间，任何一个没验证过都会在真故障时暴露；怎么判断，直接摘掉一台节点，测量注册恢复时间与在途呼叫的损失率；怎么避，把演练做成季度例行，每次都记录恢复时间并对比上次。灰度动作上，我习惯先切百分之一的注册流量观察二十四小时，再逐档放大。

Kamailio 上生产前最常被问的八个问题

问：一台机器能不能既跑 Kamailio 又跑 rtpengine？
能跑，但我不建议在生产环境这么干。同机部署的麻烦在于两者的瓶颈互相干扰：媒体转发吃网卡 pps 和软中断，一旦媒体面抖动，SIP 报文跟着延迟，事务层就开始重传，重传又进一步加重负担，形成正反馈。小规模几百路还能接受，上千路就明显吃力。真要同机，至少把 rtpengine 的进程绑到独立的核上，并且把网卡多队列与中断绑定做好。

问：一千路并发到底要多少带宽？
取决于媒体过不过这台机器。不过媒体时，一千路并发的信令流量通常只有几 Mbps，买带宽不是重点。过媒体时按编码算：G.711 二十毫秒打包在以太网层每方向约 87.2 kbps，双向一千路约 174 Mbps；G.729 每方向约 31.2 kbps，双向一千路约 62 Mbps。这是单向叠加的结果，别忘了上下行都要计。

问：REGISTER 洪泛真的会把机器打挂吗？
会，而且比多数人想的容易。关键在于带凭据的报文成本远高于空包：一次摘要认证要查一次库、算一次哈希。几千个这样的包在几秒钟内到达，CPU 就满了，表现为注册成功率断崖下跌、正常用户也连带受影响。防护分三层：pike 做速率闸门，htable 的 ipban 表做时段封禁，必要时再用 fail2ban 落到防火墙。TLS 与来源白名单能挡掉大量无关流量。

问：usrloc 该用内存还是数据库？重启会不会掉线？
注册量上规模就用内存模式（db_mode 0）或批量回写模式（db_mode 2），冗余交给 dmq_usrloc 做节点间复制，数据库只当冷备。代价是重启会丢最后一个同步周期内的注册，缩短 timer_interval（默认 60 秒）到 20 到 30 秒可以把窗口压小。write-through 模式虽然不丢数据，但注册风暴时数据库往往是第一个挂掉的组件。

问：UDP 丢包为什么表现为接续慢，而不是声音有问题？
因为丢的是控制面的报文，不是音频。SIP 的重传间隔从 T1=500ms 起步逐次翻倍，一个 INVITE 丢了要等到第二次或第三次重传才送达，用户感受到的就是按下拨号键之后干等几秒才回铃，或者干脆等来 408 超时。音频质量由 RTP 链路决定，两者是独立的路径，所以"通话中音质很好但接通很慢"是典型的信令侧丢包特征。

问：什么时候必须上 TLS？CPU 会涨多少？
公网暴露且需要保护摘要认证凭据、浏览器侧 WebRTC 走 WSS、对接方或合规要求加密信令——这三种没有商量余地。CPU 增量没有放之四海皆准的数字，它取决于握手频率而非流量：短连接频繁重连的场景涨幅明显，长连接保活好的场景几乎看不出来。所以务必开启会话恢复（RFC 5077），并把 TCP 保活时间调长。媒体侧则依赖 AES-NI，没有硬件加速的老机器跑 SRTP 会明显吃力。

问：两台 Kamailio 加 dmq 就算高可用了吗？
不算。dmq_usrloc 解决的是位置记录同步，它不同步 NAT 回程路径——客户端在 NAT 后面时，发往它的请求仍必须经回它注册的那个节点，要靠 Path 支持或 socket 信息复制配合。而且真正的单点往往在别处：共享数据库、RTP 中继、CDR 写入、dispatcher 的探测链路。把这几项逐个列出来做冗余，才谈得上高可用。

问：自建语音平台需要什么资质？
语音业务与号码资源的经营许可、外呼相关的合规要求，各地规定不同，需要自行向当地主管部门核实，也可以请服务商协助对接或提供合规架构建议。本文讨论的是合规语音业务的正常部署——企业自用呼叫中心、客服系统、语音机器人的服务端搭建。任何骚扰呼叫、号码伪造、绕过风控、批量轰炸的做法都不在本文范围内，也应当排除在你的业务之外。

数据来源

1. Kamailio 官方网站项目 History 页（kamailio.com/w/history）：SER 项目起源、2005 年 OpenSER 分叉、2008 年改名 Kamailio 与 OpenSIPS 的分立、2010 年 v3.0.0 源码树合并等时间线。

2. Kamailio Core Cookbook（kamailio.org/wiki/cookbooks）：request_route、route 子路由、branch_route、failure_route、reply_route、onreply_route、onsend_route 的执行时机与挂载方式。

3. Kamailio 官方模块文档 usrloc（5.8.x 版本）：db_mode 0 至 4 各模式语义、timer_interval、matching_mode、cseq_delay 等参数。

4. Kamailio 官方模块文档 auth_db 与 auth：HA1 定义、calculate_ha1、password_column、load_credentials 等参数说明；Kamailio 用户邮件列表 2025 年 3 月关于 SHA-256 摘要的讨论帖。

5. Kamailio 官方模块文档 dispatcher：ds_select_dst 的算法编号（0 至 9）、ds_ping_method、ds_ping_interval、ds_probing_mode、ds_probing_threshhold。

6. Kamailio 官方模块文档 dmq_usrloc（6.0.x 版本）：KDMQ 复制机制、sync、batch_size、batch_usleep、batch_msg_size、batch_msg_contacts、replicate_socket_info 等参数。

7. Kamailio 官方模块文档 nathelper（5.4.x 版本）：nat_uac_test 各 flag 含义、fix_nated_register、fix_nated_sdp、add_contact_alias、handle_ruri_alias。

8. Kamailio Wiki「Troubleshooting Memory」：pkg 与 shm 两类内存的区别，以及 4.2.0 起 pkg 默认 8MB、shm 默认 64MB 的说明。

9. Kamailio Wiki 安全配置片段页（tutorials/security/kamailio-security）：pike 模块参数示例、htable 的 ipban 表与 autoexpire 用法、fail2ban 配合方式。

10. Kamailio 用户邮件列表 2020 年 3 月「Pike Module Clarification」主题帖（Daniel-Constantin Mierla 回复）：封禁阈值落在 x 与 3x 之间的实际行为说明。

11. IETF RFC 3261 第 17 章，及 IBM WebSphere、Oracle SIP API、Cisco 等公开的 SIP 定时器汇总表：T1=500ms、T2=4s、T4=5s、Timer B/F/H=64*T1 等默认值。

12. Cisco《Voice Bandwidth Consumption Calculation》（文档 7934）及其中文版：G.711 二十毫秒打包在以太网层 87.2 kbps、G.729 31.2 kbps 的计算方法与 40 字节 IP/UDP/RTP 加 18 字节以太网开销假设。

13. SIPSymposium 的 Kamailio NAT Traversal with RTPEngine 指南、rtpproxy 官方站点：媒体中继工作方式、单通排查路径、RTP 端口范围 10000 至 20000 的常见配置。

14. SIP ALG 相关的厂商与运维公开资料（Netgate pfSense 论坛、Fortinet 管理指南、UniFi 连接跟踪设置说明等）：关闭 SIP ALG、静态端口出站 NAT、UDP 状态超时的处置建议。

15. OpenSIPS 官方模块文档 auth_db：RFC 8760 对应的 ha1_sha256、ha1_sha512t256 列定义；Kamailio 侧对 SHA-256 摘要的支持情况随版本不同，公开资料口径不一，以所用版本的官方文档为准。

16. 一万网络官网（idc10000.net）公开的机型与地区起步价信息，具体配置、带宽与报价以官网实时信息或咨询确认为准。