The Transfer object connects the caller of a service to another entity, referred to below as called party (e.g. a telephone line or another application).
Usage examples of the Transfer object include:
· Voice dialing service:
- Inbound dialer for an enterprise to automate the main reception
- Outbound dialer for a telecommunications carrier or an enterprise
· Automated directory assistance with instant transfer option
· Auto-attendant solution with a follow-me transfer option
· Transfer to an operator or a call center agent in any kind of self-service application (e.g. a flight information system)
· Voice dating service with instant call transfer option
Most of the media platforms certified for use with VoiceObjects support two different call transfer modes that can be configured within the Transfer object: bridge transfer and blind transfer. In addition, some platforms also support consultation transfer, which is a special form of blind transfer. Finally, there is the CCXML transfer.
Due to its nature the Transfer object is only intended for the voice and video channel; in the text and Web channel it will not be processed. For further information on channels refer to Chapter 10 – How to Support Multiple Phone Channels in the Design Guide.
The Object Definition below covers the configuration of the Transfer object with VoiceObjects Desktop. For information on how to define this object type using VoiceObjectsXML refer to the VoiceObjectsXML Definition paragraph.
The Transfer object belongs to the object category Actions.
During a bridge transfer, the media platform connects the caller and the far-end called party in a full duplex conversation, monitoring the progress of the call and optionally listening for speech or DTMF input from the caller (controlled by any included Grammar object). A successful DTMF input or speech recognition will terminate the connection to the called party. If no grammar is specified, the media platform will not listen to input from the caller. The media platform does not monitor in-band signals or speech input from the called party. When the connection between the caller and the called party is terminated, the processing of the dialog flow within VoiceObjects Server resumes. The following figure shows how all parties (caller, called party and media platform) are involved after a successful bridge transfer.

The bridge transfer allows the configuration of two time intervals. The first one is a timeout interval to establish the connection between the caller and the called party. If the connection timeout is exceeded a no answer event is thrown by the media platform and caught by the Transfer object. The second time interval limits the maximum duration of the established call connection. When this limit is reached the caller and called party are disconnected by the media platform anda maximum time event is thrown to the Transfer object.
A blind transfer hands off the caller to the telephony network and redirects the caller to the called party. At this point the media platform no longer has access to the call connection, and does not monitor the final outcome. Whether the connection is successful or not, the media platform cannot regain control of the call connection. Still, dialog end processing can take place in VoiceObjects Server immediately after call control has been released. The following figure shows that the media platform and VoiceObjects Server are no longer involved in the call after the transfer has been initiated.

