的迁移与用法)
去年我接手一个从OpenSER时代一路迁过来的 Kamailio 路由脚本打开配置文件第一眼就愣住了满屏都是to.uri.host、from.uri.host这类以 开头的写法。新版 Kamailio 虽然还认一部分这种旧式 select但官方文档的主推写法已经变成了$sel()而且随着模块迭代旧写法在升级后经常出现“值取不到”的诡异问题。那段时间我一边改脚本一边查手册最后把 Kamailio 的 select 框架从头到尾理了一遍才发现这套东西比我想象中有用得多也坑得多。这篇内容就是我当时梳理和实测的记录。如果你正在维护老 SIP 路由脚本或者想在 Kamailio 配置里更规范地读取 SIP 消息内部字段这篇文章应该能帮你省下不少翻文档的时间。我会从 select 框架要解决的问题讲起再给一份可以直接抄作业的中继分流配置最后聊聊几个我差点被绕进去的坑。1. 从一段老旧路由脚本说起select 框架究竟解决了什么问题Kamailio 本身是 C 语言写的 SIP 服务器它的核心能力是把 SIP 请求解析成内存里的结构化数据。但配置脚本要访问这些内部数据时不能直接用 C 结构体只能通过伪变量、函数、字符串变换这类“脚本层接口”。select 框架就是其中一种接口而且是非常特殊的一种。1.1 老式 select 与当前的主流写法在 OpenSER 时代开发者设计了一套以开头的 select 语法用来直接点取 SIP 消息里的字段。比如to.uri.host表示“从 To 头的 URI 里取出主机名部分”。这种语法在当年确实好用SIP 消息里的 Request-URI、From/To 头、Contact 头、消息体等都能用类似点路径的方式访问。但后来 Kamailio 逐步把脚本层的伪变量体系统一到$前缀select 也有了新的外壳$sel(selector)。比如$sel(uri.host)就是取当前请求 URI 的主机名功能和旧写法里的ru.host这类用法一脉相承但整体语法更统一也能直接嵌入字符串、参与、~这类比较运算。我见过不少从 OpenSER 迁过来的配置还在用老式写法。不是说完全跑不了而是维护起来很别扭文档里大量示例都换成了$sel()社区回答也默认新语法老配置一旦遇到模块版本差异很难判断到底是 select 本身失效还是写法不兼容。所以我的建议很直接碰到老脚本尽早统一改成$sel()或对应的伪变量。1.2 为什么不能只靠伪变量可能你会问Kamailio 不是有$ru、$rd、$hdr()这些伪变量吗为什么还需要 select伪变量的确能覆盖 80% 的场景但它有几个短板。第一伪变量大多是“整块”读取比如$ru是整个 Request-URI 字符串如果你只想取其中的 user 部分或 host 部分就得配合字符串变换或者正则去抠。第二伪变量的可写性很强这是优点也是负担因为有些场景你只是想做一次只读判断并不希望脚本里有任何副作用。第三SIP 消息里的一些嵌套字段例如 URI 参数、消息体、某个头字段的内部结构用普通伪变量表达起来要么很绕要么根本找不到对应变量。select 框架的定位就是解决这些问题的它提供一组“只读”的字段路径把消息解析结果按需暴露出来。调用时你只需要写清楚路径框架负责定位到具体的struct sip_msg子结构把结果作为字符串返回。这个设计思路有点像把 SIP 消息当成一棵树select 就是在树上按路径摘叶子。2. 新框架怎么工作$sel()调用方式与常用 selector搞清楚设计动机之后就得看具体怎么用。Kamailio 的 select 框架在配置脚本里统一通过$sel()这个伪变量来执行括号里填的是 selector 的 id。id 用点号分层比如uri.user表示“Request-URI 的 user 字段”msg.body表示“整个消息体”。2.1 基础语法与求值规律最简单的用法就是在if条件里直接比较if ($sel(uri.host) pbx.example.net) { # 命中目标主机 }这里$sel(uri.host)会在运行时对当前 SIP 消息执行求值返回一个字符串。取不到有效值时返回空很多情况下你可以用 $null来判断是否存在。除了直接比较也可以把 select 的结果先存到变量里再做后续逻辑。我个人更推荐这种用法原因后面会讲主要是性能和可读性的平衡$var(ru_user) $sel(uri.user); $var(ru_host) $sel(uri.host); xlog(L_INFO, user[$var(ru_user)] host[$var(ru_host)]\n);每次执行$sel()都会重新从当前消息解析结构里取一次值不是全局缓存的。所以同一个消息在路由过程中调用多次结果是一致的但开销会累积。如果你在几个地方都要用同一个字段最好先赋值给$var再复用。2.2 核心 selector 速查Kamailio 核心提供的 select id 不算多但都很常用。下面这几个是我在路由脚本里高频使用的selector作用典型返回uri请求 URI 整体sip:881234client-a.example.neturi.user请求 URI 中的用户部分881234uri.host请求 URI 中的主机部分client-a.example.neturi.port请求 URI 中的端口没有则为空5060或空uri.params请求 URI 中的参数部分transportudpmsg.bodySIP 消息的消息体原始字符串v0\r\n...举个例子如果收到一个 INVITE请求行是INVITE sip:881234client-a.example.net;transportudp SIP/2.0那么$sel(uri.user)返回881234$sel(uri.host)返回client-a.example.net$sel(uri.params)返回;transportudp或transportudp具体格式在不同版本里可能略有差异这几个 selector 的价值在于你不需要自己写正则去拆$ru字符串框架已经帮你拆好了。尤其是带参数的 URI用正则抠参数很容易踩边界条件select 直接给字段就清爽很多。2.3 模块也可以注册自己的 selector“框架”这两个字是有实际含义的。Kamailio 核心只实现了一部分 select id其它模块可以在初始化时往 select 注册表里挂自己的函数。这样配置脚本就能用统一的$sel()语法访问模块内部解析出来的扩展数据。这意味着你在一个发行版里看到的 select id换到另一个精简编译版本可能就没有了。所以遇到不认识的 selector第一反应应该是去查对应模块的文档而不是怀疑语法写错。特别提醒一句select 的 id 并不是越多越好核心模块提供的 id 在所有版本里相对稳定第三方模块的 id 则可能随版本变化升级时尤其要注意。3. 完整实例按 URI 字段做双中继分流理论讲再多不如一份能跑起来的配置。下面这个例子是我在实际项目中简化出来的场景用来演示 select 框架在路由决策里的完整使用链路。3.1 需求拆解假设你是企业 SIP 中继网关有两个客户域通过你的网关对外呼叫客户域用户号段出局中继client-a.example.net以88开头10.10.1.20:5060client-b.example.net以99开头10.10.2.20:5060其它来源的 INVITE 一律拒绝。这个需求的关键点就是“从 Request-URI 里拆出 host 和 user再做两级匹配”。用 select 来做是再合适不过的。3.2 可运行的 cfg 片段下面是一段精简但完整的路由逻辑依赖tm和sl两个模块request_route { # 非 INVITE 直接走默认中继 if ($rm ! INVITE) { route(RELAY); exit; } # 用 select 把关键字段一次性取出来 $var(ru_user) $sel(uri.user); $var(ru_host) $sel(uri.host); $var(ru_params) $sel(uri.params); xlog(L_INFO, select: user[$var(ru_user)] host[$var(ru_host)] params[$var(ru_params)]\n); # 按客户域和号段分流 if ($var(ru_host) client-a.example.net) { if ($var(ru_user) ~ ^88) { route(TO_TRUNK_A); exit; } } else if ($var(ru_host) client-b.example.net) { if ($var(ru_user) ~ ^99) { route(TO_TRUNK_B); exit; } } sl_send_reply(404, Not Found); exit; } route[TO_TRUNK_A] { $du sip:10.10.1.20:5060; route(RELAY); exit; } route[TO_TRUNK_B] { $du sip:10.10.2.20:5060; route(RELAY); exit; } route[RELAY] { if (!t_relay()) { sl_reply_error(); } exit; }这段配置的核心在于先用$sel(uri.user)、$sel(uri.host)、$sel(uri.params)把字段抽出来后面所有判断都基于变量脚本逻辑一下子清晰了很多。如果你用的是比较老的 Kamailio 分支sl_send_reply可能叫send_reply看一眼模块文档就知道。3.3 怎么验证 select 真的取对了值配置写完先别急着上线第一步先做语法检查kamailio -c语法检查只能保证格式没错不能保证 select 取到了你期望的值。我习惯的做法是先启动 Kamailio然后用nc发一个 UDP 的 INVITE 测试消息看日志里 xlog 的输出。测试消息长这样INVITE sip:881234client-a.example.net;transportudp SIP/2.0 Via: SIP/2.0/UDP 192.168.1.10:5060;branchz9hG4bK-test1 Max-Forwards: 70 From: sip:1001192.168.1.10;tag1001 To: sip:881234client-a.example.net Call-ID: test-select-001 CSeq: 1 INVITE Contact: sip:1001192.168.1.10 Content-Length: 0保存成文件后用nc发过去nc -u 127.0.0.1 5060 test_invite.txt正常的话Kamailio 日志里会打出这样一行select: user[881234] host[client-a.example.net] params[;transportudp]如果 host 或 user 取出来是空的说明你的 selector 在当前版本里不存在或者消息本身格式有问题。这一步能帮你把“select 用错了”和“路由逻辑错了”快速区分开。4. 别把 select 当万能钥匙与伪变量、字符串变换、模块化解析的取舍select 框架好用但它不是万能的。我在项目里经常看到有人把所有字段提取都堆到 select 上结果代码既啰嗦又不好维护。说到底select 只是工具之一选型要看场景。4.1 select 与普通伪变量的对比先看一张对比表维度select$sel()普通伪变量$ru、$rd、$hdr()等读写性只读大多可读可写表达力点号路径清晰适合拆字段短但整块读取时需二次处理典型场景从 URI/消息体中提取子串做判断快速读取、修改路由目标版本差异第三方模块 id 可能变化核心伪变量相对稳定调试方式可直接赋给变量打印同样可打印这里面最容易被忽视的是“可写性”的差异。select 是只读的它只是从消息结构里取字符串给你看不能改。如果你想把请求 URI 的 host 改成新的值正确做法是用$rd这类可写伪变量# 错误示范select 不能赋值 $sel(uri.host) new.example.net; # 正确做法需要改 host 时用可写伪变量 $rd new.example.net;虽然这个例子很基础但我在代码评审里见过不止一次有人想“省一步”直接对 select 赋值结果配置加载失败。4.2 select、字符串变换与正则怎么分工Kamailio 的字符串变换可以做到类似 select 的提取效果比如对$ru做各种变换取出部分字段。但我的原则是能靠字段路径说清楚的事就不要引入变换链。变换适合在原有值的基础上做格式化比如把 user 部分取出来后去掉前缀、或把某个伪变量做大小写转换而 select 的定位更偏“结构化读取”。正则也是一样。用~直接从$sel(uri.params)里判断是否包含transportudp是没问题的if ($sel(uri.params) ~ transportudp) { # UDP 传输 }但如果整个路由逻辑里全是正则去抠 URI 字段代码的可读性会很差出问题后也不好查。select 的价值就在于此把字段边界交给框架而不是交给你自己写的正则表达式。4.3 复杂结构数据要交给专业模块select 框架能拿到msg.body但拿到的是原始字符串。如果 body 是 SDP、JSON、XML 这类有复杂结构的数据我不建议用 select 加正则去解析。SDP 内容判断用sdpops模块的相关函数JSON 解析用json或jansson模块数据库查询结果有专门的变换和函数。简单说select 的边界在“SIP 消息的原始字段”而不是“字段内容的深加工”。你可以在调试阶段用 select 快速看一眼 body 里有没有某个关键字生产环境里涉及到媒体协商、数据提取还是要走专业模块。5. 用 select 框架时踩过的几个隐蔽坑这部分是我最想写的。select 框架本身不复杂但实际使用中有一堆“文档里没有但线上会炸”的细节。5.1 selector 拼错了启动不报错运行时静默返回空这个坑我印象最深。当时我写了一个$sel(uri.hostname)去判断主机名kamailio -c语法检查通过了但路由就是不命中。查了半天才发现selector id 是注册表驱动的未知 id 在运行时不会直接报错而是求值成空字符串。if ($sel(uri.hostname) example.net)永远为假。排查方法其实很简单把 select 结果打出来看。$var(dbg) $sel(uri.hostname); xlog(L_INFO, debug select: [$var(dbg)]\n);日志里如果打出空括号基本可以确定 selector id 不对。所以拿到陌生配置时不要盲目信任里面写的 id先去当前版本的文档里核对一遍模块提供的 select 列表。5.2 大字段反复取性能容易出问题msg.body这种字段可能很大一个带 SDP 的 INVITE body 动辄几百上千字节。如果你在路由脚本里重复写$sel(msg.body)每次执行都是重新走一遍查找和字符串返回相当于同一份大字符串被反复翻出来。Kamailio 的路由脚本本身不适合做重逻辑这种浪费更不值得。我的习惯是如果一个字段要在多处使用第一时间赋值给$var后面都用变量$var(body) $sel(msg.body); if ($var(body) ! $null) { # 业务判断 }这样既保证结果一致也避免重复求值。尤其是处理 body 这种大字段时缓存变量的好处立竿见影。5.3 只读语义引发的心态崩溃select 是只读的这从设计上是优点但很多人一开始不知道。有位同事迁脚本时想当然地写了类似$sel(uri.host) xxx的代码想着“既然能读到应该也能写回去”结果配置反复加载不过还以为是语法问题。最后改成用$rd赋值才解决。这点值得反复强调select 只负责“读”和“判断”需要“改”的时候换伪变量需要“深层解析”的时候换模块函数。把工具边界理清楚脚本维护成本会低很多。5.4 老脚本迁移别搞“一刀切”从旧写法迁移到$sel()或伪变量时最忌讳一次性全局替换。旧写法里有些 selector 在新版里语义可能有细微差别比如对畸形 URI 的处理、对空值的返回方式。我建议分两步走第一步先加日志把每个旧 select 的真实值和预期值打印出来确认当前版本解析结果是什么。第二步逐行替换并回归测试。举个例子旧写法里to.uri.host这种含义在新配置里我会优先用$tH这类专门的伪变量而不是硬套$sel()。伪变量更短语义也更明确。老脚本迁移的完整流程不适合在一篇文章里铺开但记住一个原则先看清真实求值结果再动手改代码。离开日志做重构跟蒙眼开车差不多。最后再分享一个习惯我现在写 Kamailio 路由脚本时凡是涉及 Request-URI、From/To 头、消息体这类“结构化字段提取”第一反应就是用 select 把字段抽出来交给$var再走后续分支凡是涉及修改消息目标立刻切回可写伪变量。这样做了一段时间之后脚本里几乎见不到大段正则抠字段的代码了排障时每条 xlog 都能直接看出 select 取到了什么思路清楚很多。
去年我接手一个从OpenSER时代一路迁过来的 Kamailio 路由脚本打开配置文件第一眼就愣住了满屏都是to.uri.host、from.uri.host这类以 开头的写法。新版 Kamailio 虽然还认一部分这种旧式 select但官方文档的主推写法已经变成了$sel()而且随着模块迭代旧写法在升级后经常出现“值取不到”的诡异问题。那段时间我一边改脚本一边查手册最后把 Kamailio 的 select 框架从头到尾理了一遍才发现这套东西比我想象中有用得多也坑得多。这篇内容就是我当时梳理和实测的记录。如果你正在维护老 SIP 路由脚本或者想在 Kamailio 配置里更规范地读取 SIP 消息内部字段这篇文章应该能帮你省下不少翻文档的时间。我会从 select 框架要解决的问题讲起再给一份可以直接抄作业的中继分流配置最后聊聊几个我差点被绕进去的坑。1. 从一段老旧路由脚本说起select 框架究竟解决了什么问题Kamailio 本身是 C 语言写的 SIP 服务器它的核心能力是把 SIP 请求解析成内存里的结构化数据。但配置脚本要访问这些内部数据时不能直接用 C 结构体只能通过伪变量、函数、字符串变换这类“脚本层接口”。select 框架就是其中一种接口而且是非常特殊的一种。1.1 老式 select 与当前的主流写法在 OpenSER 时代开发者设计了一套以开头的 select 语法用来直接点取 SIP 消息里的字段。比如to.uri.host表示“从 To 头的 URI 里取出主机名部分”。这种语法在当年确实好用SIP 消息里的 Request-URI、From/To 头、Contact 头、消息体等都能用类似点路径的方式访问。但后来 Kamailio 逐步把脚本层的伪变量体系统一到$前缀select 也有了新的外壳$sel(selector)。比如$sel(uri.host)就是取当前请求 URI 的主机名功能和旧写法里的ru.host这类用法一脉相承但整体语法更统一也能直接嵌入字符串、参与、~这类比较运算。我见过不少从 OpenSER 迁过来的配置还在用老式写法。不是说完全跑不了而是维护起来很别扭文档里大量示例都换成了$sel()社区回答也默认新语法老配置一旦遇到模块版本差异很难判断到底是 select 本身失效还是写法不兼容。所以我的建议很直接碰到老脚本尽早统一改成$sel()或对应的伪变量。1.2 为什么不能只靠伪变量可能你会问Kamailio 不是有$ru、$rd、$hdr()这些伪变量吗为什么还需要 select伪变量的确能覆盖 80% 的场景但它有几个短板。第一伪变量大多是“整块”读取比如$ru是整个 Request-URI 字符串如果你只想取其中的 user 部分或 host 部分就得配合字符串变换或者正则去抠。第二伪变量的可写性很强这是优点也是负担因为有些场景你只是想做一次只读判断并不希望脚本里有任何副作用。第三SIP 消息里的一些嵌套字段例如 URI 参数、消息体、某个头字段的内部结构用普通伪变量表达起来要么很绕要么根本找不到对应变量。select 框架的定位就是解决这些问题的它提供一组“只读”的字段路径把消息解析结果按需暴露出来。调用时你只需要写清楚路径框架负责定位到具体的struct sip_msg子结构把结果作为字符串返回。这个设计思路有点像把 SIP 消息当成一棵树select 就是在树上按路径摘叶子。2. 新框架怎么工作$sel()调用方式与常用 selector搞清楚设计动机之后就得看具体怎么用。Kamailio 的 select 框架在配置脚本里统一通过$sel()这个伪变量来执行括号里填的是 selector 的 id。id 用点号分层比如uri.user表示“Request-URI 的 user 字段”msg.body表示“整个消息体”。2.1 基础语法与求值规律最简单的用法就是在if条件里直接比较if ($sel(uri.host) pbx.example.net) { # 命中目标主机 }这里$sel(uri.host)会在运行时对当前 SIP 消息执行求值返回一个字符串。取不到有效值时返回空很多情况下你可以用 $null来判断是否存在。除了直接比较也可以把 select 的结果先存到变量里再做后续逻辑。我个人更推荐这种用法原因后面会讲主要是性能和可读性的平衡$var(ru_user) $sel(uri.user); $var(ru_host) $sel(uri.host); xlog(L_INFO, user[$var(ru_user)] host[$var(ru_host)]\n);每次执行$sel()都会重新从当前消息解析结构里取一次值不是全局缓存的。所以同一个消息在路由过程中调用多次结果是一致的但开销会累积。如果你在几个地方都要用同一个字段最好先赋值给$var再复用。2.2 核心 selector 速查Kamailio 核心提供的 select id 不算多但都很常用。下面这几个是我在路由脚本里高频使用的selector作用典型返回uri请求 URI 整体sip:881234client-a.example.neturi.user请求 URI 中的用户部分881234uri.host请求 URI 中的主机部分client-a.example.neturi.port请求 URI 中的端口没有则为空5060或空uri.params请求 URI 中的参数部分transportudpmsg.bodySIP 消息的消息体原始字符串v0\r\n...举个例子如果收到一个 INVITE请求行是INVITE sip:881234client-a.example.net;transportudp SIP/2.0那么$sel(uri.user)返回881234$sel(uri.host)返回client-a.example.net$sel(uri.params)返回;transportudp或transportudp具体格式在不同版本里可能略有差异这几个 selector 的价值在于你不需要自己写正则去拆$ru字符串框架已经帮你拆好了。尤其是带参数的 URI用正则抠参数很容易踩边界条件select 直接给字段就清爽很多。2.3 模块也可以注册自己的 selector“框架”这两个字是有实际含义的。Kamailio 核心只实现了一部分 select id其它模块可以在初始化时往 select 注册表里挂自己的函数。这样配置脚本就能用统一的$sel()语法访问模块内部解析出来的扩展数据。这意味着你在一个发行版里看到的 select id换到另一个精简编译版本可能就没有了。所以遇到不认识的 selector第一反应应该是去查对应模块的文档而不是怀疑语法写错。特别提醒一句select 的 id 并不是越多越好核心模块提供的 id 在所有版本里相对稳定第三方模块的 id 则可能随版本变化升级时尤其要注意。3. 完整实例按 URI 字段做双中继分流理论讲再多不如一份能跑起来的配置。下面这个例子是我在实际项目中简化出来的场景用来演示 select 框架在路由决策里的完整使用链路。3.1 需求拆解假设你是企业 SIP 中继网关有两个客户域通过你的网关对外呼叫客户域用户号段出局中继client-a.example.net以88开头10.10.1.20:5060client-b.example.net以99开头10.10.2.20:5060其它来源的 INVITE 一律拒绝。这个需求的关键点就是“从 Request-URI 里拆出 host 和 user再做两级匹配”。用 select 来做是再合适不过的。3.2 可运行的 cfg 片段下面是一段精简但完整的路由逻辑依赖tm和sl两个模块request_route { # 非 INVITE 直接走默认中继 if ($rm ! INVITE) { route(RELAY); exit; } # 用 select 把关键字段一次性取出来 $var(ru_user) $sel(uri.user); $var(ru_host) $sel(uri.host); $var(ru_params) $sel(uri.params); xlog(L_INFO, select: user[$var(ru_user)] host[$var(ru_host)] params[$var(ru_params)]\n); # 按客户域和号段分流 if ($var(ru_host) client-a.example.net) { if ($var(ru_user) ~ ^88) { route(TO_TRUNK_A); exit; } } else if ($var(ru_host) client-b.example.net) { if ($var(ru_user) ~ ^99) { route(TO_TRUNK_B); exit; } } sl_send_reply(404, Not Found); exit; } route[TO_TRUNK_A] { $du sip:10.10.1.20:5060; route(RELAY); exit; } route[TO_TRUNK_B] { $du sip:10.10.2.20:5060; route(RELAY); exit; } route[RELAY] { if (!t_relay()) { sl_reply_error(); } exit; }这段配置的核心在于先用$sel(uri.user)、$sel(uri.host)、$sel(uri.params)把字段抽出来后面所有判断都基于变量脚本逻辑一下子清晰了很多。如果你用的是比较老的 Kamailio 分支sl_send_reply可能叫send_reply看一眼模块文档就知道。3.3 怎么验证 select 真的取对了值配置写完先别急着上线第一步先做语法检查kamailio -c语法检查只能保证格式没错不能保证 select 取到了你期望的值。我习惯的做法是先启动 Kamailio然后用nc发一个 UDP 的 INVITE 测试消息看日志里 xlog 的输出。测试消息长这样INVITE sip:881234client-a.example.net;transportudp SIP/2.0 Via: SIP/2.0/UDP 192.168.1.10:5060;branchz9hG4bK-test1 Max-Forwards: 70 From: sip:1001192.168.1.10;tag1001 To: sip:881234client-a.example.net Call-ID: test-select-001 CSeq: 1 INVITE Contact: sip:1001192.168.1.10 Content-Length: 0保存成文件后用nc发过去nc -u 127.0.0.1 5060 test_invite.txt正常的话Kamailio 日志里会打出这样一行select: user[881234] host[client-a.example.net] params[;transportudp]如果 host 或 user 取出来是空的说明你的 selector 在当前版本里不存在或者消息本身格式有问题。这一步能帮你把“select 用错了”和“路由逻辑错了”快速区分开。4. 别把 select 当万能钥匙与伪变量、字符串变换、模块化解析的取舍select 框架好用但它不是万能的。我在项目里经常看到有人把所有字段提取都堆到 select 上结果代码既啰嗦又不好维护。说到底select 只是工具之一选型要看场景。4.1 select 与普通伪变量的对比先看一张对比表维度select$sel()普通伪变量$ru、$rd、$hdr()等读写性只读大多可读可写表达力点号路径清晰适合拆字段短但整块读取时需二次处理典型场景从 URI/消息体中提取子串做判断快速读取、修改路由目标版本差异第三方模块 id 可能变化核心伪变量相对稳定调试方式可直接赋给变量打印同样可打印这里面最容易被忽视的是“可写性”的差异。select 是只读的它只是从消息结构里取字符串给你看不能改。如果你想把请求 URI 的 host 改成新的值正确做法是用$rd这类可写伪变量# 错误示范select 不能赋值 $sel(uri.host) new.example.net; # 正确做法需要改 host 时用可写伪变量 $rd new.example.net;虽然这个例子很基础但我在代码评审里见过不止一次有人想“省一步”直接对 select 赋值结果配置加载失败。4.2 select、字符串变换与正则怎么分工Kamailio 的字符串变换可以做到类似 select 的提取效果比如对$ru做各种变换取出部分字段。但我的原则是能靠字段路径说清楚的事就不要引入变换链。变换适合在原有值的基础上做格式化比如把 user 部分取出来后去掉前缀、或把某个伪变量做大小写转换而 select 的定位更偏“结构化读取”。正则也是一样。用~直接从$sel(uri.params)里判断是否包含transportudp是没问题的if ($sel(uri.params) ~ transportudp) { # UDP 传输 }但如果整个路由逻辑里全是正则去抠 URI 字段代码的可读性会很差出问题后也不好查。select 的价值就在于此把字段边界交给框架而不是交给你自己写的正则表达式。4.3 复杂结构数据要交给专业模块select 框架能拿到msg.body但拿到的是原始字符串。如果 body 是 SDP、JSON、XML 这类有复杂结构的数据我不建议用 select 加正则去解析。SDP 内容判断用sdpops模块的相关函数JSON 解析用json或jansson模块数据库查询结果有专门的变换和函数。简单说select 的边界在“SIP 消息的原始字段”而不是“字段内容的深加工”。你可以在调试阶段用 select 快速看一眼 body 里有没有某个关键字生产环境里涉及到媒体协商、数据提取还是要走专业模块。5. 用 select 框架时踩过的几个隐蔽坑这部分是我最想写的。select 框架本身不复杂但实际使用中有一堆“文档里没有但线上会炸”的细节。5.1 selector 拼错了启动不报错运行时静默返回空这个坑我印象最深。当时我写了一个$sel(uri.hostname)去判断主机名kamailio -c语法检查通过了但路由就是不命中。查了半天才发现selector id 是注册表驱动的未知 id 在运行时不会直接报错而是求值成空字符串。if ($sel(uri.hostname) example.net)永远为假。排查方法其实很简单把 select 结果打出来看。$var(dbg) $sel(uri.hostname); xlog(L_INFO, debug select: [$var(dbg)]\n);日志里如果打出空括号基本可以确定 selector id 不对。所以拿到陌生配置时不要盲目信任里面写的 id先去当前版本的文档里核对一遍模块提供的 select 列表。5.2 大字段反复取性能容易出问题msg.body这种字段可能很大一个带 SDP 的 INVITE body 动辄几百上千字节。如果你在路由脚本里重复写$sel(msg.body)每次执行都是重新走一遍查找和字符串返回相当于同一份大字符串被反复翻出来。Kamailio 的路由脚本本身不适合做重逻辑这种浪费更不值得。我的习惯是如果一个字段要在多处使用第一时间赋值给$var后面都用变量$var(body) $sel(msg.body); if ($var(body) ! $null) { # 业务判断 }这样既保证结果一致也避免重复求值。尤其是处理 body 这种大字段时缓存变量的好处立竿见影。5.3 只读语义引发的心态崩溃select 是只读的这从设计上是优点但很多人一开始不知道。有位同事迁脚本时想当然地写了类似$sel(uri.host) xxx的代码想着“既然能读到应该也能写回去”结果配置反复加载不过还以为是语法问题。最后改成用$rd赋值才解决。这点值得反复强调select 只负责“读”和“判断”需要“改”的时候换伪变量需要“深层解析”的时候换模块函数。把工具边界理清楚脚本维护成本会低很多。5.4 老脚本迁移别搞“一刀切”从旧写法迁移到$sel()或伪变量时最忌讳一次性全局替换。旧写法里有些 selector 在新版里语义可能有细微差别比如对畸形 URI 的处理、对空值的返回方式。我建议分两步走第一步先加日志把每个旧 select 的真实值和预期值打印出来确认当前版本解析结果是什么。第二步逐行替换并回归测试。举个例子旧写法里to.uri.host这种含义在新配置里我会优先用$tH这类专门的伪变量而不是硬套$sel()。伪变量更短语义也更明确。老脚本迁移的完整流程不适合在一篇文章里铺开但记住一个原则先看清真实求值结果再动手改代码。离开日志做重构跟蒙眼开车差不多。最后再分享一个习惯我现在写 Kamailio 路由脚本时凡是涉及 Request-URI、From/To 头、消息体这类“结构化字段提取”第一反应就是用 select 把字段抽出来交给$var再走后续分支凡是涉及修改消息目标立刻切回可写伪变量。这样做了一段时间之后脚本里几乎见不到大段正则抠字段的代码了排障时每条 xlog 都能直接看出 select 取到了什么思路清楚很多。
