IMG 1010 - SIP REFER 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.

• Transferee- The party being transferred to the Transfer Target.

• Transfer Target- The new party being introduced to the Transferee.

• Transferor- The party initiating the transfer of the Transferee to the Transfer target. This is not supported on the IMG. The transferor is usually an application written on a separate server

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:

• Basic or Unattended Transfer-  Basic Transfer consists of the Transferor providing the Transfer Target's contact information to the Transferee. The Transferee attempts to establish a session using that contact and reports the results of that attempt to the Transferor. The signaling relationship between the Transferor and Transferee is not terminated, so the call is recoverable if the Transfer Target cannot be reached. Note that the Transfer Target's contact information has been exposed to the Transferee. The provided contact can be used to make new calls in the future.

• Basic or Unattended Transfer with Consultation- Transfer with Consultation Hold is the same as the Basic Transfer above but involves a session between the transferor and the transfer target before the transfer actually takes place. This is implemented with SIP Hold and Transfer.

• Attended Transfer- The transferor places the transferee on hold, establishes a call with the transfer target to alert them to the impending transfer, places the target on hold, then proceeds with transfer using an escaped Replaces header field in the Refer-To header. This is another common service expected by current PBX and Centrex users. In some instances, the Transferee and Transfer target can be the same IMG.

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.

Open

Refer to IMG 1010 - 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.

Open

Refer to IMG 1010 - 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)

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.

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)

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:

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

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

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

• 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

Added functionality in Software Release 10.5.1 ER5

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=valueA26z25y24x23w22v21u20t19s&CallParkService=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: The UUI data will be added in the User-to-User header of the INVITE.

• SS7: The UUI data will be added in the UUI parameter of the IAM.

• ISDN: The UUI data will be added in the UUI parameter of the Setup.

• The maximum supported length of the UUI parameter is 131 bytes.

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

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.

Refer to the IMG 1010 - SIP REFER Support topic for more information on this object.

Additional Information on Transferee (IMG) Releasing SIP REFER Session

• This functionality is applicable only when the IMG is configured as a Transferee.

• This functionality is supported for both Attended and Unattended Transfer Scenarios.

  • The IMG will release the SIP REFER session only when the call is transferred.

    • 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)

• The SIP REFER will not be terminated if the call transfer is unsuccessful.

• If the call is not transferred to the Transfer Target successfully, i.e Transfer Target is busy (486 returned), the Transferee (IMG) will not release the call. It is up to the Transferor to terminate the call immediately or keep it active since the REFER session was never terminated between the Transferee (IMG) and Transferor.