DTMF Attended Transfer and BLF Attended Transfer dial plan context

My original post was here BLF attended transfers with transfer callbacks but it closed with inactivity as I was pulled back into another project at that time.

I have my custom dial plan built and tested by dialling *2 for an attended transfer, however when I move to using a BLF attended transfer, it doesnt use the same context as a dtmf *2 attended transfer. Can anyone tell me how or where I can get the BLF transfer to pick up my custom dial plan?

Hopefully this is something simple, but having looked through lots of other posts I cant see anywhere that has an answer. Some people setup BLFs and DTMF buttons but having to setup and look after two sets of buttons is not somethign we can do as we dont have enough buttons on the Sangoma 500’s, plus i’m sure the client would think it strange we cant do the same attended transfer in the BLF as by pressing *2.

I know we can do extra things in the BLF like short and long presses but I would expect an attended transfer (by whatever means, BLF or *2) to go to the same transfer_context. Can I do something funky in the basefile edit template or any other file to tweak the BLF transfer context?

I am using a new FreePBX install
Current Asterisk Version: 13.22.0

My config edit file changes -


TRANSFER_CONTEXT = custom-test_transfer


exten => _X.,1,NoOp(Entering Daves custom-test_transfer)
this is not the full dial plan, this is just to show in the logs below the noop line during a dtmf attended transfer, and that it doesnt show during a BLF attended transfer.

Logs during a DTMF Attended transfer using *2 EXT #

[2019-09-06 08:48:21] VERBOSE[5620][C-0000001e] app_dial.c: PJSIP/4001-00000038 is ringing
[2019-09-06 08:48:22] VERBOSE[5620][C-0000001e] app_dial.c: PJSIP/4001-00000038 answered IAX2/sbc3-2340
[2019-09-06 08:48:22] VERBOSE[5622][C-0000001e] bridge_channel.c: Channel PJSIP/4001-00000038 joined ‘simple_bridge’ basic-bridge <7bdc2e82-aaa2-456d-af5d-fa141463d643>
[2019-09-06 08:48:22] VERBOSE[5620][C-0000001e] bridge_channel.c: Channel IAX2/sbc3-2340 joined ‘simple_bridge’ basic-bridge <7bdc2e82-aaa2-456d-af5d-fa141463d643>
[2019-09-06 08:48:26] VERBOSE[5622][C-0000001e] bridge_basic.c: Channel PJSIP/4001-00000038: Started DTMF attended transfer.
[2019-09-06 08:48:26] VERBOSE[5622][C-0000001e] file.c: <PJSIP/4001-00000038> Playing ‘pbx-transfer.ulaw’ (language ‘en_GB’)
[2019-09-06 08:48:26] VERBOSE[5620][C-0000001e] res_musiconhold.c: Started music on hold, class ‘default’, on channel ‘IAX2/sbc3-2340’
[2019-09-06 08:48:31] VERBOSE[5625][C-0000001e] bridge_channel.c: Channel Local/[email protected]_transfer-0000004f;1 joined ‘simple_bridge’ basic-bridge <365c2d13-a28d-4c97-8987-9e82c9f6f199>
[2019-09-06 08:48:31] VERBOSE[5624][C-0000001e] pbx.c: Executing [[email protected]_transfer:1] NoOp(“Local/[email protected]_transfer-0000004f;2”, "Entering Daves custom-test_transfer") in new stack
[2019-09-06 08:48:31] VERBOSE[5624][C-0000001e] pbx.c: Executing [[email protected]_transfer:2] NoOp(“Local/[email protected]_transfer-0000004f;2”, “The caller id number before dial is: 4001”) in new stack

Logs during a BLF Attended transfer to the same extension - we dont see it picking up the custom-test_transfer

