[Home]

Summary:ASTERISK-15865: [patch] [regression] Overlap dialing to PSTN failing after #16789
Reporter:Kris Shaw (shawkris)Labels:
Date Opened:2010-03-23 14:13:23Date Closed:2011-01-25 11:58:07.000-0600
Priority:TrivialRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bug17085.diff.txt
( 1) bug17085-diff2.txt
( 2) with-no-progress.txt
( 3) with-progress.txt
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.

****** ADDITIONAL INFORMATION ******

Asterisk sits between a legacy PBX and the PSTN (BT).

chan_dadhi.conf (extract):
overlapdial=yes

switchtype=euroisdn
context=in-from-bt
group=1
echocancel=yes
signalling=pri_cpe
channel =>1-15

switchtype=euroisdn
context=in-from-siemens
group=2
echocancel=yes
signalling=pri_net
channel =>32-46
Comments:By: Kris Shaw (shawkris) 2010-03-23 14:25:35

Sorry, the category should be Channels/chan_dahdi, not SS7.
By: Alec Davis (alecdavis) 2010-03-23 17:00:51

The attached test patch bug17085.diff.txt disables the CALL PROCEEDING that is automatically sent as the pbx starts executing.
By: Kris Shaw (shawkris) 2010-03-23 17:53:22

Thank you for the patch to test - I'll give this a try out of hours. We also experienced two failures after upgrading to 1.4.30 from 1.4.26.2 so I need to test carefully. Our legacy PBX dropped the ISDN30 link to Asterisk and couldn't re-establish it until Asterisk was killed and restarted (span 2 repeatedly flapping in and out of red alarms). The connection to the PSTN remained active and usable.

Going back to 1.4.26.2 stablised the system (as it has been for 2 years). The physical link, DAHDI (2.2.0.2) and Libpri (1.4.10.2) are unchanged between the stable and unstable versions. I'll open a seperate bug if I can find the cause and it's not related to this CALL PROCEEDING issue.


By: Kris Shaw (shawkris) 2010-03-24 12:50:55

I have tested the patch and it returns the original behaviour of the dialplan.

I am now testing to see if it improves the stability problem, in case the legacy PBX had a problem with the previous behaviour somehow.
By: Alec Davis (alecdavis) 2010-03-24 18:24:08

For the record please advise brand/model of PABX.

The CALL PROCEEDING may just need the progress indication set to 'In-band info/approp patt now avail'. But need to verify this before trying.
By: Kris Shaw (shawkris) 2010-03-25 03:11:13

Legacy PBX is Siemens Realitis (same software as the ISDX). I have attached a very small amount of the log before we saw the red alarm. The Realitis seems to drop the pri as part of its recovery mechanism. Just after the red alarm the Realitis error q931 error counters were only recording SABME errors. I didn't have the logging turned up enough to see what was actually happening in detail.

The problem seems to need call traffic to make it show. It ran all night with 1.4.30 with the light call traffic, but in the working day there were two periods when all calls were dropped in the space of an hour.

[Mar 23 09:59:32] VERBOSE[12357] logger.c: > Protocol Discriminator: Q.931 (8)  len=9
[Mar 23 09:59:32] VERBOSE[12357] logger.c: > Call Ref: len= 2 (reference 2198/0x896) (Terminator)
[Mar 23 09:59:32] VERBOSE[12357] logger.c: > Message type: PROGRESS (3)
[Mar 23 09:59:32] VERBOSE[12357] logger.c: > [1e 02 81 88]
[Mar 23 09:59:32] VERBOSE[12357] logger.c: > Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: Private network serving$
[Mar 23 09:59:32] VERBOSE[12357] logger.c: >                               Ext: 1  Progress Description: Inband information or appropriate pattern now avail$
[Mar 23 09:59:34] VERBOSE[12205] logger.c: < Protocol Discriminator: Q.931 (8)  len=9
[Mar 23 09:59:34] VERBOSE[12205] logger.c: < Call Ref: len= 2 (reference 2198/0x896) (Originator)
[Mar 23 09:59:34] VERBOSE[12205] logger.c: < Message type: DISCONNECT (69)
[Mar 23 09:59:34] VERBOSE[12205] logger.c: < [08 02 81 90]
[Mar 23 09:59:34] VERBOSE[12205] logger.c: < Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the loca$
[Mar 23 09:59:34] VERBOSE[12205] logger.c: <                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
[Mar 23 09:59:34] VERBOSE[12205] logger.c: -- Processing IE 8 (cs0, Cause)
[Mar 23 09:59:34] VERBOSE[12205] logger.c: q931.c:3826 q931_receive: call 2198 on channel 13 enters state 12 (Disconnect Indication)
[Mar 23 09:59:58] WARNING[12206] chan_dahdi.c: Detected alarm on channel 32: Red Alarm
[Mar 23 09:59:58] WARNING[12206] chan_dahdi.c: Unable to disable echo cancellation on channel 32: Invalid argument
[Mar 23 09:59:58] WARNING[12206] chan_dahdi.c: Detected alarm on channel 33: Red Alarm
[Mar 23 09:59:58] WARNING[12206] chan_dahdi.c: Unable to disable echo cancellation on channel 33: Invalid argument
By: Kris Shaw (shawkris) 2010-03-25 03:29:32

