SIP REFER for Call Transfer

The IMG supports the SIP REFER method of transferring calls. This method utilizes the Refer-To Header field to pass contact information such as the URI INFO provided in the request. Feature F-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 User Agents (UAs). 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 functionality is configured in the SIP SGP profile object when  running software prior to the 10.5.3 CI release. Starting in the 10.5.3 CI release, the method used to configure the feature was moved to its own SIP REFER object that is configured under the SIP SGP Profile object. The information below displays both methods.

Prior to the 10.5.3 CI software release

The SIP Refer for Call Transfer feature is by Default set to Disabled. Nothing needs to be configured if the SIP Refer functionality is not needed. If however, the SIP Refer functionality is needed, the feature is enabled by setting the REFER Support field in the SIP SGP object to Enable. Refer to screen capture below.

sc_sip_prack_pane_sgp_1051.png

Refer to SIP Profile - 10.5.2 for more information on this object.

Starting from the 10.5.3 CI software release

In the 10.5.3 CI release, the SIP Refer object was moved from being a field in the SIP SGP object to being a child object of the SIP SGP object. To access the SIP Refer functionality in software 10.5.3 and beyond simply right click on the SIP SGP object pane and select New SIP Refer Support. The SIP REFER Support object that gets configured will allow the user to configure multiple options to the SIP REFER feature. Below is screen capture of the SIP REFER Support object.

sc_sip_refer_support_en_1053.png

Refer to SIP REFER Support for more information on this object.

 

Examples of Call Transfer using SIP Refer:

Below are two examples of how SIP Refer will behave 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. 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 Transferee and Transferor 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) Connection between Transferee and Transferor is established. Transferee informs Transferor that call has succeeded.

F) Transferor terminates the REFER subscription to Transferee with a BYE message.

G) Call has successfully been transferred from Transferee to Transfer Target using the SIP Refer Method.

 

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 achieved 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.

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.

Added functionality in Software Release 10.5.1 ER4

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.

 

Added functionality in Software Release 10.5.1 ER5

Note: In software version 10.5.1 ER5 Feature F-1647 adds to the IMG the ability to relay custom headers received in the SIP Refer-To header to the transfer target in the resultant SIP INVITE. A custom header is any header other than the 'UUI' or 'Replaces' Header. The 'headers' portion in the REFER-To header starts with the '?' and each header delimited by the '&'. See below.

'?' = Determines where the 'headers' portion of the SIP REFER-To message begins.

'&' = Separates the individual headers from each other.

Example: SIP REFER-To message with Call-Info custom header:

SIP REFER:

REFER sip:3135551212@10.129.10.10:5060 SIP/2.0\r\n

Via: SIP/2.0/UDP 10.129.10.9:5060;branch=z9hG4bK-1046-1-7\r\n

From: <sip:3135551212@10.129.10.9:5060;user=phone>;tag=1\r\n

To: <sip:5088623000@10.129.10.10;user=phone>;tag=95ffcd055e0f78f7d5d397020e89288db3f4019d\r\n

Call-ID: 49c5-4b3-510200913258-SIPANSI32sp1-7-10.129.10.10\r\n

CSeq: 2 REFER\r\n

Contact: <sip:10.129.10.9:5060;transport=UDP>\r\n

Refer-To: <sip:4145551212@10.129.44.173?Call-InfoA-a1b2c3d4e5f6g7h8i9j10k11=valueA

26z25y24x23w22v21u20t19s&Call

ParkService=ParkCall&Call-InfoB01020304050607080900=10191817161514131211>\r\n

Referred-By: <sip:5088623000@10.129.10.9>\r\n

Content-Length: 0\r\n 

SIP INVITE:

INVITE sip:4145551212@10.129.44.173;user=phone SIP/2.0\r\n

Via: SIP/2.0/UDP 10.129.10.10:5060;rport;branch=z9hG4bK-67d2-1244640688-4998-473\r\n

Call-ID: 5a9-401-5102009133128-SIPANSI32sp1-7-10.129.10.10\r\n

CSeq: 1 INVITE\r\n

Max-Forwards: 70\r\n

To: <sip:4145551212@10.129.44.173;user=phone>\r\n

From: 5088623000<sip:5088623000@10.129.10.10>;tag=95ffcd055e0f78f7d5d397020e89288d55ac2da4\r\n

User-Agent: Dialogic-SIP/10.5.1.230 SIPANSI32sp1 7\r\n

Timestamp: 06102009133128\r\n

P-Asserted-Identity: 5088623000<sip:5088623000@10.129.10.10>\r\n

Contact: <sip:5088623000@10.129.10.10:5060>\r\n

Allow: INVITE, BYE, REGISTER, ACK, OPTIONS, CANCEL, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE\r\n

Supported: path, replaces, timer, tdialog\r\n

Session-Expires: 1800\r\n

Referred-By: <sip:5088623000@10.129.10.9>\r\n

Expires: 300\r\n

Organization: Dialogic\r\n

Remote-Party-ID: 5088623000<sip:5088623000@10.129.10.10

;user=phone>;party=calling;id-type=subscriber;privacy=off;screen=no\r\n

