[Home]

Summary:ASTERISK-27884: asterisk early processing the completion of the transferred call
Reporter:Nikolay (tensor)Labels:
Date Opened:2018-05-30 09:00:44Date Closed:2018-05-30 14:02:57
Priority:MajorRegression?
Status:Closed/CompleteComponents:Core/Channels
Versions:13.18.3 Frequency of
Occurrence		Constant
Related
Issues:
Environment:hardware: Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz, 4GB RAM, CentOS Linux release 7.4.1708 (Core), kernel 3.10.0-693.5.2.el7.x86_64, asterisk version is 13.18.3-certAttachments:( 0) asterisk_logs.txt
( 1) extensions.lua
( 2) features.conf
Description:1. I'm calling from extension 9702 to an external number 79201111111 through a trunk with an ISP
2. I transfer the call to the internal extension 9707 on PBX
3. After I hang up call on extension 9702, the extension h is processed twice
4. After the call is completed, the extension h is not processed
Comments:By: Asterisk Team (asteriskteam) 2018-05-30 09:00:45.140-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Richard Mudgett (rmudgett) 2018-05-30 14:02:42.418-0500

There is no bug here.  Asterisk is operating correctly.

In your [^asterisk_logs.txt] log file scenario:
* PJSIP/9702-00000015 executes dialplan to dial PJSIP/79201111111@pstn1-1 which creates channel PJSIP/pstn1-1-00000016.
* When PJSIP/pstn1-1-00000016 answers then PJSIP/9702-00000015 and PJSIP/pstn1-1-00000016 are bridged together by the dial application.
* PJSIP/9702-00000015 initiates a transfer to 9707 using the DTMF transfer feature.  Channel Local/9707@from-local-00000001;1 is bridged with PJSIP/9702-00000015.
* The other half of the local channel pair (Local/9707@from-local-00000001;2) executes dialplan to dial PJSIP/9707 which creates PJSIP/9707-00000017.
* When PJSIP/9707-00000017 answers then Local/9707@from-local-00000001;2 and PJSIP/9707-00000017 are bridged together by the dial application.
* You complete the transfer by hanging up PJSIP/9702-00000015.
* The transfer bridges PJSIP/pstn1-1-00000016 and Local/9707@from-local-00000001;1 together.
* PJSIP/9702-00000015 executes the h exten since you hung it up and it has a PBX associated with it.
* We now have this channel chain: {{PJSIP/pstn1-1-00000016 <\-> Local/9707@from-local-00000001;1 <\-> Local/9707@from-local-00000001;2 <\-> PJSIP/9707-00000017}}.
* The local channels are able to optimize themselves out of the chain.
* Local/9707@from-local-00000001;2 executes the h exten since it got optimized out of the call and it has a PBX associated with it.
* Either PJSIP/9707-00000017 or PJSIP/pstn1-1-00000016 hang up to end the call.  Since neither of these channels executed dialplan they cannot execute a h exten.

You have a misconception of when the h exten is run and which channels will execute that extension.  Only channels that have executed normal dialplan will *ever* execute the h exten since they have a PBX associated with them.  In your [^asterisk_logs.txt] log file the PJSIP/9702-00000015 and Local/9707@from-local-00000001;2 channels execute normal dialplan and will execute any h exten located in their current execution context when they hang up.

\[1] https://wiki.asterisk.org/wiki/display/AST/Hangup+Handlers
\[2] https://wiki.asterisk.org/wiki/display/AST/Local+Channel