ASTERISK-15731: Call that clears in same app_dial poll as answer is reported as NOANSWER but NORMAL

[Home]

Summary: ASTERISK-15731: Call that clears in same app_dial poll as answer is reported as NOANSWER but NORMAL_CLEARING

Reporter: David Woolley (davidw) Labels:

Date Opened: 2010-03-02 13:54:16.000-0600 Date Closed: 2011-05-19 14:38:20

Priority: Minor Regression? No

Status: Closed/Complete Components: Applications/app_dial

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments:

Description: If a call clears so fast after being answered that app_dial fails to read a frame before it realises it has been answered, handle_cause breaks from its switch and does not increment any of its failure reason counters. The call ends up with a "No one is available to answer at this time (1:0/0/0)" message logged, the default DIALSTATUS of NOANSWER and a HANGUPCAUSE of 16 (AST_CAUSE_NORMAL_CLEARING).

If it clears just slightly later, it is treated as a successful, if short call (that's why it is "sometimes", not "always".

The variablility in the result, depending on precise timing is confusing, and NOANSWER does not seem an appropriate status.

****** ADDITIONAL INFORMATION ******

I cannot find this variation reported before, but when other "No one is available" conditions were found in the past, the resolution was to convert them to CONGESTION. I'm not sure that that is right here, although it is easier than ensuring that they are treated as a short, successful call.

(Actually, there is some benefit for us if these error, as they are more common than very short calls that are long enough for Dial to succeed.)

The actual scenario is trying to dial an invalid number on a Philips IS3000 and we suspect what is happening is that it is answering and then discovering there is no free tone generator to use to send NU tone.

This is an abstract of the SIP trace for the call, mainly to demonstrate the timing - the actual mechanism can be seen from the source code:

[2010-03-01 15:11:21.062] VERBOSE[16034] chan_sip.c: Reliably Transmitting (no NAT) to x.x.x.x:5060:
INVITE sip:7900@1x.x.x.x SIP/2.0

[2010-03-01 15:11:21.286] VERBOSE[21738] chan_sip.c:
<--- SIP read from UDP://x.x.x.x:5060 --->
SIP/2.0 100 Trying

[2010-03-01 15:11:21.286] VERBOSE[21738] chan_sip.c:
<--- SIP read from UDP://x.x.x.x:5060 --->
SIP/2.0 200 OK

[2010-03-01 15:11:21.287] VERBOSE[21738] chan_sip.c: Transmitting (no NAT) to x.x.x.x:5060:
ACK sip:7900@x.x.x.x:5060 SIP/2.0

[2010-03-01 15:11:21.287] VERBOSE[21738] chan_sip.c:
<--- SIP read from UDP://x.x.x.x:5060 --->
BYE sip:5399@10.17.200.153 SIP/2.0

[2010-03-01 15:11:21.287] VERBOSE[21738] chan_sip.c:
<--- Transmitting (no NAT) to x.x.x.x:5060 --->
SIP/2.0 200 OK

[2010-03-01 15:11:21.288] VERBOSE[16034] app_dial.c: -- No one is available to answer at this time (1:0/0/0)

Comments: By: John Todd (jtodd) 2010-03-03 13:38:08.000-0600

Good catch.
By: Digium Subversion (svnbot) 2010-10-13 17:45:16

Repository: asterisk
Revision: 291577

U branches/1.4/main/channel.c

------------------------------------------------------------------------
r291577 | twilson | 2010-10-13 17:45:16 -0500 (Wed, 13 Oct 2010) | 19 lines

Don't ignore frames that have been queued when softhangup'd

When an outgoing call is answered and hung up by the far end *very* quickly, we
may not read any frames and therefor end up with a call that displays the wrong
disposition/DIALSTATUS. The reason is because ast_queue_hangup() immediately
sets the _softhangup flag on the channel and then queues the HANGUP control
frame, but __ast_read refuses to read any frames if ast_check_hangup() indicates
that a hangup request has been made (which it will if _softhangup is set). So,
we end up losing control frames.

This change makes __ast_read continue to read frames even if a soft hangup has
been requested. It queues a hangup frame to make sure that __ast_read() will
still eventually return NULL.

(closes issue ASTERISK-15731)
Reported by: davidw

Review: https://reviewboard.asterisk.org/r/740/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=291577
By: Digium Subversion (svnbot) 2010-10-13 17:47:16

Repository: asterisk
Revision: 291577

U branches/1.4/main/channel.c

------------------------------------------------------------------------
r291577 | twilson | 2010-10-13 17:45:15 -0500 (Wed, 13 Oct 2010) | 21 lines

Don't ignore frames that have been queued when softhangup'd

When an outgoing call is answered and hung up by the far end *very* quickly, we
may not read any frames and therefor end up with a call that displays the wrong
disposition/DIALSTATUS. The reason is because ast_queue_hangup() immediately
sets the _softhangup flag on the channel and then queues the HANGUP control
frame, but __ast_read refuses to read any frames if ast_check_hangup() indicates
that a hangup request has been made (which it will if _softhangup is set). So,
we end up losing control frames.

This change makes __ast_read continue to read frames even if a soft hangup has
been requested. It queues a hangup frame to make sure that __ast_read() will
still eventually return NULL.

Much thanks to David Vossel for all of the reviews, discussion, and help!

(closes issue ASTERISK-15731)
Reported by: davidw

Review: https://reviewboard.asterisk.org/r/740/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=291577
By: Digium Subversion (svnbot) 2010-10-13 17:58:44

Repository: asterisk
Revision: 291580

_U branches/1.6.2/
U branches/1.6.2/main/channel.c

------------------------------------------------------------------------
r291580 | twilson | 2010-10-13 17:58:44 -0500 (Wed, 13 Oct 2010) | 28 lines

Merged revisions 291577 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r291577 | twilson | 2010-10-13 15:45:15 -0700 (Wed, 13 Oct 2010) | 21 lines

Don't ignore frames that have been queued when softhangup'd

When an outgoing call is answered and hung up by the far end *very* quickly, we
may not read any frames and therefor end up with a call that displays the wrong
disposition/DIALSTATUS. The reason is because ast_queue_hangup() immediately
sets the _softhangup flag on the channel and then queues the HANGUP control
frame, but __ast_read refuses to read any frames if ast_check_hangup() indicates
that a hangup request has been made (which it will if _softhangup is set). So,
we end up losing control frames.

This change makes __ast_read continue to read frames even if a soft hangup has
been requested. It queues a hangup frame to make sure that __ast_read() will
still eventually return NULL.

Much thanks to David Vossel for all of the reviews, discussion, and help!

(closes issue ASTERISK-15731)
Reported by: davidw

Review: https://reviewboard.asterisk.org/r/740/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=291580
By: Digium Subversion (svnbot) 2010-10-13 18:01:57

Repository: asterisk
Revision: 291581

_U branches/1.8/
U branches/1.8/main/channel.c

------------------------------------------------------------------------
r291581 | twilson | 2010-10-13 18:01:57 -0500 (Wed, 13 Oct 2010) | 35 lines

Merged revisions 291580 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
r291580 | twilson | 2010-10-13 15:58:43 -0700 (Wed, 13 Oct 2010) | 28 lines

Merged revisions 291577 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r291577 | twilson | 2010-10-13 15:45:15 -0700 (Wed, 13 Oct 2010) | 21 lines

Don't ignore frames that have been queued when softhangup'd

When an outgoing call is answered and hung up by the far end *very* quickly, we
may not read any frames and therefor end up with a call that displays the wrong
disposition/DIALSTATUS. The reason is because ast_queue_hangup() immediately
sets the _softhangup flag on the channel and then queues the HANGUP control
frame, but __ast_read refuses to read any frames if ast_check_hangup() indicates
that a hangup request has been made (which it will if _softhangup is set). So,
we end up losing control frames.

This change makes __ast_read continue to read frames even if a soft hangup has
been requested. It queues a hangup frame to make sure that __ast_read() will
still eventually return NULL.

Much thanks to David Vossel for all of the reviews, discussion, and help!

(closes issue ASTERISK-15731)
Reported by: davidw

Review: https://reviewboard.asterisk.org/r/740/
........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=291581
By: Digium Subversion (svnbot) 2010-10-13 18:47:11

Repository: asterisk
Revision: 291657

_U trunk/
U trunk/main/channel.c

------------------------------------------------------------------------
r291657 | twilson | 2010-10-13 18:47:11 -0500 (Wed, 13 Oct 2010) | 42 lines

Merged revisions 291581 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
r291581 | twilson | 2010-10-13 16:01:56 -0700 (Wed, 13 Oct 2010) | 35 lines

Merged revisions 291580 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
r291580 | twilson | 2010-10-13 15:58:43 -0700 (Wed, 13 Oct 2010) | 28 lines

Merged revisions 291577 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r291577 | twilson | 2010-10-13 15:45:15 -0700 (Wed, 13 Oct 2010) | 21 lines

Don't ignore frames that have been queued when softhangup'd

When an outgoing call is answered and hung up by the far end *very* quickly, we
may not read any frames and therefor end up with a call that displays the wrong
disposition/DIALSTATUS. The reason is because ast_queue_hangup() immediately
sets the _softhangup flag on the channel and then queues the HANGUP control
frame, but __ast_read refuses to read any frames if ast_check_hangup() indicates
that a hangup request has been made (which it will if _softhangup is set). So,
we end up losing control frames.

This change makes __ast_read continue to read frames even if a soft hangup has
been requested. It queues a hangup frame to make sure that __ast_read() will
still eventually return NULL.

Much thanks to David Vossel for all of the reviews, discussion, and help!

(closes issue ASTERISK-15731)
Reported by: davidw

Review: https://reviewboard.asterisk.org/r/740/
........
................
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=291657
By: Digium Subversion (svnbot) 2010-11-22 12:46:28.000-0600

Repository: asterisk
Revision: 295790

U branches/1.4/apps/app_macro.c
U branches/1.4/include/asterisk/channel.h
U branches/1.4/include/asterisk/frame.h
U branches/1.4/main/channel.c
U branches/1.4/main/pbx.c

------------------------------------------------------------------------
r295790 | rmudgett | 2010-11-22 12:46:27 -0600 (Mon, 22 Nov 2010) | 46 lines

The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.

To recreate the problem:
1) Party A calls Party B
2) Invoke CLI "channel redirect" command to redirect channel call leg
associated with A.
3) All associated channels are hung up.