My guess is that the Siemens dropped the link in an attempt to restart due to T305 expiry (set to 30 seconds in its config), as it appears no RELEASE was sent after it's DISCONNECT request.
By: Alec Davis (alecdavis) 2010-03-25 03:32:06

Please open a new bug for the dropped pri.
Answer these in there.

How do you recover from the dropped pri?

You could perhaps try the libpri 1.4 svn branch.
q.921 has been reworked and is working well for us, but PABX is Fujitsu.
By: Kris Shaw (shawkris) 2010-03-25 03:36:34

The recovery was a restart of Asterisk.
I think we've tripped over this bug because of the dialplan problem. The call was very short, and was just the inband message from the PSTN saying number unobtainable (because last dialled digit was never sent). So, the user just hung up.

Does the inband error message count as a call? If it doesn't, would the call release properly after user DISCONNECT? It seems the q931 code checks to see if the call is active first before sending RELEASE.

I'll do some more debugging and raise another bug.
By: Alec Davis (alecdavis) 2010-04-02 03:45:34

I've been travelling last week sorry for the delay.

With this test patch in place, could you please provide a pri debug trace of both spans of a single successfull call to an 11 digit number using;
pri intense debug span 1
pri intense debug span 2
Also turn up verbose to 3 and debug to 3.

A section from the log file is best as it has time stamps.
By: Kris Shaw (shawkris) 2010-04-05 17:01:07

I need to be on-site out-of-hours to do this, so it will probably be Weds evening before I can capture and upload the trace.
By: Alec Davis (alecdavis) 2010-04-05 17:32:03

After the capture is done (without Proceeding sent), if it's not too much to ask.

Could you please add a Proceeding() in the dialplan before the dial to the trunk.

This Proceeding() I'm sure will have the progress indicator 'inband progress and tones available', and then try an 11 digit number again. If you could upload the capture from that call too, would be much appreciated, and whether it was successful or not.


By: Kris Shaw (shawkris) 2010-04-07 12:22:07

I have uploaded the traces.
Proceeding() isn't available in 1.4, so I tested with Progress() in case that was of any use. Both calls were successful.

exten => _0[1237]XXXXXXXX!,1,Progress()
exten => _0[1237]XXXXXXXX!,n,Dial(${GLOBAL(TRUNK)}/${EXTEN})
exten => _0[1237]XXXXXXXX!,n,Hangup
By: Alec Davis (alecdavis) 2010-04-08 06:00:12

uploaded bug17085-diff2.txt.
to patch cleanly, requires bug17085-diff.txt to be in place first.

This should send Proceeding with 'inband progress available'
By: Kris Shaw (shawkris) 2010-04-08 07:04:19

Hello,

Looking at the Q.931 spec (3.1.2), it looks like our PBX would be correct to stop sending digits when it receives a CALL PROCEEDING message, since at that point Asterisk has indicated that it won't accept further establishment information.

Kris.
By: Leif Madsen (lmadsen) 2010-04-14 14:16:37

Just curious where we've gotten with this? It seems to be a regression, but I don't think I'm going to hold up the next set of release candidates for this issue. There is currently a blocking issue though, so if this gets fixed before I create 1.4.31-rc2, then it could go in.

