[Home]

Summary:ASTERISK-21113: app_dial.c does not honor 'c' flag when calling party hangs up
Reporter:Heiko Wundram (modelnine)Labels:
Date Opened:2013-02-15 10:15:38.000-0600Date Closed:2013-02-22 09:42:18.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Applications/app_dial
Versions:11.2.0 11.2.1 Frequency of
Occurrence
Constant
Related
Issues:
Environment:Gentoo-built Asterisk 11.2.1Attachments:( 0) app_dial.patch
Description:app_dial.c does not honor a passed "c"-flag when dialing out and the caller hangs up. This occurs due to a possible reset of the hangupcause on the dialled outgoing channels.

Updating the hanguptree() after the out:-label in dial_exec_full to not only set up AST_CAUSE_ANSWERED_ELSEWHERE when the incoming channel signals it, but also when OPT_CANCEL_ELSEWHERE is set, fixes the issue and Call-Completed-Elsewhere is properly sent out in the Reason-header.
Comments:By: Heiko Wundram (modelnine) 2013-02-15 10:17:22.127-0600

Fix for the corresponding hanguptree() call.

By: Rusty Newton (rnewton) 2013-02-18 17:36:13.688-0600

Heiko, can you clarify the scenario that this is intended to resolve?

If the caller hangs up the channel before it has been answered, then no channel has been answered elsewhere.

By: Matt Jordan (mjordan) 2013-02-18 18:15:58.722-0600

It's one of the various Dial options:

{quote}
c - If the Dial() application cancels this call, always set the flag to tell the channel driver that the call is answered elsewhere.
{quote}

This probably got nuked in 11 via the HangupCause work.

By: Heiko Wundram (modelnine) 2013-02-19 03:18:07.064-0600

The 'c' flag, as stated by Matt Jordan, is supposed to always signal call answered elsewhere on outgoing lines, independent of the cause of the cancellation of the call. In my specific scenario, the dialing timed out or caller hung up before any of the lines were answered, but none of the endpoints got the appropriate SIP-header. The attached patch fixes that for the case that the 'c' dial flag is set.

By: Rusty Newton (rnewton) 2013-02-19 09:12:23.812-0600

Heiko - I was a bit confused by your original description (probably sleepy). Makes sense now. Thank you for taking the time to make a patch and submit it! :)