Summary:	ASTERISK-23897: [patch]Change in SETUP ACK handling (checking PI) in revision 413765 breaks working environments
Reporter:	Pavel Troller (patrol-cz)	Labels:
Date Opened:	2014-06-16 02:04:16	Date Closed:	2014-07-03 16:41:09
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Channels/chan_dahdi
Versions:	11.10.2	Frequency of Occurrence	Constant
Related Issues:
Environment:	An Asterisk system interconnected with either MD110 release BC13 or Avaya Definity (release Unknown)	Attachments:	( 0) jira_asterisk_23897_v11.patch ( 1) pri.diff
Description:	The change introduced in revision 413765 limits opening the media channel and sending the PROGRESS control frame only to cases, when the Progress Indication with value "Inband Info now available" is present in the SETUP ACK message. However, there are exchanges (like these mentioned in the "environment" section), which don't send this PI in SETUP ACK, but they send regular dial tone. Now the dial tone (and any subsequent audio information until some progress indication is received from the PBX) cannot be heard.  I understand, that the change was necessary to fix another problem, but it introduces this one, so from my point of view, it's a regression.  My proposed solution is to introduce a new config option. I've called it "alwayssendprogress" and it's a binary no/yes option. In the "no" status, it keeps the new behaviour in place. In the "yes" status, it restores the old one. A better naming is possible, any proposals are welcome.  The supplied patch was tested on current V11 SVN and it seems to be working as expected.
Comments:	By: Rusty Newton (rnewton) 2014-06-18 08:43:21.833-0500 [~patrol-cz] For the next step, please follow the [Code Review process|https://wiki.asterisk.org/wiki/display/AST/Code+Review] and put the patch on reviewboard. Remember to link that here once you have done so. Thanks Pavel! By: Pavel Troller (patrol-cz) 2014-06-19 01:26:39.625-0500 I've put the patch on the reviewboard for review as requested. By: Pavel Troller (patrol-cz) 2014-06-19 01:28:00.215-0500 Reviewboard entry created. By: Richard Mudgett (rmudgett) 2014-06-24 15:31:43.591-0500 Can you please attach a "pri set debug on span x" capture of a failing call for posterity? I assume that the outgoing SETUP does not contain any digits for the called number. I was thinking of an alternate method that wouldn't require a compatibility option.  If the outgoing SETUP did not have any called digits then a received SETUP ACK would open the audio path for dialtone because of the Q.931 Section 5.1.3 you noted in your patch. By: Richard Mudgett (rmudgett) 2014-06-24 17:38:36.148-0500 [^jira_asterisk_23897_v11.patch] - Alternate fix.  Please test and report. By: Matt Jordan (mjordan) 2014-07-03 12:14:46.598-0500 We're going to need to make releases of Asterisk 11 soon, and I'd prefer to have this fixed before then. If you can, please test out Richard's patch and provide feedback; otherwise, we'll have to release the next version of Asterisk 11 and fix this later. By: Pavel Troller (patrol-cz) 2014-07-03 12:37:09.471-0500 Sorry for being late. I've seen "Ship it!" on reviewboard and I thought that it's the end of the story :-). It's my first participation here in reviewboard and I'm not experienced enough.  Regarding the patch: It fixes the problem in about 90% of cases. I know of at least one case, where it doesn't work - using partial en-bloc  (i.e. at least one digit dialed in SETUP), followed by digits sent in overlap mode, and the dialed number being routed in the cooperating PBX into another one (transit call) with the same problem (very often case in complex networks like power plant nets etc.).  In such a case, you have to hear a dial tone from that exchange, and you don't hear it, because the second PBX also doesn't send PI in SETUP ACK and the first one simply doesn't send you anything after seizing the line. The original patch is fixing also this case.  With regards,  Pavel By: Richard Mudgett (rmudgett) 2014-07-03 12:46:20.656-0500 Looks like I'll have to merge the two patches.  The Q.931 section you pointed out showed that we were definitely no longer complying when the SETUP did not contain any called digits. By: Richard Mudgett (rmudgett) 2014-07-03 13:09:16.829-0500 By the way, what is the switchtype you are using in chan_dahdi.conf? For completeness, could you attach your chan_dahdi.conf and any files it includes. By: Pavel Troller (patrol-cz) 2014-07-03 13:46:32.305-0500 It's mostly qsig. The cooperating switches are also configured this way. By: Richard Mudgett (rmudgett) 2014-07-03 16:01:51.351-0500 After looking at ISO/IEC 11572 (ECMA's version of Q.931) it would seem that Q.SIG is not supposed to send the progress indication ie with the SETUP ACKNOWLEDGE message.