Summary:	ASTERISK-27749: DIALSTATUS inconsistent
Reporter:	Frederic Steinfels (fredo)	Labels:	pjsip
Date Opened:	2018-03-19 10:17:33	Date Closed:	2018-04-02 06:49:50
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_dial
Versions:	15.2.2	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) dailtwice.txt ( 1) dialonce.txt
Description:	Please consider these three scenarios: Scenario 1: Dial(PJSIP/blabla) Scenario 2: Dial(Local/abc@default) [default] abc,s,1 => Dial(PJSIP/blabla) Scenario 3: Dial(Local/abc@default) [default] abc,s,1 => Dial(Local/xyz@default) xyz,s,1 => Dial(PJSIP/blabla) blabla is a mobile phone where I am pressing the red button when the call comes in (decline). In Scenario 1+2, the DIALSTATUS variable is BUSY which is correct. In Scenario 3, the DIALSTATUS is CHANUNAVAIL. To be clear, I was always monitoring the CHANUNAVAIL variable on the Dial(PJSIP/blabla) command. I was even trying to get further information or differences using b(), B() and hangup handlers on the dial command in order to find further differences - with no avail.
Comments:	By: Asterisk Team (asteriskteam) 2018-03-19 10:17:33.922-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: Joshua C. Colp (jcolp) 2018-03-20 06:33:52.720-0500 Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. Please read over the Asterisk Issue Guidelines [1] which discusses the information necessary for your issue to be resolved and the format that information needs to be in. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need: 1. The specific steps or actions you took that caused you to encounter the problem. 2. The behavior you expected and the location of documentation that led you to that expectation. 3. The behavior you actually encountered. To demonstrate the issue in detail, please include Asterisk log files generated per the instructions on the wiki [2]. If applicable, please ensure that protocol-level trace debugging is enabled, e.g., 'sip set debug on' if the issue involves chan_sip, and configuration information such as dialplan and channel configuration. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines [2] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Frederic Steinfels (fredo) 2018-03-20 18:42:48.550-0500 Thanks for your feedback. Point 1, 2 and 3 are covered. Sip debugging is not required as the problem only comes when stacking two local channels. Point of documentation is also not required as using one local channel should forward the same result as two local channels. I will post verbose log files. By: Joshua C. Colp (jcolp) 2018-03-26 13:24:23.801-0500 Your log doesn't match your provided example, but using your example (and even adding more Local channels) I wasn't able to reproduce the issue. I called from a PJSIP channel through 3 Local channels out over PJSIP to an endpoint which returned Busy. Each DIALSTATUS in the chain was BUSY. Can you confirm using the dialplan you've provided that the problem does exist and provide logging (with SIP traces)? By: Frederic Steinfels (fredo) 2018-03-30 10:04:47.687-0500 Ok, indeed, my bad. It has nothing to do with how many channels you are  I figured out the difference. I had a c flag in the dialstring. It seems the Dial(PJSIP/x@y,180,c) will turn the otherwise BUSY dialstatus into a CHANUNAVAIL dialstatus. I think this is a bug. To be precise this time: {noformat} [internal] exten => 64,1,Dial(${SIPCHAN}/xxx@swisscomTestTrunk,180,gItc) exten => 64,2,Noop(Dialstatus is ${DIALSTATUS} Hangupcause is ${HANGUPCAUSE}) {noformat} By: Joshua C. Colp (jcolp) 2018-03-30 10:14:35.362-0500 Forcing "answered elsewhere" on alters the hangup cause so it's not actually busy when it gets to that point, which thus in turn changes the dial status. That's why it is doing what it is doing. From looking at the code it's always been like that so changing it could have repercussions for other people with the behavior change. By: Joshua C. Colp (jcolp) 2018-04-02 06:49:50.905-0500 I'm closing this out as it is working as it is supposed to based on the way it is written. As you'd like it to behave differently this would be a new feature, and it would be difficult to implement.