Review Board 1.7.16

Convert SIP blind transfer code to use core bridging API

Review Request #2495 - Created May 3, 2013 and submitted

Mark Michelson
This change set converts chan_sip to use the ast_bridge_transfer_blind() API call in order to perform blind transfers and remote attended transfers.

The majority of this change is stripping logic out of chan_sip that is performed in the core now. The following has all been removed since it is intended to be done in the bridging core now:

1. Checks to ensure that the channel is bridged/is in a state where transfers can be performed.
2. Any and all parking-related code
3. Setting of the BLINDTRANSFER channel variable on involved channels
4. CEL events and manager events

SIP blind transfers and remote attended transfers are still functional. There are some differences between how things previously worked and how they currently work

1. Previously, an unbridged channel would reject a REFER request. Now we accept the REFER but send a SIP NOTIFY with sipfrag indicating the transfer failed.
2. Some SIP history entries will be different since some processing has been moved to the core. For instance, SIP will not be aware that a transfer to parking occurred, so no such history is logged.
3. Previously, channel variables were set on the transferee channel. The clear intention of this was so that when the transferee channel was moved or masqueraded, the variables would be available in the dialplan where the new call was to be made. chan_sip does not have access to the transferee channel now, so instead, it registers a callback to set channel variables on the channel that will end up running dialplan.
4. HOLD and UNHOLD frames are not sent to the transferee during a blind transfer. This is done for two reasons. One, the transferee is likely already on hold. Two, the gap between these hold and unhold frames was miniscule and didn't really seem to be there for any purpose.
Ran several blind transfers both to valid and invalid extensions, and attempted to transfer unbridged calls.

Transfers to a valid extension worked perfectly.
Transfers of a bridged call to an invalid extension resulted in the call staying up between the two parties and audio passing properly.
Transfers of an unbridged call to any extension resulted in the call staying up, with audio still present.

Signaling was also correct in all situations.
Review request changed
Updated (May 10, 2013, 9:40 a.m.)
  • changed from pending to submitted
Committed in revision 388309 runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to