Summary:	ASTERISK-01074: Premature CONNECT while overlap dialing
Reporter:	Tomica Crnek (tcrnek)	Labels:
Date Opened:	2004-02-22 11:57:53.000-0600	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) dialcomplete.log ( 1) overlap-traces.txt ( 2) trace_modem_nok2.txt ( 3) trace_modem_ok1.txt
Description:	With TE410P connected with one E1 to PSTN and other E1 to internal PBX Asterisk sends Q.931 CONNECT towards PBX only after few digits are dialed. ****** ADDITIONAL INFORMATION ****** Attached are 2 traces taken from internal PBX. From this PBX we are dialing out through Asterisk to PSTN. The number is sent digit by digit in INFORMATION elements. The first trace "modem ok1" shows correct behavior. The CONNECT is received from Asterisk after CALL PROCEEDING and ALERTING. In the trace "modem nok2" you can see that only after three digits sent from PBX, CONNECT is received. This is wrong. The number we dialed was in both cases 6110547. In about 8 out of 10 cases it went wrong.
Comments:	By: Mark Spencer (markster) 2004-03-20 14:23:05.000-0600 Find someone in #asterisk who can confirm your dialplan.  I have a feeling this is a configuration issue. By: Mark Spencer (markster) 2004-03-24 14:41:33.000-0600 Have you made any attempt to contact anyone yet regarding this problem?  I will be available in #asterisk to assist if nobody else is. By: Tomica Crnek (tcrnek) 2004-03-24 20:00:25.000-0600 No, I didn't even try yet, because I have to solve another problem with TE410P card first. Mike Wood is working on this another problem. By: Mark Spencer (markster) 2004-04-03 20:57:01.000-0600 What is the status of this bug report?  Are you still having the problem?  Have you had someone look at your dialplan yet? By: Tomica Crnek (tcrnek) 2004-04-04 04:31:34 Nothing is solved. Nobody contacted me about this. About the other problem with TE410P; There is a problem with call drops, and Michael Wood and you Mark said that I need a new card. After installing a new one the problem is the same. Michael have checked everything again and he said everything is fine, but the problem is there and I can't use it. By: Mark Spencer (markster) 2004-04-09 10:30:19 What's the status now? By: Tomica Crnek (tcrnek) 2004-04-09 18:42:54 Hi Mark, I have just received the new card yesterday. I will try to install it during saturday and let you know all about it. Thanks! By: Mark Spencer (markster) 2004-04-10 20:58:55 Please let me know as soon as possible. By: alric (alric) 2004-04-14 10:20:34 Reminder sent to tcrnek Any update on the status of this with the new card? By: Tomica Crnek (tcrnek) 2004-04-14 11:38:45 The new card is now working and I can say that the problem reported in bug 0001061 is now solved. Mark said that this is solved in new firmware and I am happy that you have sent me the card with new firmware at last :) Now about the problem reported in this bug: If someone is dialing real fast from my internal PBX with prefix 0 and any number after that 0, I can see that my PBX sends 0 together with the first digit from the number in first message and other digits in overlap after that one. In that case it goes wrong. But, if a person waits for a moment after dialing this first 0 and then dials fast other digits it goes ok. And one more thing; I can't see whole dialed number when the call is originated from PBX. In that case I see something like this: Accepting call from '6690300' to '00' on channel 19, span 2 , but after these '00' the whole number should be displayed. CDR records don't contain whole numbers also. By: Tomica Crnek (tcrnek) 2004-04-14 11:44:25 Mark said that he will login and check it again after I install the new card and reconfigure PBX to send prefix 0 when dialing out to PSTN. This is now done, and I could open his account again on my box so he can do some traces or anything to solve this problem. By: Mark Spencer (markster) 2004-04-14 15:24:45 Find me on IRC and lets look. By: Mark Spencer (markster) 2004-04-19 19:00:51 Okay, I still think this is a configuration issue either on the PBX (which sends us digits differently depending with how fast you dial) or with Asterisk (coming up with a dialplan that makes more sense for your setup).  Find me on IRC in the next day or two or we're closing this one out. By: Michael Labuschke (zigman) 2004-04-21 12:37:30 i don't use any digium hardware (sorry for that.. i only got isdn) so i use zaphfc (zaptel BRI stuff) from junghanns.net i do have the same problem. here is my dialplan: [default] exten => _[1-9]XXX.,1,EnumLookup(${INTPREFIX}${AREACODE}${EXTEN}) exten => _[1-9]XXX.,2,Goto(enum|${EXTEN}|1) exten => _[1-9]XXX.,102,goto(pstn|${EXTEN}|1) [pstn] exten => _XXX.,1,agi,cbc_select exten => _XXX.,2,Dial(Zap/g2/${preselect}${EXTEN}|60|T) so after the 5th digit is entered asterisk checks for enum ( of course there is none because its only 5 digits) and after that dials out the zap device. now the problem is. when using redial on an analog phone ( behind another pbx connected to *) the phone dials every digit real fast. after 5 digits * opens the outgoing line. but before that line is up ( and other digits can be dialed) the phone has allready send another digit, which gets dropped. possible solution: doesn't asterisk check if the line is up? and if not .. can it not queue that number? attached is my dialcomplete.log By: Mark Spencer (markster) 2004-05-01 23:32:52 This should be fixed now (assuming it is fixable by my fix for ASTERISK-1437) By: Mark Spencer (markster) 2004-05-03 14:43:17 Okay people, need an answer and need an answer in a timely fashion if you care about this bug, otherwise I'll assume it's fixed and close it out.  Remember, only the few remaining MAJOR bugs are preventing the release of 1.0 and 1.1 release candidates. By: Tomica Crnek (tcrnek) 2004-05-03 15:24:34 Hi Mark, I didn't hear from you since you were logged to my server and I don't know if you did something there but nothing changed. I have updated now everything from cvs, tommorow I'll check how it works and let you know. By: Michael Labuschke (zigman) 2004-05-03 17:54:05 i can't test right now.. since i'm unable to patch kapejods bri stuff with curent cvs... what files ( and what versions) are the diff.. i might be able to use those patches to test. By: Mark Spencer (markster) 2004-05-03 18:08:49 It's a substantial patch to chan_zap.  Try to get kapejod to disclaim his BRI stuff so we can put it in the stock asterisk distribution and this won't be a problem in the future. By: Tomica Crnek (tcrnek) 2004-05-04 02:42:00 I have tested it myself and it worked. I have typed digits on the phone connected to my internal PBX as fast as I can and it was ok. Now I'll wait to see if there will be any complaints about it today and then let you know. Mark, can you, please, tell me what is now different? What did you do in chan_zap? By: Tomica Crnek (tcrnek) 2004-05-04 02:44:08 CDR is now ok, the whole dialed number is there, not just a first part of the number as it was before. By: Tomica Crnek (tcrnek) 2004-05-04 07:33:29 People in my company just said that while talking to external GSM phone call was dropped after a minute or little longer. After that I wasn't able to connect to asterisk console. It exited and displayed "broken pipe". I had to restart it. I found this now, this was not there before...    -- Accepting overlap call from '6690249' to '<unspecified>' on channel 4, span 2 May  4 13:23:21 WARNING[1357241136]: ast_expr.y:431 ast_yyerror: ast_yyerror(): syntax error: parse error; Input: SPEECH = DIGITAL ^^^^^^^^^^^^^^^^         ^ By: Mark Spencer (markster) 2004-05-04 10:12:23 Update to latest CVS, if it's still not working, re-open bug 1548 about ast_expr.y.  Thanks!  In the mean time, you can probably just copy the ast_expr.y from an older release.  In any case this bug is fixed. By: Mark Spencer (markster) 2004-05-04 10:12:49 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