[asterisk-bugs] [Asterisk 0016789]: [patch] Overlap receiving timeout, plus dialplan latency, causes network to retry SETUP

Asterisk Bug Tracker noreply at bugs.digium.com
Sat Feb 27 17:38:44 CST 2010


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16789 
====================================================================== 
Reported By:                alecdavis
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16789
Category:                   Channels/chan_dahdi
Reproducibility:            sometimes
Severity:                   minor
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           SVN 
JIRA:                       SWP-887 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.1 
SVN Revision (number only!): 243988 
Request Review:              
====================================================================== 
Date Submitted:             2010-02-08 19:57 CST
Last Modified:              2010-02-27 17:38 CST
====================================================================== 
Summary:                    [patch] Overlap receiving timeout, plus dialplan
latency, causes network to retry SETUP
Description: 
An overlap received call, should have a PROCEEDING sent when asterisk has
deemed that no further digits are coming, IE when asterisk starts executing
the dialplan.

The issue is, ast_waitfordigit in ss_thread waits 'matchdigittimeout'
which set 3 seconds, then there is dialplan delay, which may take a while
to execute PROGRESS(), PROGRESS() or ANSWER(). In our case, database
lookups.

When the network retries the SETUP, with the same channel and call
reference, libpri deems this as a 'Not a new call' and promptly rejects the
call. Now the call is lost!.

Previously it has required the PROCEEDING() to be the the first line of
the dialplan context.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0016755 E1 PRI channel 'glare', where asterisk ...
====================================================================== 

---------------------------------------------------------------------- 
 (0118641) svnbot (reporter) - 2010-02-27 17:38
 https://issues.asterisk.org/view.php?id=16789#c118641 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 249364

U   branches/1.6.0/channels/chan_dahdi.c

------------------------------------------------------------------------
r249364 | alecdavis | 2010-02-27 17:38:43 -0600 (Sat, 27 Feb 2010) | 19
lines

overlap receiving: automatically send CALL PROCEEDING when dialplan starts

Following Q.931 5.2.4
When the user has determined that sufficient call information has been
received the 
user shall stop T302 and send CALL PROCEEDING to the network.

Previously timeouts were possible if the dialplan took a long time to
issue any
response back to the network.

Verified that our local TELCO also does the same.

(issue https://issues.asterisk.org/view.php?id=16789)
Reported by: alecdavis
Patches: 
      overlap_receiving_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis

(closes issue https://issues.asterisk.org/view.php?id=16789)

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

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-02-27 17:38 svnbot         Checkin                                      
2010-02-27 17:38 svnbot         Note Added: 0118641                          
======================================================================




More information about the asterisk-bugs mailing list