[asterisk-bugs] [Asterisk 0017085]: [patch] [regression] Overlap dialing to PSTN failing after #16789

Tue Jan 25 11:49:23 CST 2011

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17085 
====================================================================== 
Reported By:                shawkris
Assigned To:                rmudgett
====================================================================== 
Project:                    Asterisk
Issue ID:                   17085
Category:                   Channels/chan_dahdi
Reproducibility:            always
Severity:                   trivial
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.30 
JIRA:                       SWP-1321 
Regression:                 Yes 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2010-03-23 14:13 CDT
Last Modified:              2011-01-25 11:49 CST
====================================================================== 
Summary:                    [patch] [regression] Overlap dialing to PSTN failing
after https://issues.asterisk.org/view.php?id=16789
Description: 
In the UK, local and national calls can be variable length. In Asterisk
1.4.26.2 (and previously) the following dialplan (extract) works:

;National Calls
exten => _0[127]XXXXXXXX!,1,Dial(${GLOBAL(TRUNK)}/${EXTEN})
exten => _0[127]XXXXXXXX!,2,Hangup

In Asterisk 1.4.30, after the 10th digit has been received the call goes
to CALL PROCEEDING. No further digits are then received and forwarded to
the PSTN. It appears the ability to do "pass-through" overlap dialling
doesn't work anymore.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
duplicate of        0018509 [patch] Sending out unnecessary PROCEED...
related to          0016789 [patch] Overlap receiving timeout, plus...
====================================================================== 

---------------------------------------------------------------------- 
 (0131031) svnbot (reporter) - 2011-01-25 11:49
 https://issues.asterisk.org/view.php?id=17085#c131031 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 303771

_U  branches/1.8/
U   branches/1.8/channels/chan_dahdi.c
U   branches/1.8/channels/sig_pri.c
U   branches/1.8/channels/sig_pri.h
U   branches/1.8/channels/sig_ss7.c
U   branches/1.8/channels/sig_ss7.h

------------------------------------------------------------------------
r303771 | rmudgett | 2011-01-25 11:49:21 -0600 (Tue, 25 Jan 2011) | 54
lines

Merged revisions 303769 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
  r303769 | rmudgett | 2011-01-25 11:42:42 -0600 (Tue, 25 Jan 2011) | 47
lines

  Merged revisions 303765 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4

  ........
    r303765 | rmudgett | 2011-01-25 11:36:50 -0600 (Tue, 25 Jan 2011) | 40
lines

    Sending out unnecessary PROCEEDING messages breaks overlap dialing.

    Issue https://issues.asterisk.org/view.php?id=16789 was a good idea. 
Unfortunately, it breaks overlap
dialing
    through Asterisk.  There is not enough information available at this
point
    to know if dialing is complete.  The ast_exists_extension(),
    ast_matchmore_extension(), and ast_canmatch_extension() calls are not
    adequate to detect a dial through extension pattern of "_9!".

    Workaround is to use the dialplan Proceeding() application early in
    non-dial through extensions.

    * Effectively revert issue https://issues.asterisk.org/view.php?id=16789.

    * Allow outgoing overlap dialing to hear dialtone and other early
media.
    A PROGRESS "inband-information is now available" message is now sent
after
    the SETUP_ACKNOWLEDGE message for non-digital calls.  An
    AST_CONTROL_PROGRESS is now generated for incoming SETUP_ACKNOWLEDGE
    messages for non-digital calls.

    * Handling of the AST_CONTROL_CONGESTION in chan_dahdi/sig_pri was
    inconsistent with the cause codes.

    * Added better protection from sending out of sequence messages by
    combining several flags into a single enum value representing call
    progress level.

    * Added diagnostic messages for deferred overlap digits handling
corner
    cases.

    (closes issue https://issues.asterisk.org/view.php?id=17085)
    Reported by: shawkris

    (closes issue https://issues.asterisk.org/view.php?id=18509)
    Reported by: wimpy
    Patches:
          issue18509_early_media_v1.8_v3.patch uploaded by rmudgett
(license 664)
          Expanded upon issue18509_early_media_v1.8_v3.patch to include
analog
          and SS7 because of backporting requirements.
    Tested by: wimpy, rmudgett
  ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=303771 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-01-25 11:49 svnbot         Checkin                                      
2011-01-25 11:49 svnbot         Note Added: 0131031                          
======================================================================