Summary:ASTERISK-18826: Blind Transfer failure
Reporter:Jac Barben (jbarben)Labels:
Date Opened:2011-11-03 19:22:05Date Closed:2011-11-09 12:08:50.000-0600
Status:Closed/CompleteComponents:Channels/chan_sip/General PBX/General
Versions: Frequency of
is related toASTERISK-18685 Half Attended Transfers ("Blind Transfers") Fail for No Apparent Reason
Environment:RHEL 4, DELL 2950Attachments:( 0) transfer_failure.log.txt
Description:Blind transfer fails predictably between legs C and D.
Inbound (leg A) calls subscriber (leg B) subscriber transfers to another subscriber (leg C) this transfer *works* "most of the time".  Subscriber (leg C) transfers to another subscriber (leg D) transfer *fails* 100% of the time.
Comments:By: Jac Barben (jbarben) 2011-11-03 19:24:22.305-0500

Attached is transfer_failure.log.txt (full output with core debug 10 core verbose 10 sip debug on)

By: Jac Barben (jbarben) 2011-11-03 19:26:31.488-0500

What is interesting is that chan_sip seems to acknowledge the tranfer.  The PBX seems to be trying to execute the next blind transfer context but abandons the effort at priority 2.

By: Jac Barben (jbarben) 2011-11-09 12:08:50.106-0600

This turned out to be a user logic problem in the transfer context that was somehow ignored in previous versions of Asterisk.

By: Luke H (luckman212) 2012-01-08 00:40:02.598-0600

Jac I am having a very similar problem now with one Asterisk system (running FreePBX).   Would you be kind enough to share what the "logic problem" was that you were able to solve?  I am trying to narrow down the source of the problem but as FreePBX does some funny things with dialplan it makes it more difficult.