When using blind transfer, the outcome of the transfer is not known to the media platform or VoiceObjects Server, so the application cannot continue in case of a transfer failure. If this is desired, though, useconsultation transfer. This is basically a blind transfer, so once the transfer is done, both the media platform and VoiceObjects Server terminate their sessions and free resources. But if the transfer cannot be established, call control is returned to the media platform that in turn goes back to VoiceObjects Server. The reason of the transfer failure is stored in a status variable (see below).
i8 Note: All media platforms used with VoiceObjects Server support blind transfer. Support of bridge and consultation transfer depends on the platform. Media platforms supporting the bridge transfer mode may optionally support DTMF input and/or speech recognition during the call transfer to drop the far-end connection (see the corresponding media platform documentation for further information).
The CCXML transfer mode is used to transfer a session back and forth between a VoiceXML and a Call Control XML (CCXML) session. This is useful for certain types of applications such a conferencing in which call control-related activities (e.g. setting up additional call legs) intertwine with dialog flow-related activities (e.g. playing prompts or selecting actions from menus).
A CCXML transfer differs from the other transfer types in that the Transfer object itself does not establish a connection to a called party, but merely hands control over the call back to a pre-existing CCXML session, which then decides how to proceed.
Similar to the situation in a bridged transfer, the VoiceObjects session remains active while the call is handled within the CCXML application, so that it can resume afterwards.
When deciding between using a bridge or a blind/consultation transfer, it should always be considered whether or not to allow the caller to resume the interaction with the phone application after the call transfer has been completed. If so, a bridge transfer must be used. If not, a blind or consultation transfer should be performed.
You can use a bridge transfer even if the phone application does nothing more than disconnect the caller when the transfer has ended. However, using a blind transfer in this case minimizes costs by reducing the number of minutes the caller would otherwise consume resources on both the media platform network and the call destination network. When a blind transfer is processed, the call session on the media platform network terminates, and the caller no longer ties up any telephony resources.
If for some reason the outcome of the call transfer is relevant to the application - whether it was answered, the line was busy, the transfer failed, the call duration was so many minutes long, etc. - a bridge or consultation transfer should be used.
Call transfers can fail for several reasons, which are outlined below.
Potential failures when using blind, bridge, or consultation mode:
· Callers attempt to call a destination for which they have no authorization (e.g. a long distance call or a premium service line).
· The specified destination is invalid or incomplete.
· The media platform cannot place a call to the specified destination.
Potential failure only when using the bridge mode:
· The media platform does not have the necessary resources available to place the bridge transfer.
It is possible to minimize call transfer failures by estimating the application-specific call transfer requirements before building and deploying the application; e.g. by ensuring that within an automated call center application the call center infrastructure has sufficient call handling capacity. In addition, it can be useful to take advantage of call center integration capabilities offered by several certified media platforms of VoiceObjects. Some of these media platforms offer the functionality to ensure that a call route to an agent is available for the caller before the call transfer gets processed within the phone application.
A bridge transfer consists of two processing phases:
· Before a connection to the called party is established.
· After a connection to the called party has been established.
In either processing phase, depending upon the action taken by the caller, the called party or the telephony network, the media platform will invoke a specific exception event, which is available to the Transfer object for further processing within VoiceObjects Server.
While attempting to connect to the called party, the media platform continuously checks call progress indicators. For the duration of a successful bridge transfer, the media platform monitors several telephony events, such as disconnect, on both call legs.
The following table lists the possible results for a bridge transfer before a connection with the called party is established:
|
Possible Result Prior Connection |
Status Code |
|
The caller hung up the phone. |
near_end_disconnect |
|
The caller forced a call disconnect via a DTMF or speech command. |
near_end_disconnect |
|
The far-end line of the called party was busy. |
busy |
|
An intermediate telephony network refused the call connection to the called party. |
network_busy |
|
The call connection was not answered by the called party within the specified timeout invervall. |
noanswer |
|
The transfer ended but the reason is not known. |
unknown |
The next table lists the possible outcomes for a bridge transfer after a successful connection between the caller and the called party has been established:
|
Possible Result After Connection |
Status Code |
|
The caller hung up the phone. |
near_end_disconnect |
|
The caller forced a call disconnect via a DTMF or speech command. |
near_end_disconnect |
|
The call connection was automaticallly terminated by the media platform because the call duration exceeded the allowed maximum. |
maxtime_disconnect |
|
The telephony network disconnected the called party from the media platform. |
network_disconnect |
|
The called party hung up the phone. |
far_end_disconnect |
|
The call transfer ended but the status is unknown. |
unknown |
If a transfer does not succeed, consultation transfer returns to the application. The outcome is then available with the following status codes:
|
Possible Result Prior Connection |
Status Code |
|
The caller hung up the phone. |
near_end_disconnect |
|
The caller forced a call disconnect via a DTMF or speech command. |
near_end_disconnect |
|
The far-end line of the called party was busy. |
busy |
|
An intermediate telephony network refused the call connection to the called party. |
network_busy |
|
The call connection was not answered by the called party within the specified timeout invervall. |
noanswer |
|
The transfer ended but the reason is not known. |
unknown |
The first dialog flow example shows the use of the Transfer object within a voice portal application to establish a bridge connection to an operator for assistance. The caller of the Voice Portal is using the service for the very first time and is using operator assistance immediately. After clarification of the questions the call connection is terminated by the operator, and the call continues with the dialog flow of the main menu.
|
Object – |
Dialog Flow |
|
Main menu! You have the following options … |
|
|
|
Operator |
|
|
One moment please. We will transfer your call to one of our operators. |
|
|
Good morning! |
|
|
Hi! I’m using this service for the first time and I would like to know how to … |
|
|
< Ongoing conversation > |
|
|
I’m now transferring you back to the Voice Portal. |
|
You are back in the main menu! |
The next example is based on an outbound voice dialing application. It demonstrates how successive call connections in bridge mode are initiated through the caller within the same dialog flow. The application is using a database system to manage the individual caller profiles and the corresponding personal phone book information.
The third dialog flow example demonstrates the use of a blind transfer which hands off the caller to the telephony network and redirects the call to an operator for personal assistance. This happens after the caller has failed to enter his phone number for the third time in a row.
|
Object – |
Dialog Flow |
|
Enter your ten-digit phone number. |
|
|
|
< No input > |
|
I’m sorry, I need your phone number. |
|
|
|
8 4 5 3 3 3 3 |
|
That’s not a complete phone number. Please enter your ten-digit phone number including the area code. |
|
|
|
7 0 3 8 4 5 3 3 3 |
|
I’m sorry, but I still don’t have your complete phone number. |
|
|
|
I’ll connect you with one of our operators < Dialog session ends > |
|
|
< Ongoing conversation between the |
The Definition of the Transfer object provides the following sections:
· Transfer Notification
To inform the caller about the transfer process.
· Processing
To configure the transfer operation behavior.
· Parameter Set
To optionally transmit custom parameters with the transfer request.
· Termination Grammar
To allow the caller to control the connection termination.
· Connect Audio
To optionally play back an audio file while connecting.

