SIP REFER - Call Transfer
The IMG 2020 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. The IMG 2020 has 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. The IMG 2020 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 2020. 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 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 2020.
The above information will be explained in more detail below in different examples and Call Flows.
Examples of Call Transfer using SIP Refer
Below are a few examples of how SIP Refer will work in a Network where the IMG 2020 is used as either the Transferee the Transfer Target or both. The 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 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
The Unattended method allows the user the flexibility to be able to transferred the call to any Channel Group.
If call is routed based on the user of the Refer-To Header:
The host address of the Refer-To Header must be set to the IMG 2020 SIP signaling IP address.
The user of the Refer-To Header must have a match in the routing table.
Only Blind Transfer can be accomplished if the call is transferred back to the PSTN side.
 |  |
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 2020 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 2020. In this instance the Transferee and Transfer Target have the same Signaling IP address on the same IMG 2020. i.e. SIP signaling between the Transferee and Transfer Target are looped back externally to the IMG 2020. In order for this type of transfer to work, the following settings must be configured accordingly:
Under the External Network Elements pane the IMG 2020 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 2020 that has the IMG 2020 listed as the groups IP Network element.
A separate Routing Table must be used as the destination address of the second and third INVITE messages (above). The messages are the same but they need to be routed to different channel groups The second INVITE to the Transfer Target and the third INVITE to the IMG 2020 itself.
Delayed Answer (SS7 to SIP -and- ISDN to SIP)
Delayed Answer (F-6179) is used in conjunction with the SIP REFER feature. In a normal SS7/ISDN to SIP call, the IMG 2020 would send an ANM/Connect message after receiving a 200 OK message and a Voice Path would be opened between the IMG 2020 and the PSTN. When the Delayed Answer functionality is enabled, the CONNECT or ANSWER message is not sent immediately. Instead, the SIP device then transfers the call to a new destination which could be either SIP, H323, or PSTN. When the transfer target answers the call the ANM/Connect message is then sent back to the original PSTN caller. This feature is used mainly to delay billing charges until the call is connected to its final destination rather than starting billing time before the call is transferred. Refer to the Call Flow diagrams below. This feature is supported in SS7 to SIP and ISDN to SIP.
Call Flows: Delayed Answer
The call flows display the Delayed answer functionality.
Delayed ANM - Enabled (SS7 to SIP)
Delayed ANM - Disabled (SS7 to SIP)
Configuration
The procedure below explains how to configure SIP Refer and Delayed Answer functionality. Before configuring the SIP Refer and Delayed Answer functions, the IMG 2020 must first have an initial or basic configuration created on it. Refer to the Basic Configurations procedure. The Basic Configurations procedure describes how to configure the basic functions required prior to configuring the SIP Refer and Delayed Answer functionality. Also, since this is utilizing the SIP protocol, a SIP signaling stack must be configured. Refer to the Configure SIP (Single SIP IP) or Configure SIP (Multiple SIP IP) for information on configuring the SIP stack.
Create a SIP Gateway Profile
Create a SIP Profile object. Within the SIP Profile object, the SIP Refer can be configured.
Right click on the Profiles object and select New SIP Profiles. The SIP Profiles object is a parent or container object. No configuration is needed here. Refer to the SIP Profiles topic for more information on this object.
Right click on the SIP Profiles object and select New SIP Profile. The first profile that gets created is a Default SIP Profile and cannot be modified. Disregard this profile.
Right click on the SIP Profiles object and select New SIP Profile again. In the SIP Profile object that appears, either enter a name that identifies this SIP Profile or accept the default name already entered. In this example the SIP Profile was labeled SIP_REFER_Profile. Refer to the SIP Profile - SGP topic for more information on configuring the remaining fields in this object.
Configure the SIP REFER functionality
Within the SIP Profile just created, configure the SIP REFER functionality
Right click on the SIP Profile object just created and select New SIP REFER Support. Enable the REFER Support functionality by selecting Enabled from the drop down menu of the REFER Support field.
In the From Header in INVITE triggered by REFER field, select either Referred-by or Original Caller. Refer to the SIP Profile - Refer Support topic.
(Optional) Configure the Delayed Answer functionality
Once the REFER Support field is enabled, and the Delayed Answer functionality can be configured. Note that Delayed Answer is supported when call is going from SS7 to SIP or ISDN to SIP.
To enable the Delayed Answer functionality, select Enabled from the drop down menu of the Delayed Answer Support field.
Once Delayed Answer Support is Enabled, select from drop down menu in the Delayed Answer Timer field the number of minutes to wait before sending the 200 OK message.
Create SIP Channel Group
Right click on the Dialogic object and select New Routing Configuration. The Routing Configuration object is a parent or container object and no configuration is required in this object. Refer to Routing Configuration topic for more information on this object.
Right click on Routing Configuration and select New Channel Groups. The Channel Groups object is a parent or container object as well which allows multiple channel groups to be created under it. No configuration required in this object either. Refer to the Channel Groups topic for more information on this object.
Right click on Channel Groups object and select New Channel Group. In the name field, either accept the default name provided or enter a name that will identify the channel group being created.
Select SIP from the drop down menu of the Signaling Type field. Refer to the Channel Group topic for more information for more information on configuring a SIP channel group.
Create an External Network Element (Gateway)
The External Network Element is the gateway that the SIP channel group just created will communicate with. Create and configure the external gateway.
Right click on the Dialogic object and select New External Network Elements. The External Network Elements object is a container object and no configuration is needed here. For more information on this object refer to the External Network Elements topic.
Right click on External Network Elements and select New External Gateways. The External Gateways object is also a container object and no configuration is needed here either. For more information on this object refer to the External Gateways topic.
Right click on External Gateways object and select New External Gateway. In the Name field, enter a name that identifies this gateway. In this procedure, REFER_GW was entered as the name
Select SIP from drop down menu in the Protocol field.
Select either Gateway IP Address or Gateway Host name from the Address Type field. In this procedure the IP Address will be how the IMG 2020 will communicate with external gateway.
Enter the IP address of the external gateway in the IP Address field.
Select the SIP Profile created earlier from the drop down menu of the Profile field . Refer to screen capture below.
Refer to the External Gateway topic for information on configuring the remaining fields in this object.
Insert External Gateway created into SIP Channel Group
Once the External Gateway is configured, it must be linked to a SIP channel group. Link the External Gateway created above to the SIP Channel group.
Right click on the SIP Channel Group created above and select New IP Network Element. In the IP Network Element field, select from the drop down menu, the external gateway just created. Refer to screen capture below.
The Channel Groups object in the configuration tree will now have a yellow exclamation point in the ICON. This indicates that the configuration has not been sent down to the IMG 2020. Click on the Channel Groups object and then click the Download Resource Tables button. The configuration will get sent and the yellow exclamation point will change to a green check mark indicating the configuration has been sent and the IMG 2020 was configured.
At this point, the Translations and Routing can be configured. Refer to the Routing Overview topic for more information on this.
Additional Information
If the SIP device transfers the call to a new destination, and the transfer target answers the call, an answer indication will be sent back to PSTN caller.
If the call transfer failed, the answer indication will not be sent back to the PSTN caller. In this case, a release message with cause code will be send back to PSTN side.
On a received SIP 200 OK, a new guard timer will be started and is canceled when the REFER is received. If no REFER is received within the interval configured in the Delayed Answer Timer field, the timer will expire and the ANM will be sent out to SS7 side.
The IMG 2020 has the ability to transfer any URI Parameters from the Transferor to the Transfer Target. The URI Parameters are passed in the outgoing INVITE message 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.
Delayed Answer is supported from TDM to SIP call direction only.
The Delayed Answer Support can be enabled only if the REFER Support is Enabled. If “REFER Support” is disabled, the user can not enable the Delayed Answer feature.
The IMG 2020 has the ability to relay custom headers received in the SIP Refer-To header and transmit them 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 is 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&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
The IMG 2020 has the ability to relay UUI headers received in the SIP Refer-To header and transmit them to the transfer target. The headers portion in the REFER-To header starts with the ? and each header is delimited by the &.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 then 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