Bridged transfers
In a bridged transfer, a caller calls an application, the application connects the caller to the called party but stays connected to both lines—creating a bridge—and monitors the call. A bridged call involves two call legs, one on the primary line (inbound or outbound) and one on the secondary line (outbound only).
In the following figure, the original call comes in from party A on the primary line and is transferred to the third party C, on the secondary line. The resource for the primary call (A) is blocked until the third party hangs up or until the application (B) releases the third-party call (C).
Far-end dialog
A far-end dialog specifies a VoiceXML dialog to conduct with the called party before connecting the transfer. It’s enabled with the farenddialog attribute on the <transfer> element.
- With far-end dialog: A caller calls the application, the application calls the called party (or far end), and based on interaction (or dialog) with the called party, determines whether or not to connect the user to the far end. If the called party agrees, the application connects the two parties. An example of an application using far-end dialog would be a collect call application.
- Without far-end dialog (default): A caller calls the application, the application calls the called party and waits until the called party answers the call before connecting the two parties.
Far-end hot word
A hot word is a specific word or phrase that, once recognized, ends the call to party C and resumes the dialog between party A (caller) and the application. Hot word occurs by default on party A. To enable hot word on party C, set the farendhotword attribute to TRUE on the <transfer> element. See <transfer> for more information.
