Ticket #4148 (closed Bugs: fixed)

Opened 2 years ago

Last modified 2 years ago

Transfers aren't hung up due to dial status ANSWER

Reported by: rsw686 Assigned to: p_lindheimer
Priority: major Milestone: 2.8
Component: Core Version: 2.7-branch
Keywords: Cc:
Confirmation: Unreviewed SVN Revision (if applicable):
Backend Engine: All Backend Engine Version:

Description

When a blind transfer is initiated by the calling party Dial() returns with dial status ANSWER. The result is dial plan execution continues even though the calling party should have been hung up on.

I reported this bug in #4053. macro-dialout-trunk and macro-dialout-enum where corrected in r8930. However I just noticed the issue is still present in macro-dial.

[Mar 18 16:35:05] VERBOSE[9856] pbx.c: -- Executing [s@macro-dial:8] Set("SIP/1500-000014b6", "DIALSTATUS=ANSWER") in new stack

To reproduce this take three extension 1001, 1002, 1003.

1001 calls 1002

1001 blind transfers the call to 1003

1002 and 1003 are connected

1001 isn't hung up on

Change History

03/18/10 22:42:06 changed by rsw686

Found the following issue report on Asterisk where they state that while this appears to be a bug it may be a feature for some people. It looks like it will be fixed in trunk for future branches.

https://issues.asterisk.org/view.php?id=17009

03/19/10 01:00:18 changed by p_lindheimer

sounds like a warped perspective unless I am missing something. This has never been the standard behavior in the past. They introduce a bug in 1.6 creating this new behavior. They then say that it is a feature to some people who may be depending on it even though it broke existing dialplan from previous releases (e.g. FreePBX which has hundreds of thousands of installations all of a sudden breaks). So they are going to leave it broken, but still turn around and "fix" it in 1.8 thus breaking everyone who is depending on it when they migrate to 1.8?

If what I just said was accurate, then you may want to go comment on their ticket that their actions and behavior make no sense what so ever and they should be fixing the bug they introduced, wasn't there in the past, and thus should be put back vs. just waiting until 1.8 to go fix those few people...

03/19/10 07:19:23 changed by rsw686

Well this happened at the end of the 1.4 branch and looks to be in 1.6.0, 1.6.1, and 1.6.2. I'm going to suggest that they add a setting so this behavior can be turned on or off. I guess having the ANSWER status could be useful for playing a transfer completed message.

03/19/10 09:51:53 changed by p_lindheimer

sounds good, you should suggest that the setting keep the old behavior, otherwise they completely violate their own rules of changing exiting behavior mid-stream. Not that we won't look at working around their changed behavior anyhow but you can make the argument to them that the changed behavior they have introduced has broken hundreds of thousands of existing installs, amongst them many being AsteriskNOW...

03/19/10 16:43:53 changed by p_lindheimer

  • status changed from new to closed.
  • resolution set to fixed.

(In [9288]) closes #4148 work around Asterisk bug returning transferer to dialplan since it is present in several reelases

03/19/10 16:52:47 changed by p_lindheimer

(In [9290]) Merged revisions 9253-9289 via svnmerge from http://svn.freepbx.org/modules/branches/2.7

................

r9282 | mickecarlsson | 2010-03-18 14:48:59 -0700 (Thu, 18 Mar 2010) | 9 lines

Merged revisions 9279 via svnmerge from http://svn.freepbx.org/modules/branches/2.8

........

r9279 | mickecarlsson | 2010-03-18 22:06:12 +0100 (Thu, 18 Mar 2010) | 1 line

Removed dbug from language module

........

................

r9288 | p_lindheimer | 2010-03-19 14:43:52 -0700 (Fri, 19 Mar 2010) | 1 line

closes #4148 work around Asterisk bug returning transferer to dialplan since it is present in several reelases

................

r9289 | p_lindheimer | 2010-03-19 14:44:41 -0700 (Fri, 19 Mar 2010) | 1 line

update module.xml

................

03/19/10 17:24:30 changed by rsw686

It looks like ANSWER,1 is not going to execute unless call screening is set.

exten => s,n,GosubIf?($["${SCREEN}" != ""]?${DIALSTATUS},1)

I think the following line should be added above the call screening check.

exten => s,n,GotoIf?($[ "${DIALSTATUS}" = "ANSWER" ]?ANSWER,1)