我来帮你搞定这个需求——你需要SIP话机拨打000-000-0000时，既要触发对0000的呼叫，又得保证AMI事件监听器能捕获到完整的呼叫发起、接听全流程，对吧？之前直接用Answer()在主叫端的方式会跳过呼叫发起环节，确实不符合要求，咱们调整下拨号计划就行：

; 处理主叫拨打000-000-0000的请求，发起对0000的呼叫
exten => _0000000000,1,Dial(SIP/0000,20)  ; 这里替换成你实际的通道类型（比如SIP/0000），超时设20秒
same => n,NoOp(Call to 0000 finished with status: ${DIALSTATUS})  ; 记录呼叫结果，方便排查问题

; 处理0000的接听逻辑
exten => _0000,1,Answer()
same => n,NoOp('0000 has answered')
; 这里添加你需要的后续操作，比如播放音频、转接、执行AGI脚本都可以
same => n,Playback(welcome)  ; 示例：播放欢迎音频
same => n,Hangup()

几个关键点要注意： #

• 为啥不能直接在_0000000000里用Answer()？
  直接在主叫触发的拨号计划里调用Answer()会立刻接听主叫，相当于跳过了向0000发起呼叫的完整流程，AMI监听器自然抓不到NewChannel、DialBegin这类呼叫发起的关键事件。而Dial()命令会完整触发从呼叫发起、振铃到接听的全流程事件，刚好适配你的AMI监听需求。

• Dial()命令的细节
  一定要确保Dial()的目标通道是对的（比如你的0000是SIP话机就写SIP/0000，如果是IAX2就改IAX2/0000），第二个参数是超时时间，超时后主叫会收到忙音或者进入后续逻辑。${DIALSTATUS}变量能拿到呼叫的最终状态（比如ANSWERED、BUSY、NOANSWER），用来打日志或者做后续处理都很方便。

• 接听后的自定义逻辑不受影响
  在_0000的上下文里，Answer()之后你该加什么操作就加什么，播放音频、转接、执行脚本都没问题，完全不会破坏呼叫发起和接听的完整流程。

这样调整后，当SIP话机拨打000-000-0000时，Asterisk会正常向0000发起呼叫，0000接听后触发你要的后续逻辑，同时AMI监听器能捕获到从呼叫发起、振铃到接听的所有关键事件，完美满足你的需求。

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