Summary:	ASTERISK-05123: Is impossible send dtmf digits to some toll free remote ivr using early audio
Reporter:	Ezio Vernacotola (ezio)	Labels:
Date Opened:	2005-09-21 13:48:25	Date Closed:	2011-06-07 14:10:11
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) annotated-pri-toll-free-dtmf.txt ( 1) chan_zap_zt_digit.patch ( 2) digitfix1.diff ( 3) post-progressdiff.diff-debug.txt ( 4) pri-toll-free-dtmf.txt ( 5) progressdiff.diff ( 6) progressdiff2.diff
Description:	Here in Italy is a common setup that toll free ivr don't answer the call with CONNECT message, but send back PROGRESS messages. The state of the channel remain "Dialing". In the meantime the ivr send audio to the caller, eg: "press 1 to info..etc.", keeping sending PROGRESS. The caller press the "1" key, but "zt_digit" in chan_zap.c don't send the ZT_DIAL ioctl request, but calls "pri_information". This don't works, the ivr never receives the dtmf. This is very annoying, because make impossible call this kind of ivr. I have told everyone "no problem, use the cellular phone, it's free!", but cleary is not a solution. ****** ADDITIONAL INFORMATION ****** The dtmf aren't sent because ast->_state == AST_STATE_DIALING && (p->proceeding < 2). p->proceeding is 0. Forcing sending anyway ioctl ZT_DIAL requests, resolve the problem. I tried patching myself chan_zap.c, but, because my very little knowledge of zaptel/libpri architecture, this may create I lot of others problems.
Comments:	By: Kevin P. Fleming (kpfleming) 2005-09-25 21:32:50 We need to get two things from you: 1) Do you have overlapdial turned on for this PRI span? 2) Please generate a 'pri debug span <x>' log for one of these calls, so we can see _exactly_ the sequence of messages received from the telco. If possible, please annotate the log with notes that tell us what point you hear audio prompts from the IVR asking you to press digits, and at what point you actually pressed them. By: Ezio Vernacotola (ezio) 2005-09-26 13:11:38 Yes, overlapdial is on. I'm running in the last 4 days with chan_zap.c patched by myself, no side effects in my asterisk, and toll fre ivr works. I'm sending in upload annotated-pri-toll-free-dtmf.txt, with some info in what happened, and my patch chan_zap_zt_digit.patch, it's very simple, I only removed an "else". By: Kevin P. Fleming (kpfleming) 2005-09-26 13:31:09 OK, you are receiving the proper signaling from the telco, but your p->proceeding value is not '2' as it should be. I'll have our Q.931 people take a look at this. By: Andrew Lindh (andrew) 2005-09-26 14:20:22 While not common it does happen in the US too. IBM support 800-426-7378 has the same issue. They don't "answer" the call until a human gets on the phone, AFTER the IVR. You can tell this by the call counter not starting until someone at IBM picks up. (also from debug on asterisk) We use a cisco AS5300 with PRI's and we don't have a problem dialing DTMF without the call being answered. This allows us to hit "0" and get a human before the dial timeout expires and the call disconnects. Sorry, I don't have an internal digium PRI card for testing. But that is a good free USA based number for someone to try. I assume IBM is trying to cheat their 800 service provider and not have "IVR" minutes counted as billable. By: Matthew Fredrickson (mattf) 2005-09-26 19:22:41 I just attached a patch that is probably more generic (and won't break back to back pri behavior).  Could you try it out and tell me if it works the same as your patch? By: Paul Cadach (pcadach) 2005-09-26 21:17:04 There was a bug - we cannot send addressing information after PROCEEDING stage (PROCEEDING means connected switch/PBX/etc. is got all neccessary addressing information and being call establishing). So, any digits, etc. received after PROCEEDING should send out as inband DTMF, not by INFORMATION messages. By: Ezio Vernacotola (ezio) 2005-09-27 12:07:14 Ok Matt, the digitfix1.diff works, it's good for me. By: Matthew Fredrickson (mattf) 2005-09-29 17:24:41 Try the attached diff and see if it still works.  This way should be a little more robust. By: Ezio Vernacotola (ezio) 2005-09-30 13:07:37 I tried, progressdiff.diff does'n work. In zt_digit  p->proceeding is 0, p->outgoing is 1. Seems that after that PRI_EVENT_PROCEEDING is queued we should have back AST_CONTROL_PROCEEDING in zt_indicate, but this doesn't occour. By: Matthew Fredrickson (mattf) 2005-09-30 17:00:07 Try this one.  I'd forgotten to do it for non-bridged calls. By: Ezio Vernacotola (ezio) 2005-09-30 17:24:18 progressdiff2.diff and progressdiff.diff seems the same.. By: Matthew Fredrickson (mattf) 2005-09-30 20:32:37 Sorry, uploaded the wrong patch version.  Try this one :-) By: Ezio Vernacotola (ezio) 2005-09-30 23:01:44 Ok, progressdiff2.diff works. Tomorrow I will see if will be any problem under real workload, I'll let you know. By: Matthew Fredrickson (mattf) 2005-10-04 13:03:00 Committed! By: Digium Subversion (svnbot) 2008-01-15 15:50:00.000-0600 Repository: asterisk Revision: 6711 U   trunk/channels/chan_zap.c ------------------------------------------------------------------------ r6711 | mattf | 2008-01-15 15:49:59 -0600 (Tue, 15 Jan 2008) | 4 lines Rewrite of PRI progress and message handling.  Fixes bugs ASTERISK-5123 and ASTERISK-4353 (Early media related digit passing and passing early media progress between channels) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=6711