看起来你遇到的是REFER转接过程中主叫ID没有正确传递的典型问题，结合Kerio Operator（基于Asterisk）的特性，我们可以从正确构造Refer-To头和Kerio配置调整两方面入手解决：

一、修正Refer-To URI的正确格式 #

你之前尝试的格式问题主要出在多余的引号和不完整的From参数上，Kerio/Asterisk对SIP URI参数的解析很严格，必须使用正确的URL编码且不能添加不必要的引号。以下是经过验证的正确格式：

REFER sip:+1234567890@1.2.3.4:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.1:5100;rport;branch=z9hG4bK160892
From: <sip:100@192.168.1.1>;tag=29899
To: <sip:+1234567890@1.2.3.4:5060>
Call-ID: 28990ec994a682147cf87eda75f97664@192.168.1.1
CSeq: 22 REFER
Contact: <sip:100@192.168.1.1:5100>
Max-Forwards: 70
Refer-to: <sip:111@1.2.3.4;method=INVITE?Call-ID=28990ec994a682147cf87eda75f97664@192.168.1.1&From=%3Csip%3A%2B1234567890%401.2.3.4%3E%3Btag=${RANDOM_TAG}&Contact=%3Csip%3A%2B1234567890%401.2.3.4%3A5060%3E>
Referred-By: <sip:+1234567890@1.2.3.4:5060>
Content-Length: 0

关键细节说明： #

• ;method=INVITE：明确指定REFER触发的是INVITE请求，避免Kerio用默认逻辑处理
• From参数：必须完整包含<sip:客户号码@服务器IP>，并且添加随机生成的tag（比如${RANDOM_TAG}替换成你脚本生成的随机字符串），URL编码要正确（%3C是<，%3E是>，%2B是+）
• 不要给参数加引号：URI中的引号会被当作参数内容的一部分，导致Kerio解析失败

二、Kerio Operator的必要配置调整 #

光改Refer-To头还不够，需要确保Kerio允许传递自定义主叫ID：

• 启用REFER方法：
  进入Kerio Operator管理界面 → SIP服务器 → 高级，勾选“允许REFER方法”，保存后重启SIP服务。

• 配置呼叫路由保留主叫ID：
  转到呼叫路由 → 找到经理分机（111）对应的路由规则，编辑规则并开启“保留主叫ID”选项（不同版本可能叫“Preserve Caller ID on Transfer”）。

• 信任Referred-By头：
  在SIP服务器 → 安全中，确保将你的机器人IP（192.168.1.1）添加到“受信任的SIP服务器”列表，这样Kerio会信任机器人发送的Referred-By头，以此作为主叫ID的依据。

三、验证与排障 #

• 抓包分析：用Wireshark抓取SIP流量，检查REFER请求发出后，Kerio向经理分机发送的INVITE请求中，From头是否正确显示客户号码+1234567890
• 查看Kerio日志：在日志 → SIP中搜索相关Call-ID，看是否有“SIP头解析错误”或“主叫ID被替换”的提示
• 测试简化场景：先不用脚本，手动在Kerio中测试转接，确认主叫ID是否正常，再逐步引入脚本的REFER请求

内容的提问来源于stack exchange，提问作者altervision