Summary:	ASTERISK-01437: chan_zap doesn't check for multiple / ambiguous matches on PRI overlap dialling
Reporter:	apollon (apollon)	Labels:
Date Opened:	2004-04-20 05:37:39	Date Closed:	2008-01-15 14:53:08.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) zapdiff
Description:	chan_zap doesn't check for multiple or ambiguous extensions in overlap dialling (before audio mode is established) and thus won't allow for variable-length extensions.
Comments:	By: Mark Spencer (markster) 2004-04-20 11:27:32 I don't believe there is a workable solution here within the PRI specification, because we have to respond with SETUP_ACK.  Is it permissible to send a CALL PROCEEDING after sending SETUP_ACK without having received another SETUP? By: James Golovich (jamesgolovich) 2004-04-21 02:14:44 This can get complicated.  We probably should get t302 implemented. I believe we should be sending the SETUP_ACK right away, reading the INFO messages until either we get the Sending Complete IE or the timer expires. When we get a match in either of those cases we should be sending either an ALERT or CALL PROCEEDING Been a while since I've dug into this though. By: Mark Spencer (markster) 2004-04-23 09:57:22 Actually looking at Q.931 it looks like we can do this trick, it's just gonna take some time. By: apollon (apollon) 2004-04-23 10:41:20 Is this actually a trick? After some discussion (and some background reading on Q.931) I have reached a tentative conclusion that what's actually missing here is indeed the T302 timer. I just started scanning the q931.c code today... I hope I'll have some feedback to provide by Wednsday. By: Mark Spencer (markster) 2004-04-26 00:37:25 Right the T302 timer can do it, although you ahve to look at the table to see that it's actually permissible to send PROGRESS at its expiration as well. By: Mark Spencer (markster) 2004-04-28 10:33:18 Maybe we can make PRI use ss_thread as well.  Perhaps I can login to your system and implement it. By: Mark Spencer (markster) 2004-05-01 23:32:01 This should be fixed in latest CVS.  Please confirm. By: Mark Spencer (markster) 2004-05-02 12:44:42 I'm upgrading this to "major" since it is now implemented and I want to be sure it's carefully tracked.  It is closely related to bug ASTERISK-1074 By: apollon (apollon) 2004-05-03 08:10:06 I checked the cvs version. It appears that my digits are coming in as INFO events, but not in overlap mode. I don't really know why that is happening, but by removing the overlap check I managed to get the system to work and accept calls (not thouroughly tested, yet). Don't take the patch seriously, I'm no coder :D By: Mark Spencer (markster) 2004-05-03 09:11:14 Just add "overlapdial=yes" to your zapata.conf to enable support for overlapdial. By: Mark Spencer (markster) 2004-05-03 23:44:55 Again, please try to answer as timely as possible. By: apollon (apollon) 2004-05-04 04:25:54 Indeed, the overlap setting changed *'s behaviour - sorry for the blunder. I reversed all my changes, and everything seems to be in perfect order in all parts of my dialpan. Thanks Mark!!! and sorry for the delay. By: Mark Spencer (markster) 2004-05-04 10:09:10 Fixed in CVS! By: Digium Subversion (svnbot) 2008-01-15 14:53:08.000-0600 Repository: asterisk Revision: 2854 U   trunk/channels/chan_zap.c ------------------------------------------------------------------------ r2854 | markster | 2008-01-15 14:53:07 -0600 (Tue, 15 Jan 2008) | 2 lines Make overlap dial be interpreted in the same way an FXS would be (bugs ASTERISK-1074 and ASTERISK-1437) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=2854