For information regarding additional object configuration refer to Pre-/Postprocessing, Event Handling, Tuning, and Properties in this Object Reference.
The optional output is played back when the Transfer object is entered to notify the caller that a connection to the desired far-end will be initiated. The output should also tell the caller which speech or DTMF command can optionally interrupt the transfer processing via the termination grammar, to return to the original dialog flow. If necessary, timing constraints such as the connect timeout or the maximum connection duration should be mentioned as well.

For more details on output definitions refer to the Output object in this Object Reference.
The Processing section specifies mandatory settings, time limits, and optional variables to catch the transfer processing results.

The first part specifies the following mandatory properties:
|
Property |
Description |
|
Transfer mode |
Defines the transfer mode as Bridge, Blind, Consultation, or CCXML. By default it is set to Bridge. The transfer mode can also be provided dynamically at call time by assigning a Variable, Expression, Script, or Layer object, which must contain the string bridge, blind, consultation, or ccxml. |
|
Protocol |
Defines a connection protocol to be used for the transfer. The options are Phone, SIP (Session Initiation Protocol) or Custom, where Phone is the default setting to configure a regular phone number in the Destination field. All media platforms support the phone protocol. Support of the Session Initiation Protocol (SIP) depends on the underlying media platform (details are available in the corresponding media platform documentation). When setting the protocol property to Custom, a complete URL for the transfer destination has to be provided in the Destination field (see details below). |
|
Destination |
Usually contains a regular phone number (e.g. 18001234567) when using the phone protocol, or a SIP address (IP telephony address) when using the Session Initiation Protocol. The connection destination can be provided as a constant value or as the value of a Variable, Expression, Script, or Layer object at call time. If the protocol property is set to Custom, the URL for the destination address is based on the URL addressing schemes supported by the individual media platform (see the corresponding media platform documentation for further information). All media platforms usually support the “tel:” URL syntax described in the document URLs for Telephone Calls of the IETF Network Working Group (see http://www.ietf.org/rfc/rfc2806.txt, The Internet Engineering Task Force, April 2000) and may support other URL-based addressing schemes. |
The second part of the Processing section specifies time limits:
|
Property |
Description |
|
Defines the time interval to wait while trying to connect to the called party before returning the noanswer status. The value is a time designation provided in seconds. The timeout setting only applies if the bridge or consultation transfer mode is enabled, otherwise it will be ignored. By default, the value for the connect timeout is set to 15 seconds. When using a Variable, Expression, Script, or Layer object to define the connect timeout at call time, or when typing in a custom value instead of selecting one of the values from the drop-down list, the value needs to be a positive number and will be applied as seconds, e.g. for a custom timeout of 5.5 minutes, type in 330. |
|
|
Defines the maximum time the caller may remain in the transferred call before the server internally terminates the dialog session. If a transfer takes longer than this time interval and the caller wants to return to the dialog after a bridged or CCXML transfer, the server will respond with a "service unavailable" message and make the platform hang up. When using a Variable, Expression, Script, or Layer object to define the standby timeout at call time, or when typing in a custom value instead of selecting one of the values from the drop-down list, the value needs to be a positive number and will be applied as seconds, e.g. for a custom timeout of 5.5 minutes, type in 330. The default setting Default indicates that this timeout is defined within the Service object. For more details on services, refer to Configuring Servers and Services in Chapter 2 of the Deployment Guide. |
|
|
Specifies the time interval that the call connection to the called party is allowed to last. The value is also a time designation provided in seconds and only applies if bridge mode is activated. To enter a custom value, which is interpreted as seconds, enter "15.0" for instance. The default value is set to unlimited which is internally represented by the value 0 (zero). When using a Variable, Expression, Script, or Layer object to define the maximum duration dynamically at call time, the corresponding value needs to be numerical and will be applied as seconds. @8 Tip: If the caller exceeds the time interval defined in the Maximum duration field, the event ASR – Max Processing Time is activated in case a corresponding event handler is defined. A typical use case would be an event handler that first tells the caller that the transfer was interrupted due to the time limit (by linking an Output object in the handler) and then restarts the transfer (by setting Continuation to Return). |
The third part of the Processing section references optional variables to catch the transfer processing results for the connection duration and status.
|
Property |
Description |
|
Duration |
Optionally references a Variable object to catch the transfer duration time in seconds provided by the media platform. The duration has the value 0 (zero) if a call attempt was terminated by the caller (using an active speech or DTMF command) prior to being answered by the called party. Note that this value is only available in the case of a bridge or consultation transfer. In addition to using this field, you can also access the duration by using the LASTRESULT function through an Expression object. |
|
Status |
Optionally references a Variable object to catch the transfer status as documented in the introduction Handle bridge transfer events. The following list shows the set of possible status values in alphabetical order: · busy · far_end_disconnect · maxtime_disconnect · near_end_disconnect · network_busy · network_disconnect · noanswer · unknown The value of an assigned status variable can be evaluated (e.g. with a Case object) after the Transfer object processing has ended to decide how to continue with the dialog flow. Note that this value is only available in case of a bridge or consultation transfer. In addition to using this field, you can also access the status by using the LASTRESULT function through an Expression object. |
The Parameter Set section defines an optional list of parameters that are passed to the media platform. These parameters allow designers to make use of special extensions to the transfer functionality that are provided by a number of media platforms.

The example shown here applies to the VoiceGenie media platform and indicates that the platform should try to detect whether an answering machine answers the transferred call.
The parameters defined in the Parameter Set section are placed into the markup as attributes of the <transfer> tag, so the VoiceXML code for the example above looks like this:
<transfer detectansweringmachine=”true”> … </transfer>
When using the Transfer mode CCXML, the following parameters are automatically transmitted without having to define them in the parameter set:
· VSN
The VoiceObjects Service Name (VSN) of the current service.
· dialogID
The dialog ID of the current dialog session.
· returnURL
The URL under which the current dialog session may be continued.
The CCXML application can use these parameters to re-enter the dialog session after having performed any relevant call control activities.
By use of the parameters goto=<ReferenceID> or gosub=<ReferenceID> the CCXML application can invoke a different part of the VoiceObjects application when returning, either replacing the normal continuation of the dialog flow (in case of goto) or inserting a sub-dialog before continuing with the object following the Transfer (in case of gosub).
The termination grammar defines the utterances the caller can say and/or the DTMF keys the caller can press to terminate the connection with the called party.

For details on a valid grammar definition refer to the Grammar object in this Object Reference.
i8 Note: This feature is only supported for bridged transfers and is not available on all media platforms. See the corresponding media platform documentation for further information.
If a transfer has been terminated through a voice or DTMF command, the utterance and input mode of this command can be retrieved by using the LASTRESULT function. See the Expression object in this Object Reference for details.
The Connect Audio section allows configuring an audio source to be played back while the transfer attempt is in progress (before the called party has answered). This is only possible if Transfer mode is set to either Bridge or Consultation.

For detailed information on the fields provided in the Connect Audio section refer to the Audio object in this Object Reference.
If for any reason the audio file resource cannot be fetched at call time from the media platform (e.g. the file is not available or corrupted), the error will be ignored and the call transfer operation will continue. What the caller will hear instead of the audio resource during the connect interval is media platform and network configuration dependent (e.g. the standard ring tone from the telephony network).
i8 Note: Not all media platforms certified for VoiceObjects support the playback of an audio file while attempting to establish the connection to the called party (see the corresponding media platform documentation for further information).
The Transfer object is represented by the VoiceObjectsXML element <transfer>. It has eight attributes and seven groups of children.
In addition, the element has the standard attributes described in the XDK Guide.
The <transfer> element uses the embedded <parameterSet> element.
· mode
Defines the mode of the transfer, one of bridge, blind, consultation, or ccxml. May be a constant value, or a reference to an Expression, Script, or Variable object. If not specified, defaults to bridge.
· protocol
Defines the protocol used for the transfer. One of phone, sip, custom. If not specified, defaults to phone.
· destination
Defines the destination for the transfer. May be a constant value, or a reference to an Expression, Script, or Variable object.
· connectTimeout
Defines the timeout for trying to reach the third party. An integer value that is interpreted as seconds. If not specified, defaults to 15.
May be static text or a reference to an Expression, Script, or Variable object.
When importing an XDK application into VoiceObjects Desktop, this value must be one of those presented in the Desktop drop-down list (5, 10, 15, 20, 30, 40, 50, 60, 120, 180, 240, 300), or an object reference.
· standbyTimeout
Defines the standby timeout for the Transfer object. Either default or an integer value that is interpreted as seconds. If not specified, defaults to default.
May be static text or a reference to an Expression, Script, or Variable object.
· maxDuration
Defines the maximum duration of the transferred call. Either unlimited or an integer value interpreted as seconds. If not specified, defaults to unlimited.
May be static text or a reference to an Expression, Script, or Variable object.
For details see Maximum Duration above.
When importing an XDK application into VoiceObjects Desktop, this value must be one of those presented in the Desktop drop-down list (60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2400, 3000, 3600), or an object reference.
· status
Reference to a Variable object that receives the return status (only relevant for bridged transfers).
· duration
Reference to a Variable object that receives the duration of the transferred call in seconds.
· <expression usage=”precondition”> or
<variable usage=”precondition”> or
<collection usage=”precondition”> or
<script usage=”precondition”>
Defines the precondition for the Transfer object.
· <sequence usage=”preprocessing”>
Defines the preprocessing sequence for the Transfer object.
· <output>
Defines the transfer notification.
· <parameterSet>
Defines the parameter set for the Transfer object.
· <grammar>
Defines the grammar used to return to the original application.
· <audio>
Defines the connect audio.
· <eventHandling>
Defines the event handling for the Transfer object.
· <tuning>
Defines the tuning settings for the Transfer object.
· <sequence usage=”postprocessing”>
Defines the postprocessing sequence for the Transfer object.
<transfer mode=“blind“ destination=“+492204845100“/>
· +<item>
Defines the list of entries in the parameter set. The use of the alias attribute is optional when the object attribute is used, and required when the value attribute is used.
<parameterSet>
<item alias=”customer” object=”#Customer number”/>
<item alias=”locale” value=”de-DE”/>
</parameterSet>
· object
Defines a reference to an object. If this attribute is defined, the value attribute may not be defined.
· value
Defines a constant value. If this attribute is defined, the object attribute may not be defined.
· alias
Defines the parameter alias.
<item alias=”premium” object=”#Annual premium”/>
<item alias=”locale” value=”en-US”/>
The following table contains all the object types that can reference a Transfer object:
|
Icon |
Object Name |
Use Case Example |
|
|
A call can be transferred at a certain point when using the Transfer object within a Sequence object. |
|
|
|
A Transfer object can be initiated within a Menu object. |
|
|
|
A call can be transferred under a certain condition in an If object. |
|
|
|
A call can be transferred under a certain condition in a Case object. |
|
|
|
The Transfer object can be referenced within a Goto object. |
|
|
|
A Hyperlink object is a typical use case where the Transfer object gets activated on demand by the caller through a voice command as described in the first dialog flow scenario. |
In order to leverage the capabilities of the integrated documentation of VoiceObjects it is important to provide intuitive and self-explanatory object names and descriptions.
The name of the Transfer object should describe in brief what kind of call transfer will be processed and to which destination. The name may contain additional information on the maximum allowed transfer duration or other processing options. The attached description should provide further details how the Transfer object is processed. See the examples below:
|
Name |
Description |
|
|
Transfers the call in blind mode to the call center operator. |
|
|
Connects the caller to the specified destination via the SIP protocol in bridge mode. The destination is specified by the variable SIP Destination. |
|
|
Transfers the call to the 3rd party phone application VoiceBanking (1-800-VOICE-BANK). |