SIP REFER for Call Transfer

Overview:

The IMG supports the SIP Refer method of transferring calls. This method utilizes the Refer-To Header field to pass contact information such as URI INFO provided in the request. Feature 759 (SIP REFER) gives the IMG the ability to act as either a Transferee or a Transfer Target when used as part of the SIP Call Transfer functionality between three SIP UA’s. The IMG cannot become a Transferor. This will be left to an application written on a different server. Below is a short description of the three functions.

 

There are three different methods to transferring calls using the SIP Refer method. They are as follows and will be explained in more detail below:

 

The above information will be explained in more detail below in different examples and Call Flows.

 

Configuration:

The SIP Refer for Call Transfer feature is Disabled by default. Nothing needs to be configured if SIP Refer functionality is not needed. If however SIP Refer is needed the feature can be enabled by selecting enable in the drop down menu of the SIP Refer field of the SIP Profile pane. See screen capture below.

 

SC_SIP_PRACK_PANE_SGP_1051.png

 

Examples of Call Transfer using SIP Refer:

Below are two examples of how SIP Refer will work in a Network where the IMG is used as the Transferee and Transfer Target. The two methods that will be explained below are the Basic Transfer and the Attended transfer.

 

Note: In the examples below, the SIP REFER message is sent back to the Transferee. When this happens, the route table from the original inbound channel group on the Transferee is used and not the route table from the Transferor.

 

Basic Transfer (Unattended)

 

DG_SIP_REFER_Unattended.png CF_SIP_REFER_Unattended.png

 

 

 

A) A connection between Transferor and Transferee is established through dialog.

B) Transferor sends a REFER message to Transferee. Within REFER is information to be able to communicate with the Transfer Target.

C) Transferee informs the Transferor that it accepted the REFER message

D) Transferee tries to make a connection with the Transfer Target through dialog.

E) Transferor terminates the connection between Transferor and Transferee

F) Connection between Transferee and Transferor is established. Transferee informs Transferor that call has succeeded and then terminates the REFER subscription

G) Call has successfully been transferred using SIP Refer

 

 

 

 

Unattended Transfer back to PSTN

This method allows the user the flexibility that a call can be transferred to any Channel Group.

 

If call is routed based on the user of the Refer-To Header:

  1. The host address of the Refer-To Header must be set to the IMG SIP signaling IP address.

  2. The user of the Refer-To Header must have a match in the routing table.

 

Note: Only Blind Transfer can be accomplished if the call is transferred back to the PSTN side.

 

DG_SIP_REFER_Unattended_Transfer_back_PSTN.png    CF_SIP_REFER_Unattended_Transfer_back_PSTN.png

 

 

A) A dialogue between the Transferee and Transferor is established

B) Transferor sends a REFER message to Transferee with the originating GW IP address along with Destination Address in Refer-to header.

C) Transferee informs the Transferor that it accepted the REFER message. The IMG looks up routing table assigned to the Originator Channel Group for the Destination.

D) Transferee initiates a call to the PSTN on the results of the Route table look up

E) Transferor sends BYE to Transferee to release the original dialogue

F) Call between Transferee and Transferor is dropped

 

Call has successfully been transferred to PSTN using SIP Refer

 

 

 

 

Transfer (Attended)

DG_SIP_REFER_Attended.png      CF_SIP_REFER_Attended.png

 

 

A) A connection between Transferor and Transferee is established through dialog.

B) Transferor makes connection with Transfer Target through dialog.

C) Transferor then sends REFER to Transferee. Within REFER is information to be able to communicate with the Transfer Target.

D) Transferee informs Transferor that it accepted the REFER and then tries to make connection between Transferee and Transfer Target

E) Transfer Target terminates connection with Transferor and ends dialog and Transferor terminates connection with Transferee.

F) Connection between Transferee and Transfer Target is established. Transferee informs Transferor that call has succeeded.

 

 

Transfer (Attended) - Transferee and Transfer Target are same entity.

 

Note: In the diagram above the Transferee and Transfer Target are depicted as separate entities.  The Attended Transfer can also be accomplished using a single IMG.  In this instance the Transferee and Transfer Target have the same Signaling IP address on the same IMG. i.e. SIP signaling between the Transferee and Transfer Target are looped back externally to the IMG.  In order for this type of transfer to work, the following settings must be configured accordingly:

  1. Under the External Network Elements pane the IMG must be added as an 'External Gateway' and configured.

  2. The SIP profile used for this configured 'External Gateway' must have the 'SIP Loop Detection' set to 'Disable with no header check'

  3. Add a 'Channel Group' for the IMG that has the IMG listed as the groups 'IP Network element'.

  4. A separate Routing Table must be used as the destination address of the second and third INVITE's (above) are the same but they need to be routed to different channel groups, the second to the Transfer Target and the third to the IMG itself.

 

 

Note: In software version 10.5.1 ER4 Feature F-1683 Handling URI parameters in the Refer To: header adds to the IMG the ability to transfer any URI Parameters from the Transferor to the Transfer Target. The URI Parameters are passed in the Outgoing INVITE only and is limited to 512 bytes in length. This feature allows customers the ability to transport call control related information (Call Waiting, Call Forward on Busy, etc) from the Transferor to the SIP Transfer Target during a referral scenario.