Problems with Blind Transfer [solved]

General Help
1

Hi,

I am running Asterisk 1.4.21.2 and FreePBX 2.4.1.1 and I cannot perform any blind transfers.
Hitting ## I hear the “transfer”, then I enter the extension. The person being transferred then hears “This call cannot be completed as dialed…”

Regular transfers work fine without a problem. I have tried disabling the ‘##’ in feature codes as well as ‘#’ for the directory, so it uses the native asterisk transfer. I have tTr in dial command options and tT in outbound dial command options.

In trying to look at the logs, it appears that the call is being hung up first and not transferred.

I saw some posts from last year relating to 1.4.13 but I would have assumed this was fixed by now in Asterisk?
Has anybody come across this?

Any suggestions on what to look for or what I am missing?

Thanks

M

Here is a call from ext 302 to ext 301 and 301 attempting to transfer to ext 122. All extensions exist on physical phones.

dialparties.agi: Methodology of ring is  'none'
    --  dialparties.agi: Added extension 301 to extension map
    --  dialparties.agi: Extension 301 cf is disabled
    --  dialparties.agi: Extension 301 do not disturb is disabled
       >  dialparties.agi: extnum 301 has:  cw: 1; hascfb: 0 [] hascfu: 0 []
       >  dialparties.agi: ExtensionState: 0
    --  dialparties.agi: dbset CALLTRACE/301 to 302
    --  dialparties.agi: Filtered ARG3: 301
  == Manager 'admin' logged off from 127.0.0.1
    -- AGI Script dialparties.agi completed, returning 0
    -- Executing [s@macro-dial:7] Dial("SIP/302-095fdbf0", "SIP/301|15|tTr") in new stack
    -- Called 301
    -- SIP/301-09606ec8 is ringing
    -- SIP/301-09606ec8 answered SIP/302-095fdbf0
    -- Started music on hold, class 'default', on SIP/302-095fdbf0
    -- <SIP/301-09606ec8> Playing 'pbx-transfer' (language 'en')
    -- Stopped music on hold on SIP/302-095fdbf0
  == Channel 'SIP/302-095fdbf0' jumping out of macro 'dial'
  == Channel 'SIP/302-095fdbf0' jumping out of macro 'exten-vm'
    -- Executing [122@from-internal-xfer:1] ResetCDR("SIP/302-095fdbf0", "") in new stack
    -- Executing [122@from-internal-xfer:2] NoCDR("SIP/302-095fdbf0", "") in new stack
    -- Executing [122@from-internal-xfer:3] Wait("SIP/302-095fdbf0", "1") in new stack
  == Parsing '/etc/asterisk/manager.conf': Found
  == Parsing '/etc/asterisk/manager_additional.conf': Found
  == Parsing '/etc/asterisk/manager_custom.conf': Found
  == Manager 'admin' logged on from 127.0.0.1
  == Manager 'admin' logged off from 127.0.0.1
    -- Executing [122@from-internal-xfer:4] Playback("SIP/302-095fdbf0", "silence/1&cannot-complete-as-dialed&check-number-dial-again|noanswer") in new stack
    -- <SIP/302-095fdbf0> Playing 'silence/1' (language 'en')
    -- <SIP/302-095fdbf0> Playing 'cannot-complete-as-dialed' (language 'en')
  == Parsing '/etc/asterisk/manager.conf': Found
  == Parsing '/etc/asterisk/manager_additional.conf': Found
  == Spawn extension (from-internal-xfer, 122, 4) exited non-zero on 'SIP/302-095fdbf0'
  == Parsing '/etc/asterisk/manager_custom.conf':     -- Executing [h@from-internal-xfer:1] Macro("SIP/302-095fdbf0", "hangupcall") in new stack
Foundst*CLI>
    -- Executing [s@macro-hangupcall:1] ResetCDR("SIP/302-095fdbf0", "w") in new stack
2

Check your log file for any "ERROR"s at the time of the transfer. This smells very much like: #3092 although in that case, the use of Asterisk ‘#’ transfer was immune to the issue. The related bug cross referenced in #3092 is:

http://bugs.digium.com/bug_view_advanced_page.php?bug_id=13363

where I have a patch that fixes the problem, but the patch has potential for issues so the bug is still open with Digium waiting for a proper fix. (Assuming this is related to the same thing).

3

Thanks for the response.

I didn’t think it was the bug you were referring to as this happened on the first attempt to blind transfer and the bug appears to reference many macro calls.

In the end I found two sections called [from-internal-custom] in my extensions_custom.conf (second one placed there by a reminder script automatically). This obviously caused some confusion in the dialplan and the call was being hung up at the transfer.

It was interesting that the issue didn’t show up anywhere else as everything else worked.

Thanks

M