Please let me know though if this gets closed, because it will need to be merged manually into the release candidate when I copy the currently RC1 to a new tag. Thanks!
By: Kris Shaw (shawkris) 2010-04-21 11:45:39

I'm not sure where we can go with this. It seems that PROCEEDING should only be sent if no more digits can be send, which is not the case with ! in the dial plan.
I've a look through the code and perhaps it would be necessary to determine earlymatch from chan_dahdi.
By: Alec Davis (alecdavis) 2010-04-21 14:14:27

shawkris: I was thinking the same regarding earlymatch.

A simple change to the dialplan to match the first 9 digits (not 10) and change the '!' to a '.' will then cause a wait for 3 seconds, and if no digits are received in this time the PBX starts running.

like below
;National Calls
exten => _0[127]XXXXXXX.,1,Dial(${GLOBAL(TRUNK)}/${EXTEN})
exten => _0[127]XXXXXXX.,2,Hangup
By: Kris Shaw (shawkris) 2010-04-22 11:34:50

I'm still running with 1.4.26 as I've not worked out why 1.4.30 got stuck. However, I did change my dialplan anyway. I've now got two entries for national calls:

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

exten => _0[1237]XXXXXXXXX,1,Dial(${GLOBAL(TRUNK)}/${EXTEN})
exten => _0[1237]XXXXXXXXX,n,Hangup

The two national call entries are there so the 11 digit one matches immediately rather than waiting 3 seconds before dialling (which users don't like).

For shorter dialplan entries, e.g. _0X. then if the user is slow to dial and the PBX starts running they can't then overlap dial further digits. There is then another long pause before the PSTN dial times out and plays the "number not recognised" message, which is confusing.


By: Digium Subversion (svnbot) 2011-01-25 11:31:20.000-0600

Repository: asterisk
Revision: 303747

U   branches/1.4/main/pbx.c

------------------------------------------------------------------------
r303747 | rmudgett | 2011-01-25 11:31:19 -0600 (Tue, 25 Jan 2011) | 9 lines

Backport the Proceeding application.

Added in trunk -r129399.

Enable the workaround for issue ASTERISK-15865 and ASTERISK-17141.

(issue ASTERISK-15865)
(issue ASTERISK-17141)

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

http://svn.digium.com/view/asterisk?view=rev&revision=303747
By: Digium Subversion (svnbot) 2011-01-25 11:36:52.000-0600

Repository: asterisk
Revision: 303765

U   branches/1.4/channels/chan_dahdi.c

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

Sending out unnecessary PROCEEDING messages breaks overlap dialing.

Issue ASTERISK-15594 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 ASTERISK-15594.

* 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 ASTERISK-15865)
Reported by: shawkris

(closes issue ASTERISK-17141)
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=303765
By: Digium Subversion (svnbot) 2011-01-25 11:42:44.000-0600

Repository: asterisk
Revision: 303769

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_dahdi.c

------------------------------------------------------------------------
r303769 | rmudgett | 2011-01-25 11:42:43 -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 ASTERISK-15594 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 ASTERISK-15594.
 
 * 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 ASTERISK-15865)
 Reported by: shawkris
 
 (closes issue ASTERISK-17141)
 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=303769
By: Digium Subversion (svnbot) 2011-01-25 11:49:23.000-0600

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 ASTERISK-15594 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 ASTERISK-15594.
   
   * 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 ASTERISK-15865)
   Reported by: shawkris
   
   (closes issue ASTERISK-17141)
   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
By: Digium Subversion (svnbot) 2011-01-25 11:58:06.000-0600

Repository: asterisk
Revision: 303772

_U  trunk/
U   trunk/channels/chan_dahdi.c
U   trunk/channels/sig_pri.c
U   trunk/channels/sig_pri.h
U   trunk/channels/sig_ss7.c
U   trunk/channels/sig_ss7.h

------------------------------------------------------------------------
r303772 | rmudgett | 2011-01-25 11:58:01 -0600 (Tue, 25 Jan 2011) | 61 lines

Merged revisions 303771 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
 r303771 | rmudgett | 2011-01-25 11:49:20 -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 ASTERISK-15594 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 ASTERISK-15594.
     
     * 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 ASTERISK-15865)
     Reported by: shawkris
     
     (closes issue ASTERISK-17141)
     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=303772