| Summary: | ASTERISK-18826: Blind Transfer failure | ||||
| Reporter: | Jac Barben (jbarben) | Labels: | |||
| Date Opened: | 2011-11-03 19:22:05 | Date Closed: | 2011-11-09 12:08:50.000-0600 | ||
| Priority: | Major | Regression? | Yes | ||
| Status: | Closed/Complete | Components: | Channels/chan_sip/General PBX/General | ||
| Versions: | 1.8.7.0 1.8.7.1 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | RHEL 4, DELL 2950 | Attachments: | ( 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 1.8.9.0-rc1 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. | ||||