Summary:ASTERISK-11608: [patch] chan_zap call progress does not connect if there is talking
Reporter:Michael FIG (michael-fig)Labels:
Date Opened:2008-03-10 22:38:27Date Closed:2009-02-12 16:53:37.000-0600
Versions:Frequency of
Environment:Attachments:( 0) 20080717__bug12178.diff.txt
( 1) asterisk-1.4.17-talking.diff
( 2) asterisk-1.4.23-talking.diff
Description:The following issue:

0002799: [patch] Do not use call progress analysis on PRI links

went out of its way to disable DSP_PROGRESS_TALK on Zap channels.  I have no idea why it did that, and the issue doesn't have any discussion of that detail of the patch.


Our application relies on being able to use call progress, and disabling this flag makes the call progress over a T1 extremely inaccurate for anything that isn't a PRI-to-PRI connection.  The attached file (asterisk-1.4.17-talking.diff) removes this disability.  It should apply cleanly to 1.4.18 and CVS as well.
Comments:By: Tilghman Lesher (tilghman) 2008-07-17 15:24:51

Sorry this took so long to track down, but issue ASTERISK-2750 was not where this occurred, but rather in issue ASTERISK-5472.  It does appear that the change was in error, and I'm suggesting a slightly different patch, which should work for PRI, as well as analog lines.

By: Digium Subversion (svnbot) 2008-07-17 15:27:58

Repository: asterisk
Revision: 131790

U   branches/1.4/channels/chan_dahdi.c

r131790 | tilghman | 2008-07-17 15:27:56 -0500 (Thu, 17 Jul 2008) | 7 lines

Revert part of issue ASTERISK-5472 (revision 6965) as it appears that it was in error.
This should fix talk call progress on analog lines.
(closes issue ASTERISK-11608)
Reported by: michael-fig
      20080717__bug12178.diff.txt uploaded by Corydon76 (license 14)



By: Michael FIG (michael-fig) 2009-02-09 13:35:46.000-0600

As I mentioned before, clearing the DSP_PROGRESS_TALK flag from the saved dsp_features variable causes incorrect behaviour for PRIs.  The way I understand the current code (as of 1.4.23), for PRIs the dsp features are set to 0 until after the PROGRESS message is received, at which time the dsp_features are applied to the dsp.

The current behaviour means that talking on the line after PROGRESS is received does *not* cause an ANSWER.  I think this is wrong, and I have verified it by dialing over 1,000 phone numbers with call recording.  People have answered the phone but Asterisk does not return from app_dial, then they hang up and the DIALSTATUS is set to NOANSWER.  Please remove the following lines from chan_dahdi:

               /* Remember requested DSP features, don't treat
                  talking as ANSWER */
               i->dsp_features = features & ~DSP_PROGRESS_TALK;

Instead, just change the comment to "Remember requested DSP features."


By: Tilghman Lesher (tilghman) 2009-02-10 14:52:45.000-0600

If you're proposing a patch, please upload it in the standard unified diff format, not embedded in a bugnote.

By: Michael FIG (michael-fig) 2009-02-12 15:36:52.000-0600

My apologies... attached is the patch.

By: Tilghman Lesher (tilghman) 2009-02-12 16:53:17.000-0600

I'm afraid I have to disagree with your analysis.  PRI links MUST get an explicit ANSWER before billing starts.  We don't want early audio to trigger an answer.  Consider any SS7 congestion message received, which is typically sent as early audio.  You want those calls to be considered as congestion/no answer, not answered and billed.

Additionally, your patch does not do what you're suggesting.