Note that if the CLI command were done on the channel call leg associated
with B it works.

This regression was a result of the fix for issue ASTERISK-15731
(https://reviewboard.asterisk.org/r/740/).

The regression affects all features that use an async goto to execute the
dialplan because of an external event: Channel redirect, AMI redirect, SIP
REFER, and FAX detection.

The struct ast_channel._softhangup code is a mess. The variable is used
for several purposes that do not necessarily result in the call being hung
up. I have added doxygen comments to describe how the various _softhangup
bits are used. I have corrected all the places where the variable was
tested in a non-bit oriented manner.

The primary fix is the new AST_CONTROL_END_OF_Q frame. It acts as a weak
hangup request so the soft hangup requests that do not normally result in
a hangup do not hangup.

JIRA SWP-2470
JIRA SWP-2489

(closes issue ASTERISK-16838)
Reported by: SantaFox
(closes issue ASTERISK-16847)
Reported by: kwemheuer
(closes issue ASTERISK-16873)
Reported by: zahir_koradia
(closes issue ASTERISK-16891)
Reported by: vmarrone
(closes issue ASTERISK-16950)
Reported by: mbrevda
(closes issue ASTERISK-16972)
Reported by: nerbos

Review: https://reviewboard.asterisk.org/r/1013/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=295790
By: Digium Subversion (svnbot) 2010-11-22 13:28:28.000-0600

Repository: asterisk
Revision: 295843

_U branches/1.6.2/
U branches/1.6.2/apps/app_macro.c
U branches/1.6.2/include/asterisk/channel.h
U branches/1.6.2/include/asterisk/frame.h
U branches/1.6.2/main/channel.c
U branches/1.6.2/main/pbx.c

------------------------------------------------------------------------
r295843 | rmudgett | 2010-11-22 13:28:27 -0600 (Mon, 22 Nov 2010) | 53 lines

Merged revisions 295790 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines

The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.

To recreate the problem:
1) Party A calls Party B
2) Invoke CLI "channel redirect" command to redirect channel call leg
associated with A.
3) All associated channels are hung up.

