Asterisk cmd Transfer

Transfer()

Synopsis

Transfer caller to remote extension

Description

Transfer([Tech/]dest[|options])

Requests the remote caller be transferred to a given extension.
If TECH (SIP, IAX2, LOCAL etc) is used, only an incoming call with the same channel technology will be transferred.
Note that for SIP, if you transfer before the call is set up, a 302 redirect SIP message will be returned to the caller. It is possible to use 302 redirections to load-balance SIP calls among several servers. A patch that fixes a few bugs is here: patch 9483.

The result of the application will be reported in the TRANSFERSTATUS channel variable:

SUCCESS Transfer succeeded
FAILURE Transfer failed
UNSUPPORTED Transfer unsupported by channel driver

The option string may contain the following character:

‘j’ — jump to n+101 priority if the channel transfer attempt fails

Olle in Jan 2006: Transfer() is currently the only way to issue an outbound SIP REFER in the dial plan.
The transfer() application sends a REFER, then totally ignores what is happening with the transfer. It does need a total rewrite for all VoIP channels and should probably be considered a bad hack.

For older Asterisk versions that still support priority jumping (1.0, 1.2 if enabled): If the transfer was not supported or successful and there exists a priority n+101, then that priority will be taken next.

Question: Where – except for a SIP REFER – is this application of use, why not simply use Dial(), maybe together with a Local channel?

Answer: For example, a SIP provider offering DIDs, you want calls to go to a colo box and then be transferred to other locations rather then waiting for the DID provider to update routes, by using this you save headaches with 1 way audio due to tracking firewalls not being able to track asynchronous SIP and RTP paths, and call delay if you and the colo are in different countries. The downside to doing something like this is you incur a slightly increase call setup delay while the call is bounced between servers, but no one will ever notice since most people take a few rings to actually answer.

Related transfer techniques: Deflection and re-routing

Please note that ECT or CD will only work if your telco has configured your BRI/PRI accordingly (possibly involving an extra charge).

• Asterisk func REDIRECTING introduced by Asterisk 1.8 and REDIRECTING(reason) for LibPRI.
• patch 3554: Two-B-channel transfer with Zap; note that 2BCT service just exists for Lucent 5ESS switches, then a regular Dial() on the same PRI span should invoke 2BCT; “transfer” keyword in zapata.conf enables/disables 2BCT on channels
• Asterisk cmd CapiCD: Capi call deflection on PtMP (chan_capi), in newer versions use CapiCommand(deflect|123456)
• CallReroute: Chan_capi-cm, use for PtP (point-to-point = Anlagenanschluss), aka “partial reroute”
• External program capidivert for call diversion
• Asterisk cmd SrxDeflect: Reflect an incoming call (Sirrix)
• Asterisk cmd SrxReroute: Reroute an incoming call (Sirrix)

Notes

Asterisk supports blind (unattended) transfer (on SIP, MGCP and H.323) by pressing # if Asterisk is in the media path, i.e. the Dial() statement has a t or T in it, or if canreinvite has been set to no.
Such a transfer sets the channel variable TRANSFER_CONTEXT so when a #-transfer is executed it uses ${TRANSFER_CONTEXT} from transferee else from transferer else it acts as always, disregarding any transfer context.

See also

• ChannelRedirect: Redirect an existing channel to the dialplan (Asterisk 1.4)
• Asterisk CLI command: channel redirect (new in Asterisk 1.6.2)
• Asterisk config features.conf: Arrange blind and attended transfer
• PBX CallTransfer: More on blind and attended/supervised transfers
• app_bridge (Asterisk 1.6)

Asterisk | Applications | Functions | Variables | Expressions | Asterisk FAQ