[2019-09-06 08:51:06] VERBOSE[6110][C-00000021] app_dial.c: PJSIP/4001-0000003e is ringing
[2019-09-06 08:51:08] VERBOSE[6110][C-00000021] app_dial.c: PJSIP/4001-0000003e answered IAX2/sbc3-6413
[2019-09-06 08:51:08] VERBOSE[6112][C-00000021] bridge_channel.c: Channel PJSIP/4001-0000003e joined ‘simple_bridge’ basic-bridge <4b2ab841-5127-458d-92f1-be575877046f>
[2019-09-06 08:51:08] VERBOSE[6110][C-00000021] bridge_channel.c: Channel IAX2/sbc3-6413 joined ‘simple_bridge’ basic-bridge <4b2ab841-5127-458d-92f1-be575877046f>
[2019-09-06 08:51:13] VERBOSE[6110][C-00000021] res_musiconhold.c: Started music on hold, class ‘default’, on channel ‘IAX2/sbc3-6413’
[2019-09-06 08:51:13] VERBOSE[15638] pbx_variables.c: Setting global variable ‘SIPDOMAIN’ to ‘servername.domain.co.uk
[2019-09-06 08:51:13] VERBOSE[15638] netsock2.c: Using SIP RTP Audio TOS bits 184
[2019-09-06 08:51:13] VERBOSE[15638] netsock2.c: Using SIP RTP Audio TOS bits 184 in TCLASS field.
[2019-09-06 08:51:13] VERBOSE[15638] netsock2.c: Using SIP RTP Audio CoS mark 5
[2019-09-06 08:51:13] VERBOSE[6113][C-00000022] pbx.c: Executing [[email protected]:1] GotoIf(“PJSIP/4001-0000003f”, “1?ext-local,4000,1:followme-check,4000,1”) in new stack
[2019-09-06 08:51:13] VERBOSE[6113][C-00000022] pbx_builtins.c: Goto (ext-local,4000,1)
[2019-09-06 08:51:13] VERBOSE[6113][C-00000022] pbx.c: Executing [[email protected]:1] Set(“PJSIP/4001-0000003f”, “__RINGTIMER=30”) in new stack
[2019-09-06 08:51:13] VERBOSE[6113][C-00000022] pbx.c: Executing [[email protected]:2] Macro(“PJSIP/4001-0000003f”, “exten-vm,4000,4000,0,0,0”) in new stack
[2019-09-06 08:51:13] VERBOSE[6113][C-00000022] pbx.c: Executing [[email protected]:1] Macro(“PJSIP/4001-0000003f”, “user-callerid,”) in new stack

Thanks for your help,

That’s simple. The BLF buttons of phones don’t do In-Call feature dialing. They do this the traditional way which is to put the existing call on hold and then dial a new call. Or they could do blind transfer and just send the call. Either way it’s the standard method of doing transfers.

Hi Tom,
Thanks for the info, I am a bit of a newbie with dialplan etc, but learning fast.
So do you mean I need to put my code in somewhere like
[from-internal-noxfer] or from-internal-noxfer-custom
[from-internal-xfer] or from-internal-custom

I tried some of these but now understanding the code a bit more, it caused a loop.

I am trying some new contexts and code to see what I can get, but essentially are you telling me a BLF transfer just works like a normal call so we cant do any dial plan specific to it. Even if we locked down the dialplan code to internal extensions, it would mean all calls to other extensions would read this dial plan, wether its a transfer or a call.

We only want this dialplan to happen during an attended BLF transfer after the initiator has set down the phone. Does this put the call leg into a dial plan context we can use?


I have managed to get a bit of a work around by linking to my custom dialplan as a custom destination, and having the custom destination as the extensions unavailable destination.

The next workaround to look at is how to transfer direct to voicemail via BLF but I feel this might be the holy grail considering the client doesnt want to have to learn extension numbers nor use a web page etc.

If anyone has any suggestions it would be great to hear them.

Update -
Rather than using the custom destination of the extensions I have managed to use Short and Long presses to look at different dial plan contexts.

During my dial plan for the BLF LongPress it dials the extension with a short 4 second time out, before going to the unattended voicemail. As the BLF transfer in this PBX template is an attended transfer, I am looking to find out if there is a dialplan code to either change to a blind transfer or hang up the operator leg automatically which ends the attended transfer?

I currently have this code below,

exten => _LPX.,1,Set(timeoutd=4) ; set timeout in seconds
exten => _LPX.,n,Dial(Local/${EXTEN:2}@from-internal,${timeoutd})
exten => _LPX.,n,VoiceMail(${EXTEN:2},u)
exten => _LPX.,n,Hangup

I inject LP into the extension by the LongPress in EndpointManager which is why I need to remove the first two digits with EXTEN:2


The phones BLF button capabilities is the phones not the PBX. You can choose to make the BLF have multiple functions (Speed Dial, Transfer, Call Pickup, etc) but those are based on the phone.

Any form of a transfer (attended or blind) not done using In-Call feature codes will make the phone put the active call on hold and then dial the new call then it will REFER the held line to the open line. So the only time a transfer is handled at the PBX like what you are looking for is with In-Call features (DTMF) otherwise the phones transfer abilities are done at the phone level.

Hi Tom, I will keep it as is and let the operator just hang up after the long press has been performed.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.