Note that if the CLI command were done on the channel call leg associated
with B it works.

This regression was a result of the fix for issue ASTERISK-15731
(https://reviewboard.asterisk.org/r/740/).

The regression affects all features that use an async goto to execute the
dialplan because of an external event: Channel redirect, AMI redirect, SIP
REFER, and FAX detection.

The struct ast_channel._softhangup code is a mess. The variable is used
for several purposes that do not necessarily result in the call being hung
up. I have added doxygen comments to describe how the various _softhangup
bits are used. I have corrected all the places where the variable was
tested in a non-bit oriented manner.

The primary fix is the new AST_CONTROL_END_OF_Q frame. It acts as a weak
hangup request so the soft hangup requests that do not normally result in
a hangup do not hangup.

JIRA SWP-2470
JIRA SWP-2489

(closes issue ASTERISK-16838)
Reported by: SantaFox
(closes issue ASTERISK-16847)
Reported by: kwemheuer
(closes issue ASTERISK-16873)
Reported by: zahir_koradia
(closes issue ASTERISK-16891)
Reported by: vmarrone
(closes issue ASTERISK-16950)
Reported by: mbrevda
(closes issue ASTERISK-16972)
Reported by: nerbos

Review: https://reviewboard.asterisk.org/r/1013/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=295843
By: Digium Subversion (svnbot) 2010-11-22 13:36:11.000-0600

Repository: asterisk
Revision: 295866

_U branches/1.8/
U branches/1.8/apps/app_macro.c
U branches/1.8/include/asterisk/channel.h
U branches/1.8/include/asterisk/frame.h
U branches/1.8/main/channel.c
U branches/1.8/main/pbx.c

------------------------------------------------------------------------
r295866 | rmudgett | 2010-11-22 13:36:11 -0600 (Mon, 22 Nov 2010) | 60 lines

Merged revisions 295843 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
r295843 | rmudgett | 2010-11-22 13:28:23 -0600 (Mon, 22 Nov 2010) | 53 lines

Merged revisions 295790 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines

The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.

To recreate the problem:
1) Party A calls Party B
2) Invoke CLI "channel redirect" command to redirect channel call leg
associated with A.
3) All associated channels are hung up.

