Summary:	ASTERISK-01806: [patch] Overlap dialing not accepted after (premature) proceeding on PRI
Reporter:	petersv (petersv)	Labels:
Date Opened:	2004-06-12 14:00:52	Date Closed:	2004-09-25 02:42:34
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk_apps_app_dial_c.diff ( 1) libpri_q931_c.diff
Description:	Overlap digits are not accepted after Dial() is started. The digits are dropped by libpri in q931_receive() since c->ourcallstate == Q931_CALL_STATE_INCOMING_CALL_PROCEEDING. This prevents us from dialing numbers from our pbx to the pstn. After enough digits have been matched to send the call to the pstn no further digits are passed. Outgoing overlap does not work. Running with "pri intense debug span 2" reveals that the pbx sends INFORMATION elements with the digits. "pri intense debug span 1" shows that asterisk does not pass the digits. Further examination and placing of debug statements led us to the attached patch to q931.c. It probably just masks the error of being in the wrong state, but it allowed us to get this installation up and running. ****** STEPS TO REPRODUCE ****** From extension.conf:  exten 0,1,Dial(Zap/g1) Dial 0 <connected to asterisk> Dial 0 <pstn dial tone> Dial national number  <nothing happens, dialtone remains> ****** ADDITIONAL INFORMATION ****** We have a server with a TE405P sitting between our PSTN connection (E1 PRI) and our PBX (E1 PRI). Both connections are EuroISDN with overlap dialing. Zap/g1 is connected to the PSTN, Zap/g2 is connected to the PBX.
Comments:	By: petersv (petersv) 2004-06-12 14:08:22 I forgot to mention that Asterisk passes "PROCEEDING" to the originating PBX. This does cause some problems with the pbx thinking that the number dialed is complete. Perhaps the proceeding should be supressed in Dial() until it comes from the PSTN? Another problem our work around listed above uncovered was that there is a window after app_dial is started until SETUP ACK is reveiced that digits are silently dropped by zt_digit in zap_chan.c. We worked around that by adding a usleep(500000) to app dial. A more correct fix would be to store numbers in zt_digit after SETUP and then dispatch them once SETUP ACK is received. For completeness I have attached our hack for that as well. We were under a tight time constraint so the fixes are treating the symptoms and not the cause itself I am afraid. By: Mark Spencer (markster) 2004-06-13 02:27:33 When overlap mode is enabled, Asterisk should not provide a PROCEEDING until one is received from the far end switch.  If you can look at the debug for both PRI's it may be possible to see what the far switch is sending us that is causing us to send proceeding. By: petersv (petersv) 2004-06-13 02:50:30 http://www.psv.nu/jbl/problemlog.txt contains a pri intense log of two identical calls, one watching the inside (pbx) line that originates and terminates the call and the second log watches the pstn line. I took two separate logs because at that time I had not figured out how to separate which messages were coming in off which interface. When completed the call goes pbx-asterisk-pstn-asterisk-pbx. the pbx is on Zap/g2 (32-62) and the pstn os in Zap/g1 (1-31): Paraphrased (using the INFORMATION elements to synchronize the two logs): pbx  > ast  SETUP (empty called party number) ast  > pbx  SETUP ACK pbx  > ast  INFORMATION (digit 0)            (asterisk executes Dial(Zap/g1) a) ast  > pbx  CALL PROCEEDING ast  > pbx  PROGRESS b) ast  > pstn SETUP pstn > ast  STATUS (Call initiated?) pstn > ast  SETUP ACK pbx  > ast  INFORMATION (digit 2) ast  > pstn INFRMATIION (digit 2) The blocks marked a) and b) may have come in any order, I cannot deduce the order due to the split logs. I will try to get a log some evening next week. This weekend has seen enough work in our telephony system. By: petersv (petersv) 2004-06-14 14:47:00 The culprit is the test at the start of zt_write. It calls pri_progress when very soon after the first digit is dialed after the Dial(). The frame that triggered this in zt_write was an audio frame (I logged the frametype). So, the sequence was: pbx > ast SETUP (empty called party number) ast > pbx SETUP ACK pbx > ast INFORMATION (digit 0) (asterisk executes Dial(Zap/g1) ast > pstn SETUP pstn > ast SETUP ACK pbx > ast INFORMATION (digit 4) ast > pbx CALL PROCEEDING ast > pbx PROGRESS ast > pstn INFORMATION (digit 4) I commented out the whole ifdef:ed block at the start of zt_write and now everything works just fine. I do not really understand why we send a progress as soon as we send any audio. The sequence above made our analog phone extensions dial duouble numbers since the test that blocks dtmf detection in overlapdial did not kick in when proceeding was set. With the change I can dial from both analog and digital extensions as well as use all he asterisk functions I have tried. By: Mark Spencer (markster) 2004-06-14 16:35:06 As a start, I've separated the PROGRESS and PROCEEDING parts.  This requires an update to libpri and asterisk both.  Let me know if that makes any difference. By: petersv (petersv) 2004-06-14 16:39:59 I will try cvs head late this week och during the weekend. By: petersv (petersv) 2004-06-15 11:33:01 I tested cvs head today quickly. I still get a CALL PROCEEDING after the first digit after app_dial is started. By: petersv (petersv) 2004-06-15 11:47:01 I cannot dial with the latest CVS at all today. Overlap dialling went ok as far as to the first digit after the Dial then they were received but not passed on. I can not test more tonight as there will be an evening seminar here tonight. I have rolled back to the last working version (cvs yesterday. :-) There was still a CALL PROCEEDING generated, but I think this is done automatically by q931.c. By: Mark Spencer (markster) 2004-06-15 22:35:23 find me on irc. By: petersv (petersv) 2004-06-17 14:42:32 This seems solved now. Our hackish patch is no longer needed.