Call-InfoA-a1b2c3d4e5f6g7h8i9j10k11: valueA-26z25y24x23w22v21u20t19s\r\n

CallParkService: ParkCall\r\n

Call-InfoB01020304050607080900: 10191817161514131211\r\n

Content-Type: application/sdp\r\n

Content-Length: 166\r\n

 

Added functionality in Software Release 10.5.3 CI

In software version 10.5.3 Feature F-1646 adds to the IMG the ability to relay UUI headers received in the SIP Refer-To header to the transfer target. The headers portion in the REFER-To header starts with the '?' and each header delimited by the '&'. See below. The UUI header, escaped in the SIP REFER message shall be relayed to the transfer target endpoint. The transfer target can be a SIP, ISDN or SS7 endpoint.

SIP REFER-To message with UUI header:

SIP Refer-To header. It needs to be percent decoded before being relayed to the transfer target.

 

Refer-To: <sip:30810@135.122.60.176;transport=tcp?Expires=120&User-to

User=00C810471d16fc00000000877a110d23510002FA0827110013485C1D78%3Bencoding%3Dhex&Replaces=aa24868b7b3ddd1560007a87303c%3Bfrom-

tag%3D7824868b7b3ddd1550007a87303c%3Bto-tag%3D80fcc03db746dd1c6448148fa500&Call-Info=answer-after%3D2>

 

Header is relayed in an INVITE to a SIP Transfer Target as displayed below.

User-to-User: 00C810471d16fc00000000877a110d23510002FA0827110013485C1D78;encoding=hex\r\n

Replaces: aa24868b7b3ddd1560007a87303c;from-tag=7824868b7b3ddd1550007a87303c;to-tag=80fcc03db746dd1c6448148fa500\r\n

Expires: 120\r\n

Call-Info: answer-after=2\r\n

 

Added functionality in Software Release 10.5.3 SP10.1

Prior to software release 10.5.3 SP10.1, when the IMG (Transferee) is in a call transfer scenario via the SIP REFER functionality, the Transferor (SIP Application Server) initiates the SIP REFER message with information on where to transfer the call to. Once the call has been transferred, the IMG (Transferee) does not terminate the REFER session. The IMG (Transferee) leaves it up to the Transferor (SIP Application Server) to initiate the termination of the SIP REFER session.

In some older SIP Application Servers, the Transferor (SIP Application Server) does not have the functionality to be able to release the SIP REFER session after the call has been successfully transferred to the Transfer Target. This causes an issue where the SIP REFER session is not terminated until the active call to the Transfer Target is terminated. At that point, the IMG releases the SIP Refer session.

Feature F-6319 Ability for Transferee to Release SIP REFER session adds functionality that will allow the IMG to release/terminate the SIP REFER session between the Transferee (IMG) and Transferor (SIP Application) once the call has been redirected to the Transfer Target (Ext Gateway). The IMG can now be configured to send a BYE message to the Transferor (SIP Application Server) and release the SIP REFER session once the call between the Transferee (IMG) and Transfer Target (Ext Gateway) has successfully been transferred. This functionality is added to both the Basic Attended and Basic Unattended call flows displayed above.

Refer to the information below which describes the new functionality and how to configure the IMG to make use of the new feature which is utilized when the Transferor (SIP Application) does not have the functionality to release the SIP Refer session itself.  

 

Basic Transfer (Unattended) - IMG Releases SIP REFER session

 

dg_sip_refer_unattended.png cf_sip_refer_unattended_f6319.png

A) A connection between Transferee and Transferor 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) Connection between Transferee and Transferor is established. Transferee informs Transferor that call has succeeded.

F) Transferee terminates the REFER subscription to the Transferor with a BYE message.

G) Call has successfully been transferred from Transferee to Transfer Target using the SIP Refer Method.

 

Configuration of Transferee (IMG) Releasing SIP REFER Session

The SIP Refer for Call Transfer feature is by Default set to Disabled. The REFER Support field in the SIP Refer Support object must first be set to Enabled. Once SIP Refer is enabled, the Release REFER Session field can be either Enabled or Disabled. When the field is Disabled (Default) the IMG depends on the Transferor (SIP Application) to release the SIP REFER Session. When the field is Enabled, the Transferee (IMG) will initiate the release by sending a BYE message to the Transferor once the call has been transferred/redirected. Refer to screen capture below.

sc_sip_refer_support_1053_sp1_10_1.png

Refer to the SIP Refer Support topic for more information on this object.

 

Additional Information on Transferee (IMG) Releasing SIP REFER Session

 
  • The IMG will release the SIP REFER session only after it transmits the SIP Notify message and received back the 200 OK NOTIFY message from the Transferor
  • If IMG does not receive back the SIP 200 OK NOTIFY message, it will begin a retransmission of the SIP NOTIFY (terminate) message.
  • If the SIP NOTIFY (terminate) messages retransmission expires and the IMG still does not receive the SIP 200 OK NOTIFY from the Transferor, the IMG will proceed to release the SIP REFER message.
  • The Transferee (IMG) will release the SIP REFER session by transmitting a SIP BYE to the Transferor (SIP Application)