Note that if the CLI command were done on the channel call leg associated
with B it works.

This regression was a result of the fix for issue ASTERISK-15731
(https://reviewboard.asterisk.org/r/740/).

The regression affects all features that use an async goto to execute the
dialplan because of an external event: Channel redirect, AMI redirect, SIP
REFER, and FAX detection.

The struct ast_channel._softhangup code is a mess. The variable is used
for several purposes that do not necessarily result in the call being hung
up. I have added doxygen comments to describe how the various _softhangup
bits are used. I have corrected all the places where the variable was
tested in a non-bit oriented manner.

The primary fix is the new AST_CONTROL_END_OF_Q frame. It acts as a weak
hangup request so the soft hangup requests that do not normally result in
a hangup do not hangup.

JIRA SWP-2470
JIRA SWP-2489

(closes issue ASTERISK-16838)
Reported by: SantaFox
(closes issue ASTERISK-16847)
Reported by: kwemheuer
(closes issue ASTERISK-16873)
Reported by: zahir_koradia
(closes issue ASTERISK-16891)
Reported by: vmarrone
(closes issue ASTERISK-16950)
Reported by: mbrevda
(closes issue ASTERISK-16972)
Reported by: nerbos

Review: https://reviewboard.asterisk.org/r/1013/
........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=295866
By: Digium Subversion (svnbot) 2010-11-22 13:42:04.000-0600

Repository: asterisk
Revision: 295867

_U trunk/
U trunk/apps/app_macro.c
U trunk/include/asterisk/channel.h
U trunk/include/asterisk/frame.h
U trunk/main/channel.c
U trunk/main/pbx.c

------------------------------------------------------------------------
r295867 | rmudgett | 2010-11-22 13:42:03 -0600 (Mon, 22 Nov 2010) | 67 lines

Merged revisions 295866 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
r295866 | rmudgett | 2010-11-22 13:36:10 -0600 (Mon, 22 Nov 2010) | 60 lines

Merged revisions 295843 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
r295843 | rmudgett | 2010-11-22 13:28:23 -0600 (Mon, 22 Nov 2010) | 53 lines

Merged revisions 295790 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines

The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.

To recreate the problem:
1) Party A calls Party B
2) Invoke CLI "channel redirect" command to redirect channel call leg
associated with A.
3) All associated channels are hung up.

Note that if the CLI command were done on the channel call leg associated
with B it works.

This regression was a result of the fix for issue ASTERISK-15731
(https://reviewboard.asterisk.org/r/740/).

The regression affects all features that use an async goto to execute the
dialplan because of an external event: Channel redirect, AMI redirect, SIP
REFER, and FAX detection.

The struct ast_channel._softhangup code is a mess. The variable is used
for several purposes that do not necessarily result in the call being hung
up. I have added doxygen comments to describe how the various _softhangup
bits are used. I have corrected all the places where the variable was
tested in a non-bit oriented manner.

The primary fix is the new AST_CONTROL_END_OF_Q frame. It acts as a weak
hangup request so the soft hangup requests that do not normally result in
a hangup do not hangup.

JIRA SWP-2470
JIRA SWP-2489

(closes issue ASTERISK-16838)
Reported by: SantaFox
(closes issue ASTERISK-16847)
Reported by: kwemheuer
(closes issue ASTERISK-16873)
Reported by: zahir_koradia
(closes issue ASTERISK-16891)
Reported by: vmarrone
(closes issue ASTERISK-16950)
Reported by: mbrevda
(closes issue ASTERISK-16972)
Reported by: nerbos

Review: https://reviewboard.asterisk.org/r/1013/
........
................
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=295867