Implementing SIP Call Transfer operations

The ways of implementing blind transfer and attended transfer with SIP are described.

As described in Call transfer, two types of SIP call transfer are implemented by Blueworx Voice Response SIP support:

Blind transfer
Attended transfer

In the blind transfer mode using State Tables, Blueworx Voice Response initiates an immediate transfer using the SIP 'REFER' method, which will eventually result in the Blueworx Voice Response application’s calling party being connected to a third party and Blueworx Voice Response being disconnected. There is a single phase to this operation. A Blind Transfer is initiated by a State Table TransferCall action with SV541 containing the TO_HDR URI for the transfer target (No SIP CONSULT or SIP TRANSFER tags are set). The Ring Wait and Ring Time parameters must also be set to zero. XFER_TIMER can be set in SV541 to define a timeout value for the transfer. See VoIP SIP blind transfer, How to write a SIP blind transfer application using state tables, and Transfer control tags for details.

In the attended transfer mode using State Tables, Blueworx Voice Response initially starts a second application, which talks independently to the third party by using a SIP outbound call. This operation is what is known as the ‘Consultation Phase’. Assuming that it is still required to proceed with the transfer after the consultation, the actual call transfer phase then proceeds using the SIP ‘REFER/REPLACES’ sequence. As with the Blind Transfer, the result is that the Blueworx Voice Response application’s calling party is connected to the third party and Blueworx Voice Response is disconnected. See VoIP SIP attended transfer, How to write a SIP attended transfer application using state tables, and Transfer control tags for details.

Blind transfer using VoiceXML

For a blind transfer to work:

The calling device must allow the SIP REFER method indicated by the Invite message Allow header including “REFER”.
An on-hold method that is supported by the calling device must be used by Blueworx Voice Response. The on-hold method is set in the Blueworx Voice Response VOIP SIP Signalling window by the RFC3264 media-on-hold method parameter.
To open the VOIP SIP Signalling window:
1. From the Welcome window, select Configuration → System Configuration → Change.
  The System Configuration window opens.
2. Click on the VoIP SIP Signaling button.
  The VoIP SIP Signalling window opens.
See RFC3264 Media on-hold method for details of the available on-hold methods.

The following example uses the VoiceXML <transfer> element to transfer a non-secure SIP call:

<form id="Transfer1">
 <transfer name="Blind1" dest="sip:12345@xxxxx.hursley.ibm.com" type="blind">
  <filled>
   <log>
    Sample Blind Transfer form filled. Blind1 (form variable)= <value expr="Blind1"/>
   </log>
  </filled>
 </transfer>
 <block>
    <log>Sample Blind Transfer goto exit_app</log>
    <goto next="#exit_app"/>
 </block>
</form>
<catch event="connection.disconnect.transfer">
 <log>Sample Blind Transfer Caught Event result : connection.disconnect.transfer</log>
 <goto next="#exit_app"/>
</catch>
<form id="exit_app">
  <block>
    <log>Exit Sample Blind Transfer Application</log>
    <exit expr="'hangup'"/>
  </block>
</form>

When the VoiceXML <transfer> element is executed, Blueworx Voice Response calls the DTJConsult state table followed by the DTJTransfer state table. The DTJConsult state table does a simple blind call transfer, and the DTJTransfer state table simply hangs up to complete the transfer. If necessary, the DTJConsult state table can be easily modified to change the transfer timeout value.

Using the <object> element:

There is an alternative way of implementing blind transfer from VoiceXML that does not use the VoiceXML <transfer> element, but instead uses the <object> element to call a state table that performs the SIP blind transfer. For more information, see Accessing SIP and Call Transfer tags from your voice application.

Attended transfer

An attended transfer consists of two steps, Consultation and Actual Transfer:

In the Consultation step, a second Blueworx Voice Response application is started up which then does a MakeCall such that the new application is talking to the intended transfer target.
In the Transfer step, the SIP REFER/REPLACES operation is used to connect second and third parties together and allow Blueworx Voice Response to disconnect from the call.
The Consultation Phase is triggered by a TransferCall State Table action with the CONSULT tag set to 0 in SV541, which must also contain the TO_HDR tag set to the URI of the transfer target.
The VOIP_Call_Transfer custom server is used to start the second application, which initiates an outbound call to the transfer target.
The application to be used on the Consultation phase must at least initially be a Blueworx Voice Response State Table (although a VoiceXML application can then be called). The name of the State Table to be initially called is defined in main args parameters of the VOIP_Call_Transfer state table (the default is SuperXferA, which is a State Table that is supplied in the VOIP_Call_Transfer application package).
The return code (edge) from the Consultation phase TransferCall action indicates whether it is required to proceed with the Transfer Phase or not.
The final Transfer Phase is triggered by a TransferCall State Table action with the TRANSFER tag set to zero. This operation causes the actual transfer to take place using the SIP ‘REFER/REPLACES' method. When complete, the initial application is disconnected from the call.

