Asterisk中Answer()后调用Transfer()失败，请求技术支持

你的问题我懂了 #

你现在做的是SIP重定向服务器，需求是必须先接听呼叫、等用户输入DTMF后再用Transfer()转接。但直接调用Transfer()完全正常，一旦先执行Answer()再转接，CLI就会抛出错误：

[2018-01-22 07:31:56] NOTICE[32021]: chan_sip.c:20716 handle_response_refer: SIP transfer to sip:1120@xxx.xxx.xxx.xxx failed, REFER not allowed.
-- Auto fallthrough, channel 'SIP/1313001-000e0e7c' status is 'UNKNOWN'

为啥会出这问题？ #

核心差异在于呼叫状态的不同：

• 未接听时，Transfer()本质是发送SIP重定向（3xx响应），这完全符合重定向服务器的工作逻辑，所以能正常执行；
• 但呼叫被Answer()接通后，Asterisk默认会改用SIP REFER方法发起转接——这是针对已建立通话的转接方式，可你的目标SIP端点或Asterisk配置不支持这个操作，就触发了报错。

两种解决办法，按需选择 #

1. 强制Transfer用重定向模式（最推荐，贴合你的场景）

Transfer()函数支持指定转接模式，只要添加redirect参数，就能让Asterisk不管呼叫是否已接听，都沿用重定向的方式完成转接，和你之前正常工作的逻辑完全一致。

修改后的Dialplan代码如下：

exten => s,1,Answer()
; 这里放置你的DTMF读取逻辑，比如Read()或WaitExten()
exten => s,n,Transfer(SIP/1120@xxx.xxx.xxx.xxx,,redirect)

注意第三个参数填redirect即可，修改完成后执行dialplan reload重新加载配置，再测试呼叫流程就能解决问题。

2. 配置支持SIP REFER（如果一定要用这种转接方式）

如果你确实需要使用REFER方式转接，得检查两端的配置：

• 查看Asterisk的sip.conf，确保你的SIP peer/用户配置中allowtransfer=yes（默认是开启状态，但可以确认下未被修改）；
• 检查目标SIP设备/服务器是否开启了接受REFER请求的选项——不少设备默认禁用该功能，需要手动开启；
• 若使用Asterisk 13及以上版本，还可以检查chan_sip的refercallid等参数是否配置正确。

最后提个小建议 #

优先尝试第一种方案，不需要修改对方设备配置，完全贴合你作为重定向服务器的需求，能最快解决问题。

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