Allows one channel to bridge itself to the a or b leg of another call. The remaining leg of the original call gets hungup (or does this only happen with hangup_after_bridge?)
intercept [-bleg] <uuid>
<action application="intercept" data="myUUID"/>
To intercept the b leg of the call:
<action application="intercept" data="-bleg myUUID"/>
Via sendmsg on the event socket:
sendmsg <the uuid of the channel you want to control (inbound leg) > call-command: execute execute-app-name: intercept execute-app-arg: <the uuid of the call you want to bridge to (outbound leg)
To intercept only if the call is not bridged (available since git-58fe45a):
<action application="set" data="intercept_unbridged_only=true"/> <action application="intercept" data="myUUID"/>
To intercept only if the call was not answered:
<action application="set" data="intercept_unanswered_only=true"/> <action application="intercept" data="myUUID"/>
intercept_unbridged_only is useful e.g. in scenarious where the initial call has been answered and transferred and is ringing at the transfered extensions. With intercept_unanswered_only=true this call could no longer be intercepted, but with intercept_unbridged_only=true it still can be.
原文:http://www.cnblogs.com/dancheblog/p/3531209.html