See Call transfer for more details of how to program SIP Call Transfer.

Attended transfer using VoiceXML

For an attended (consultation) transfer to work:

The calling device must allow the SIP REFER method indicated by the Invite message Allow header including “REFER”.
An on-hold method that is supported by the calling device must be used by Blueworx Voice Response. The on-hold method is set in the Blueworx Voice Response VOIP SIP Signalling window by the RFC3264 media-on-hold method parameter.
To open the VOIP SIP Signalling window:
1. From the Welcome window, select Configuration → System Configuration → Change.
  The System Configuration window opens.
2. Click on the VoIP SIP Signaling button.
  The VoIP SIP Signalling window opens.
See RFC3264 Media on-hold method for details of the available on-hold methods.
The calling device must allow the SIP Replaces header indicated by the Invite message Supported header, including option tag "replaces". This last requirement can be overridden by setting the Blueworx Voice Response configuration option Ignore replaces option for Attended Transfer to Yes in the VOIP SIP Signalling window. For more information, see Ignore replaces option for Attended Transfer.
The VOIP_Call_Transfer custom server is installed and started. By default, the custom server calls the SuperXferA state table initially. This state table is supplied in the VOIP_Call_Transfer application package, and does all that is needed to complete the transfer. If required, the SuperXferA state table can be replaced by a customized state table, the name of which is specified in the main args parameters of the VOIP_Call_Transfer custom server. See Attended transfer using the VOIP_Call_Transfer custom server for details of how to install and configure the VOIP_Call_Transfer custom server.

The following example uses the VoiceXML <transfer> element to transfer a non-secure SIP call:

<form id="Transfer1">
 <transfer name="Attended1" dest="sip:12345@uptonsip.hursley.ibm.com" type="consultation"
           connecttimeout ="33s">
  <filled>
   <log>
    Sample Attended Transfer form filled. Attended1 (form variable) = <value expr="Attended1"/>
   </log>
   <if cond="Attended1 == 'busy'">
     <log>Sample Attended Transfer filled = busy.</log>
   <elseif cond="Attended1 == 'noanswer'"/>
     <log>Sample Attended Transfer filled = no answer.</log>
   <elseif cond="Attended1 == 'network_busy'"/>
     <log>Sample Attended Transfer filled = network busy.</log>
   <elseif cond="Attended1 == 'unknown'"/>
     <log>Sample Attended Transfer filled = unknown.</log>
    </if>
   </filled>
  </transfer>
  <block>
   <log>Sample Attended Transfer goto exit_app</log>
   <goto next="#exit_app"/>
  </block>
 </form>
 <catch event="error.connection.baddestination">
  <log>Sample Attended Transfer Caught Event result : error.connection.baddestination</log>
  <goto next="#exit_app"/>
 </catch>
 <catch event="error.connection.noauthorization">
  <log>Caught Event result : error.connection.noauthorization</log>
  <goto next="#exit_app"/>
 </catch>
 <catch event="error.unsupported.uri">
  <log>Sample Attended Transfer Caught Event result : error.unsupported.uri</log>
  <goto next="#exit_app"/>
 </catch>
 <catch event="error.unsupported.noroute">
  <log>Sample Attended Transfer Caught Event result : error.unsupported.noroute</log>
  <goto next="#exit_app"/>
 </catch>
 <catch event="error.unsupported.noresource">
  <log>Sample Attended Transfer Caught Event result : error.unsupported.noresource</log>
  <goto next="#exit_app"/>
 </catch>

<catch event="connection.disconnect.hangup">
  <log>Sample Attended Transfer Caught Event result : connection.disconnect.hangup</log>
  <goto next="#exit_app"/>
 </catch>
 <catch event="connection.disconnect.transfer">
  <log>Sample Attended Transfer Caught Event result : connection.disconnect.transfer</log>
  <goto next="#exit_app"/>
 </catch>
 <form id="exit_app">
  <block>
   <log>Exit Sample Attended Transfer Application</log>
   <exit expr="'hangup'"/>
  </block>
 </form>

Using the <object> element:

There is an alternative way of implementing attended transfer from VoiceXML that does not use the VoiceXML <transfer> element, but instead uses the <object> element to call a state table that performs the SIP attended transfer. For more information, see Accessing SIP and Call Transfer tags from your voice application.

Bridge Transfer

Bridge Transfer is not supported by Blueworx Voice Response.