Handle incoming REFER request

REFER is used for call transfer in SIP. We get a REFER to place a new call with an INVITE somwhere and then keep the transferor up-to-date of the transfer. If the transfer fails, get back on line with the orginal call.

• REFER can be sent outside or inside of a dialog. Asterisk only accepts REFER inside of a dialog.
• If we get a replaces header, it is an attended transfer

Blind transfers

The transferor provides the transferee with the transfer targets contact. The signalling between transferer or transferee should not be cancelled, so the call is recoverable if the transfer target can not be reached by the transferee.

In this case, Asterisk receives a TRANSFER from the transferor, thus is the transferee. We should try to set up a call to the contact provided and if that fails, re-connect the current session. If the new call is set up, we issue a hangup. In this scenario, we are following section 5.2 in the SIP CC Transfer draft. (Transfer without a GRUU)

Transfer with consultation hold

In this case, the transferor talks to the transfer target before the transfer takes place. This is implemented with SIP hold and transfer. Note: The invite From: string could indicate a transfer. (Section 6. Transfer with consultation hold) The transferor places the transferee on hold, starts a call with the transfer target to alert them to the impending transfer, terminates the connection with the target, then proceeds with the transfer (as in Blind transfer above)

Attended transfer

The transferor places the transferee on hold, calls the transfer target to alert them, places the target on hold, then proceeds with the transfer using a Replaces header field in the Refer-to header. This will force the transfee to send an Invite to the target, with a replaces header that instructs the target to hangup the call between the transferor and the target. In this case, the Refer/to: uses the AOR address. (The same URI that the transferee used to establish the session with the transfer target (To: ). The Require: replaces header should be in the INVITE to avoid the wrong UA in a forked SIP proxy scenario to answer and have no call to replace with.

The referred-by header is NOT required, but if we get it, can be copied into the INVITE to the transfer target to inform the target about the transferor

"Any REFER request has to be appropriately authenticated.".

We can't destroy dialogs, since we want the call to continue.